Skip to main content

Verifiable Credentials and SD-JWT

Verifiable credentials allow an issuer to make tamper-evident claims that can be held and later presented to a verifier. SD-JWT adds a standardized mechanism for selectively disclosing individual elements from a signed JSON structure.

UbID uses these concepts to separate the issuer's signed evidence from the holder's decision about what to present and from the verifier's decision about whether the evidence is sufficient.

The credential trust model​

A credential interaction normally involves:

  • an issuer that makes and signs claims;
  • a holder that receives and controls the credential;
  • a wallet or holder service that protects and presents it;
  • a verifier that validates evidence and applies policy;
  • a subject, which may or may not be identical to the holder.

A valid signature establishes integrity and issuer-key provenance. It does not, by itself, establish that the issuer is trusted for the claim, that the evidence is current, or that the transaction should be approved.

Verifiable Credential semantics​

The W3C Verifiable Credentials Data Model defines a common conceptual model for issuers, holders, subjects, credentials, presentations, claims, schemas, and status. It does not require one universal cryptographic proof format.

A credential profile must still define:

  • the credential type and claim meanings;
  • required and optional fields;
  • issuer and subject identifiers;
  • validity and status behavior;
  • cryptographic envelope and allowed algorithms;
  • holder-binding requirements;
  • presentation and verification rules.

UbID treats VC Data Model 2.0 as an important semantic reference. Current UbID credential paths also use JWT-based selective-disclosure formats, and individual credential profiles must state their exact conformance model.

SD-JWT selective disclosure​

SD-JWT allows an issuer to sign commitments to selected claim values rather than placing every value directly in the visible signed payload. The holder keeps the associated disclosures and reveals only those required for a presentation.

A verifier reconstructs the disclosed view and validates that each disclosure matches a commitment protected by the issuer's signature.

This supports minimisation, but it does not automatically prevent correlation. Stable identifiers, unique claim combinations, timestamps, credential identifiers, verifier behavior, and repeated presentation patterns can still create linkability.

SD-JWT and SD-JWT VC are not the same thing​

The distinction matters:

TermScope
SD-JWTThe IETF selective-disclosure mechanism for JSON data and JWT claims.
SD-JWT VCA credential profile defining data format and processing rules for verifiable digital credentials based on SD-JWT.
W3C VC Data ModelA semantic model for credentials and presentations, independent of one proof format.
VC secured with JOSE/COSEA W3C approach for applying JOSE, SD-JWT, or COSE mechanisms to credentials conforming to the VC data model.

As of the editorial baseline for this portal, SD-JWT is an IETF Standards Track RFC, while the IETF SD-JWT VC credential profile remains a work in progress. UbID documentation must therefore pin the profile version used by a deployment and must not describe draft-profile support as universal final-standard conformance.

Holder binding​

A credential can be cryptographically bound to holder-controlled key material. During presentation, the holder may prove control of the relevant key and bind the presentation to the verifier, audience, nonce, or transaction.

Holder binding can reduce credential theft and replay risk, but it does not replace user consent, device security, status checks, or verifier policy. Some credential use cases may also require a bearer or delegated model; the profile must make that choice explicit.

Status and lifecycle​

A credential can remain correctly signed while becoming expired, suspended, revoked, replaced, or outside the verifier's accepted policy. Verification therefore considers:

  • issuer trust and signing material;
  • signature and algorithm policy;
  • validity period;
  • credential status;
  • schema and profile version;
  • holder binding where required;
  • presentation freshness and audience;
  • requested claims and purpose;
  • verifier policy.

Data minimisation and receipts​

A verifier should request only the claims needed for the declared purpose. It should also minimise the receipt it retains after verification. Retaining the full presentation merely because selective disclosure was used can defeat the privacy benefit.

UbID position​

Selective-disclosure JWT credentials are part of the implemented and transitional UbID baseline. W3C VC semantics, SD-JWT VC profiles, status mechanisms, and presentation contracts are governed per credential type and partner profile.

No public example in this portal represents a production credential, customer schema, real key, or complete acceptance policy.

Source standards​

See Selective Disclosure, Credential Lifecycle, and Verification and Policy.