Wiki · Concept · Last reviewed June 25, 2026

SD-JWT VC

SD-JWT VC is the IETF profile for expressing verifiable digital credentials as Selective Disclosure JWTs, so a holder can reveal only selected claims when presenting evidence to a verifier.

Category: Concept Updated: June 25, 2026 Tags: digital identity, selective disclosure, wallets, verifiable credentials, AI governance

Definition

SD-JWT VC, short for SD-JWT-based Verifiable Digital Credentials, is an Internet-Draft in the IETF OAuth Working Group. The datatracker entry for draft-ietf-oauth-sd-jwt-vc-16 lists Oliver Terbu, Daniel Fett, and Brian Campbell as authors, shows the draft as submitted to the IESG with publication requested, and marks it as intended for the Standards Track. The draft defines JSON-payload credential formats and processing rules with and without selective disclosure, based on SD-JWT.

The base SD-JWT mechanism is RFC 9901, Selective Disclosure for JSON Web Tokens. RFC 9901 defines how individual elements of a JSON structure used as a JWS payload can be selectively disclosed; its primary use case is selective disclosure of JWT claims. SD-JWT VC specializes that mechanism for verifiable digital credentials.

The important practical distinction is this: SD-JWT VC is a credential format, not a wallet, not a browser API, and not a presentation protocol. It can be carried through protocols such as OpenID for Verifiable Presentations, mediated by wallet software, and interpreted under a trust framework, but those layers remain separate.

Mechanism

An issuer creates a signed credential in which some claim values can be hidden behind disclosures. Later, the holder can present the signed SD-JWT with only the disclosures needed for a verifier. The verifier checks the issuer signature, disclosed values, hash commitments, and any holder-binding proof required by the deployment.

The SD-JWT VC draft says issuers encode an SD-JWT VC using RFC 9901's SD-JWT format. Presentations are encoded as an SD-JWT or as an SD-JWT with key binding. The draft defines the vct claim for credential type, allows type metadata, includes optional status information, and identifies application/dc+sd-jwt as the Internet media type.

Selective disclosure is therefore a cryptographic affordance, not a complete privacy program. The holder may reveal fewer fields than a conventional signed JWT would, but the presentation can still leak through identifiers, metadata, issuer patterns, verifier logs, repeated use, wallet behavior, or rare credential types.

Standards Stack

W3C Verifiable Credentials Data Model v2.0 defines the broader issuer-holder-verifier ecosystem. The W3C Recommendation Securing Verifiable Credentials using JOSE and COSE, published on May 15, 2025, defines how to secure credentials and presentations conforming to that data model with JOSE, SD-JWT, and COSE. It registers media types including application/vc+sd-jwt and application/vp+sd-jwt.

OpenID for Verifiable Presentations 1.0, a Final OpenID Foundation specification published on July 9, 2025, defines a protocol for requesting and presenting credentials. It names IETF SD-JWT VC as one possible credential format alongside W3C Verifiable Credentials Data Model credentials and ISO mdoc credentials. In deployment, OpenID4VP may move the presentation, SD-JWT VC may format the credential, and a browser or wallet may mediate the user decision.

Agent Context

For AI agents, SD-JWT VC matters because a credential prompt can become part of ordinary automation. A browser agent, benefits navigator, workplace assistant, travel tool, education agent, or procurement bot may encounter a verifier asking for age, authorization, licensure, employment role, residency, student status, or organizational authority. The agent may understand the form, but the user bears the consequence of disclosure.

An agent should not treat selective disclosure as permission to disclose. It should identify the verifier, summarize the requested claims, distinguish required from optional disclosures, explain holder binding, and surface retention and refusal consequences when available. Pre-approved automation should be narrow: "prove employee-of-this-company to this exact internal service," not "present work credentials when asked."

Governance Risks

The first risk is selective-disclosure theater. A verifier can ask for too much, and a polished consent screen can normalize the demand. The second risk is correlation. A credential that reveals one attribute may still expose a stable subject identifier, rare credential type, issuer metadata, status-check side effects, or repeatable holder binding.

The third risk is authority laundering. The credential may be genuine while the verifier has no legitimate reason to ask for it. The fourth risk is audit blindness: later reviewers may know that "an SD-JWT VC was presented" without seeing which disclosures were released, who authorized the request, what alternatives were offered, or whether an agent recommended acceptance.

Governance Pattern

Source Discipline

Claims about SD-JWT VC should name the draft version, base SD-JWT reference, credential data model, media type, and presentation protocol. Do not collapse RFC 9901, IETF SD-JWT VC, W3C VC JOSE/COSE, W3C Verifiable Credentials Data Model, OpenID4VP, or the Digital Credentials API into one thing. They can appear in the same product, but they answer different questions.

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