Skip to content
Universal Manifest

DID + VC Credential Lane

This page describes a method-agnostic pattern for binding DID and Verifiable Credential attestations to Universal Manifest subjects.

DID & VC Integration

Boundary: normative vs non-normative

Section titled “Boundary: normative vs non-normative”
  • Normative contract: Specification and Conformance
  • Non-normative guidance: this page

All claim names, pointer names, and consent keys on this page are non-normative examples.

What you implement

Section titled “What you implement”

Inputs

Section titled “Inputs”
  • A valid Universal Manifest with a stable subject identifier
  • A DID reference for the subject or credential issuer (any supported DID method)
  • A VC attestation with verifiable issuer and status metadata

Outputs

Section titled “Outputs”
  • Manifest claims entries carrying DID + VC attestation references
  • Deterministic handling for revoked or unrecognized credentials
  • Consent-gated disclosure of credential data

Minimum behaviors

Section titled “Minimum behaviors”
  • Represent DID + VC attestations as claim extensions
  • Ignore unknown DID/VC claim types safely
  • Enforce consent before disclosing credential data
  • Do not treat revoked credentials as valid attestations
  • Keep DID/VC-specific fields out of core required UM fields

DID overview

Section titled “DID overview”

Universal Manifest does not require a single DID method. Common options include did:key, did:web, did:ion, did:pkh, and did:plc. DID resolution is method-specific and can be implemented with any resolver stack appropriate for your environment.

Landscape caveats

Section titled “Landscape caveats”
  • The methods and stacks listed here are examples, not an endorsed shortlist.
  • DID/VC ecosystems change quickly, so this page should not be read as a permanent recommendation of specific vendors or networks.
  • DID + VC guidance does not choose storage, federation, or runtime architecture for UM implementations.

Composite-stack position

Section titled “Composite-stack position”

DID + VC material mostly strengthens the trust layer of Universal Manifest:

  • subject and issuer identifiers
  • attestation provenance
  • status/revocation checks
  • presentation and disclosure controls

VC attestation model

Section titled “VC attestation model”

VC attestations can be represented using JSON-LD VC or JWT VC profiles. UM carries these as extension claims while keeping the core document format unchanged. Verification typically includes issuer checks, signature/proof validation, and credential status checks.

Suggested pointer names

Section titled “Suggested pointer names”
  • did.document
  • vc.statusListCredential
  • vc.schema
Section titled “Suggested consent keys”
  • didvc.credentialShare
  • didvc.statusCheck

Next

Section titled “Next”