Skip to main content

Tier 1 - Technical Interoperability

Tier 1 validates that your credential is a technically valid, cryptographically verifiable W3C Verifiable Credential that can be processed by any W3C VC-compliant verifier.

What Tier 1 Validates​

Tier 1 ensures your credential meets the core requirements of the W3C Verifiable Credentials Data Model 2.0:

  • W3C Verifiable Credentials Data Model 2.0 compliance
  • Valid JSON-LD structure with correct @context URLs
  • Cryptographic proof verification (signature validity)
  • Issuer DID resolution (does the issuer DID resolve correctly?)
  • Credential status checking (if status list is present)
  • Temporal validity (validFrom and validUntil dates)

Why This Matters​

Tier 1 ensures your credential is a technically valid Verifiable Credential that can be cryptographically verified by any W3C VC-compliant verifier. Without passing Tier 1, your credential cannot be trusted regardless of its content.

Even if your credential contains all the correct data, if it fails Tier 1 validation, it cannot be verified and trusted by other systems in the UNTP ecosystem.

Testing Methods​

The easiest way to test Tier 1 is using the UNTP Playground:

  1. Go to https://test.uncefact.org/untp-playground
  2. Upload your signed credential JSON file
  3. Check the "Technical Interoperability" section shows PASS
  4. If it fails, review the error messages for specific issues

The playground will show you exactly which checks passed or failed, making it easy to identify and fix problems.

CLI Testing​

For automated testing, CI/CD integration, or batch validation:

  1. Install the UNTP Test Suite CLI - See UNTP Test Suite CLI documentation
  2. Run validation - Use the CLI to validate credentials programmatically
  3. Review reports - Get detailed conformance reports

Library Integration​

For programmatic integration into your own tools:

note

For comprehensive testing guidance, detailed API documentation, and advanced use cases, refer to the official UNTP Test Suite documentation.

Validation Checklist​

Before testing, verify:

  • Credential includes required @context URLs
  • issuer.id is a valid, resolvable DID
  • Credential has a valid proof object with signature
  • validFrom is present and not in the future
  • validUntil is present and not in the past
  • DID document is accessible at the expected URL
  • Signature matches the public key in the DID document

Testing Your Credential​

Step-by-Step: Using UNTP Playground​

  1. Prepare your credential

    • Ensure it's a valid JSON file
    • Make sure it's signed with a valid proof

  2. Upload to Playground

  3. Review Tier 1 Results

    • Look for the "Technical Interoperability" section
    • Check for PASS or FAIL indicators
    • Review any error messages

  4. Fix Issues

    • Address any failures shown in the results
    • Re-upload and verify fixes

Testing Sample Credentials​

You can test against our sample credentials to verify your setup:

  • Sample credentials: /schema/example/ (served from static/schema/example/)
  • These are signed with: did:web:un.opensource.unicc.org:unece:uncefact:spec-unttp:acme
  • Download and test them in the playground to see what passing credentials look like

Common Issues and Solutions​

Why is my credential failing with "Missing or Incorrect @context URLs"?

Problem: The credential doesn't include required context URLs or uses incorrect URLs.

Solution: Ensure your @context array includes:

  • "https://www.w3.org/2018/credentials/v1" (or v2)
  • UNTP-specific context URLs
  • Textiles Extension context URLs (when published)

Example:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://test.uncefact.org/vocabulary/untp/dpp/dpp-context.jsonld"
  ]
}

Why is my credential failing with "Invalid issuer.id" or "DID Resolution Failure"?

Problem: The issuer DID cannot be resolved or doesn't exist.

Solution:

  • Ensure issuer.id is a valid DID format (e.g., did:web:example.com)
  • Verify the DID document is accessible at the expected URL
  • For did:web, ensure the DID document is served at the correct path

Example:

  • DID: did:web:example.com:path:to:issuer
  • Must resolve to: https://example.com/path/to/issuer/did.json

Why is my credential failing with "Malformed Proof" or "Invalid Signature"?

Problem: The credential's proof object is missing, malformed, or the signature is invalid.

Solution:

  • Ensure your credential includes a proof object
  • Verify the signature was created with the correct private key
  • Check that the proof format matches the verification method in the DID document

Example:

{
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2024-01-01T00:00:00Z",
    "verificationMethod": "did:web:example.com#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "..."
  }
}

Why is my credential failing with "Expired Credentials"?

Problem: The credential's validUntil date is in the past, or validFrom is in the future.

Solution:

  • Ensure validFrom is not in the future
  • Ensure validUntil is not in the past
  • Use ISO 8601 format for dates: "2024-01-01T00:00:00Z"

Why is my credential failing with "DID Document Not Accessible"?

Problem: The issuer's DID document cannot be fetched (network error, 404, etc.).

Solution:

  • Verify the DID document URL is correct
  • Ensure the DID document is publicly accessible
  • Check that the web server is configured correctly
  • For did:web, ensure the document is served with correct content-type headers