Wiki · Concept · Last reviewed August 12, 2026

SD-JWT VC

SD-JWT VC is an IETF work-in-progress credential format built on RFC 9901. It lets an issuer sign JSON claims and, where the issuer permits, lets a holder disclose only selected claims—without by itself proving issuer authority, verifier entitlement, subject identity, status, or unlinkability.

Category: Concept Published: June 25, 2026 Modified: August 12, 2026 Last reviewed: August 12, 2026 Tags: digital identity, selective disclosure, JWT, wallets, verifiable credentials, AI governance

Definition

SD-JWT VC is the established short name for SD-JWT-based Verifiable Digital Credentials, a proposed IETF format for cryptographically secured JSON credentials. It profiles the Selective Disclosure JWT mechanism standardized in RFC 9901, adds credential-specific claims and processing rules, and supports presentations with or without selective disclosure and with or without cryptographic holder key binding.

The current draft deliberately uses the three-word term Verifiable Digital Credential to distinguish its model from the W3C Verifiable Credentials Data Model. The established short name still omits the letter D. An SD-JWT VC can be used in a W3C-related ecosystem, but it is not automatically a W3C VCDM credential.

SD-JWT VC is a credential format, not an issuance protocol, presentation protocol, wallet, browser API, status service, or trust framework. Those surrounding layers decide how a credential is obtained, requested, mediated, checked, accepted, retained, and contested.

Snapshot

Current Context

As reviewed on August 12, 2026, the current version was draft-ietf-oauth-sd-jwt-vc-18, dated August 3 and last updated on the IETF Datatracker on August 10. The OAuth Working Group state was “Submitted to IESG for Publication,” while the IESG state was “AD Evaluation: Revised I-D Needed.” Its intended status was Proposed Standard. These labels describe a document moving through review; they do not make it an approved RFC, and Internet-Drafts can change or be replaced.

The draft specifies the media type application/dc+sd-jwt and JOSE typ value dc+sd-jwt. On the review date, IANA's application-media-type registry listed RFC 9901's application/sd-jwt and application/sd-jwt+json, plus W3C's distinct application/vc+sd-jwt and application/vp+sd-jwt, but not application/dc+sd-jwt. Implementations should therefore pin the draft or ecosystem profile they implement, preserve explicit typing, and avoid describing the proposed subtype as already registered.

OpenID for Verifiable Presentations 1.0 and OpenID for Verifiable Credential Issuance 1.0 are Final OpenID Foundation specifications and both profile IETF SD-JWT VC with the format identifier dc+sd-jwt. Their finality does not change the IETF profile's work-in-progress status.

Mechanism

At issuance, the issuer signs a JWT whose payload can contain ordinary cleartext claims and digests of separately encoded Disclosures. Each Disclosure contains a cryptographically random salt, a claim value, and—for object properties—the claim name. The holder receives the issuer-signed JWT and the available Disclosures.

At presentation, the holder sends the same issuer-signed JWT with only the selected Disclosures. The verifier hashes each supplied Disclosure, checks that its digest appears in the signed structure, and reconstructs the disclosed payload. Omitted Disclosures do not invalidate the issuer signature. The issuer, however, chooses which fields are selectively disclosable and at what structural granularity; a holder can choose only within those bounds.

If a deployment requires key binding, the holder also signs a Key Binding JWT with the private key identified by the credential's cnf claim. Its required aud, nonce, iat, and sd_hash values bind the proof to the intended verifier, a fresh transaction, and the exact issuer-signed JWT plus selected Disclosures. A verifier must decide from policy whether key binding is required rather than trusting the presence or absence of a KB-JWT in the received presentation.

Selective disclosure is not encryption, generic predicate proving, or automatic data minimization. For example, an issuer can sign a derived claim such as “over 18” so the holder need not reveal a birth date, but the format does not derive that predicate at presentation time. RFC 9901 also places confidentiality in the transport layer and explicitly says SD-JWT does not provide the properties of anonymous credentials.

Validation and Trust

A verifier first validates the issuer signature and uses an issuer-key discovery method permitted for that issuer by policy. If it cannot establish that the verification key corresponds to the issuer, it must reject the credential. It then validates disclosure digests, required validity claims, and any application-specific rules. If key binding is required, it also validates the KB-JWT and its audience, nonce, time, signature, and sd_hash.

That cryptographic result has a narrow meaning. A valid issuer signature does not show that the issuer was authorized to issue the asserted credential type, that the claims are factually correct, or that the verifier is entitled to request them. The draft requires issuer authorization to be checked independently of the vct, aka_vcts, or type-inheritance relationship. Likewise, the optional sub subject identifier has no required binding to the cnf holder key. Key possession is therefore not, by itself, subject identity.

The optional status claim identifies a status mechanism. If it is present, the draft says status should be checked and leaves acceptance or rejection to verifier policy. The adjacent Token Status List specification was itself an active Internet-Draft at version 21 on the review date. Status freshness, unavailable-list handling, and the authority of a status issuer belong in the deployment policy.

The vct value can point to Type Metadata describing display text, claims, mandatory fields, and selective-disclosure rules. Processing this metadata is policy-dependent, but when it is processed the draft requires complete processing, including inherited types, and rejection on validation failure. A metadata publisher is not necessarily the credential issuer, so publisher trust and document integrity are separate checks.

Standards Stack

Agent Context

For AI agents, SD-JWT VC matters because a credential request can appear inside routine automation. A browser agent, benefits navigator, workplace assistant, travel tool, education agent, or procurement bot may encounter a verifier asking for age, licensure, employment role, residency, student status, or organizational authority. The agent can parse the request, but the person or organization represented by the credential bears the consequences of disclosure and denial.

An agent should not treat selective disclosure as permission to disclose. Before any presentation it should identify the verifier, state the purpose, enumerate always-visible and requested claims, distinguish required from optional fields, report whether key binding and status checking will occur, and surface retention and refusal consequences when available. Pre-approved automation should be exact as to verifier, credential type, claim set, purpose, and expiry.

Wallets, verifiers, and agents must also treat issuer metadata, Type Metadata, images, data URIs, and display strings as untrusted input. The draft calls out server-side request forgery, denial-of-service, active-content, and text-rendering risks. Agentic systems should additionally keep such content outside privileged instructions so credential metadata cannot steer tool use or policy decisions through Prompt Injection.

Governance Risks

Selective-disclosure theater. The issuer controls disclosure granularity, and the verifier controls what it demands. A deployment can advertise selective disclosure while leaving sensitive fields always visible, bundling several facts into one Disclosure, or conditioning service on an excessive claim set.

Correlation. The issuer-signed JWT is reused across presentations unless the ecosystem issues multiple or replacement credentials. The visible vct, aka_vcts, issuer identifier, validity times, holder key, and status reference can also distinguish a person or credential. RFC 9901 states that salted-hash SD-JWT cannot prevent a colluding verifier from forwarding the issuer-signed credential back to the issuer, and the SD-JWT VC draft warns that remote key or metadata retrieval can become an issuer “phone home.”

Authority and identity confusion. A correct signature can authenticate a rogue or unaccredited issuer. A recognized type identifier does not grant authority to issue that type. A valid holder-key proof establishes possession of a key, not necessarily the real-world identity or current authority of the credential subject.

Metadata supply chain. Remote issuer and type metadata expand the attack and availability surface. Unbounded fetches can enable SSRF or resource exhaustion; unavailable metadata can block offline use; malicious display content can mislead users; and on-demand retrieval can reveal credential use. Caching and integrity pinning can reduce some of these risks but create their own update and governance duties.

Audit hoarding and exclusion. Recording the full credential or every Disclosure can defeat the privacy benefit and create a high-value breach target. Recording too little leaves no evidence of which claims, policy, verifier, status result, or agent recommendation drove a consequential decision. Systems also need a non-credential route and Notice and Appeal when wallet loss, metadata failure, stale status, or an erroneous claim blocks access.

Governance Pattern

Source Discipline

Claims about SD-JWT VC should cite both an immutable draft version and the live IETF status page. Call the profile a work in progress until an RFC is published, and distinguish a media type specified in an Internet-Draft from one already registered by IANA. Record the transition behavior if an implementation still accepts the older vc+sd-jwt JOSE typ value.

Do not collapse RFC 9901, IETF SD-JWT VC, W3C VC JOSE/COSE, W3C VCDM, OpenID4VCI, OpenID4VP, Token Status List, the Digital Credentials API, a wallet, or a trust framework into one “verified credential” result. They answer different questions.

A defensible report should state what was cryptographically verified, how the signing key was bound to the issuer, why that issuer was authorized for the credential type, which claims were always visible or disclosed, whether key binding was required, how status and metadata were handled, what policy entitled the verifier to ask, and what evidence supports the underlying claim. Do not describe SD-JWT as encryption, a generic Zero-Knowledge Proof, or an unlinkable anonymous-credential system.

Spiralist Reading

Spiralism reads SD-JWT VC as a small ceremony of withholding. The credential says: some facts may be proven without exposing the whole file. That is useful, but incomplete. A society of automated verifiers can still make every doorway ask for a token. The humane version treats selective disclosure as the beginning of restraint, not the end of governance.

Open Questions

Sources

Return to Wiki