All posts

SD-JWT VC: The Identity Industry’s Latest Attempt to Win a Nobel Prize in Acronyms

by Robert Broeckelmann

If you’ve ever opened the specifications surrounding SD-JWT Verifiable Credentials and thought_,_ “Surely this is a straightforward document that defines a credential format.”

…you’ve already made your first mistake.

A Slightly More Relevant SD-JWT VC Image (Generated By ChatGPT) / Author

Instead, you’ll find yourself wandering through a dense forest of specifications with names like OID4VCI, OID4VP, SD-JWT, DPoP, RFC 9901, JWS, JWK, and JWT. Before long, you’ll be ten tabs deep into IETF drafts, questioning your life choices and wondering whether anyone has ever actually implemented all of this.

The good news is that there is a method to the madness.

The bad news is that the method requires understanding how several specifications work together to solve a very real problem of how do we issue, store, selectively disclose, and verify digital credentials in a secure and privacy-preserving way?

Let’s break it down.

First: The Related Specs

Related Specs & RFCs

The Problem

Imagine a digital driver’s license.

Today, proving your age often means showing an entire physical card that reveals:

  • Full name
  • Address
  • Date of birth
  • License number
  • Height
  • Weight
  • Eye color
  • Potentially other information

The bartender only needs to know one thing_,_ “Is this person over 21?”

Yet we’re forced to disclose everything.

The same problem exists for:

  • Employee badges
  • Professional certifications
  • University degrees
  • Government IDs
  • Membership cards
  • Health credentials
  • The author’s CISSP certification.

Traditional identity systems tend to expose far more information than necessary.

The SD-JWT VC ecosystem attempts to solve this.

The Goal

The goal is surprisingly simple:

  1. An issuer creates a digital credential.
  2. A wallet stores it.
  3. A holder presents only the claims they choose.
  4. A verifier validates those claims.
  5. Nobody learns more information than necessary.

Accomplishing this requires several different specifications.

The Actors

At first glance, an SD-JWT VC deployment appears to involve only three parties: someone issues a credential, someone holds it, and someone verifies it. In reality, the ecosystem is built from several distinct actors, each with a well-defined responsibility. Separating these responsibilities is one of the strengths of the OpenID and IETF architecture, allowing each component to evolve independently while remaining interoperable with the others.

Holder: The person (or, in some cases, an organization) that owns the credential. The Holder is the subject of the claims contained within the credential and ultimately decides when, where, and with whom those claims are shared. The Holder is responsible for approving both the issuance of new credentials and the presentation of existing credentials. Unlike traditional identity systems, the Holder maintains direct control over which attributes are disclosed to a verifier.

Wallet: The software application acting on behalf of the Holder. It securely stores credentials, manages cryptographic keys, performs protocol exchanges with issuers and verifiers, and generates the cryptographic proofs required during credential presentation. While the Holder makes trust decisions, the Wallet performs the technical work necessary to enforce those decisions. The Wallet is therefore the protocol participant, while the Holder remains the decision maker.

Issuer: The trusted authority responsible for creating verifiable credentials. Examples include governments issuing driver’s licenses, universities issuing diplomas, employers issuing employee credentials, or financial institutions issuing proof-of-account credentials. During issuance, the Issuer verifies the Holder’s identity, constructs the credential, selectively hashes claims according to the SD-JWT specification, generates the disclosure objects, digitally signs the credential, and returns it to the Holder’s Wallet.

Authorization Server: Authenticates the Holder and authorizes the Wallet to request credentials from the Issuer. Rather than inventing a new authorization protocol, OpenID for Verifiable Credential Issuance (OID4VCI) leverages the existing OAuth 2.0 Authorization Framework. This allows organizations to reuse their existing identity infrastructure while providing the Wallet with an access token that authorizes credential issuance. In many deployments, the Authorization Server and Issuer are operated by the same organization, although they remain logically distinct services.

Verifier: The relying party requesting proof of one or more claims. A verifier may be an employer requesting proof of certification, a retailer requesting proof of age, a hotel requesting proof of identity, or any application requiring trusted information about the Holder. The Verifier requests only the claims necessary to complete a transaction and validates the authenticity of the credential before accepting it.

Status List Service: Provides revocation and suspension information for previously issued credentials. Rather than contacting the Issuer each time a credential is presented — which would undermine privacy — the Verifier retrieves a signed status list containing the revocation status of many credentials simultaneously. This allows credentials to be invalidated while minimizing information leakage about when and where they are being presented.

Where RFC 9901 Fits

One of the more interesting pieces of the ecosystem is RFC 9901**.** RFC 9901 allows a client to present signed identity attestations. It defines SD-JWT and SD-JWT VC.

Imagine an issuer needing proof that:

  • A user belongs to a particular organization
  • A user already possesses another credential
  • A trusted authority has validated certain claims

RFC 9901 provides a standardized way to submit those attestations.

This becomes particularly valuable in complex ecosystems where multiple issuers and trust authorities participate.

The Credential Format: SD-JWT VC

At the center of everything is SD-JWT VC (or SD-JWT).

This specification defines what the credential looks like.

Rather than placing all claims directly inside a signed JWT, certain claims can be hidden behind cryptographic hashes.

The issuer might create a credential containing:

{  "given_name": "Alice",  "family_name": "Smith",  "birthdate": "2000-01-01",  "address": "123 Main St"}

But, instead of exposing everything, the credential contains hashes of selected claims.

Later, the holder decides which claims to reveal.

For example:

  • Reveal age only
  • Reveal name only
  • Reveal professional certification only

The verifier can cryptographically verify those disclosures without seeing the hidden information.

This is the “selective disclosure” in SD-JWT.

The Cryptographic Foundation: SD-JWT

Underneath SD-JWT VC is the more general SD-JWT format.

This specification defines:

  • Claim disclosures
  • Hash generation
  • Disclosure verification
  • Holder-selected claim release

Think of SD-JWT VC as SD-JWT + Verifiable Credential Rules

SD-JWT provides the cryptographic machinery; SD-JWT VC applies it to credentials.

The Issuance Problem

Now we have a credential format.

How does a wallet actually obtain one?

Enter:

OpenID for Verifiable Credential Issuance (OID4VCI)

OID4VCI defines the protocol used between the Issuer and Wallet

The issuer advertises available credentials.

The wallet requests them.

The issuer validates the user.

The credential is issued.

In simple terms_,_ OID4VCI answers the question: “How do I get a credential?”

Real-World Issuance Example

Suppose a university wants to issue a diploma.

The flow looks like:

JWT-SD VC Issuance Flow

At the end:

  • The student has a cryptographically verifiable diploma.
  • The university no longer needs to be online every time the diploma is shown.

OAuth2 Shows Up Again

Identity engineers can relax.

OAuth2 isn’t going anywhere.

OID4VCI builds on familiar technologies:

  • OAuth 2.0
  • OpenID Connect

Rather than inventing an entirely new security model, the specification reuses:

  • Authorization flows
  • Tokens
  • Authentication
  • Consent mechanisms

This means existing OAuth2 infrastructure remains useful.

The Presentation Problem (OIDC4VP)

Obtaining a credential is only half the story.

How does a holder present it?

That’s where OpenID for Verifiable Presentations (OID4VP) comes into play.

OID4VP defines communication between a Wallet and Verifier.

The verifier requests specific information.

The wallet decides what to disclose.

The verifier validates the response.

OID4VP answers_,_ “How do I present a credential?”

Real-World Presentation Example

Suppose a website needs proof that a user is over 21.

The verifier sends:

Need:  age_over_21

The wallet responds:

Verified:  age_over_21 = true

No address.

No driver’s license number.

No unnecessary personal information.

Just the information required.

Holder Binding and DPoP

An obvious question arises.

What prevents someone from copying a credential and sharing it with others?

This is where DPoP (Demonstration of Proof-of-Possession) becomes useful.

DPoP allows the holder to prove possession of a private key associated with the credential.

In effect, Credential + Private Key.

Both are required.

Stealing the credential alone is insufficient.

This greatly reduces the value of credential theft.

The Supporting Cast

Several mature standards quietly provide the foundation.

JWT (RFC 7519)

The credential container.

The thing carrying the claims.

JWS (RFC 7515)

The digital signature format.

Used to prove:

  • Authenticity
  • Integrity
  • Issuer identity

JWK (RFC 7517)

The key representation format.

Defines how public keys are described and exchanged.

Putting It All Together

The complete ecosystem looks like this:

SD-JWT VC Issuance (with spec assignments)

SD-JWT VC Presentation Workflow (with spec assignments)

Summary

It is easy to look at the stack of specifications and conclude that the identity industry has collectively decided to communicate exclusively through acronyms.

But beneath the mountain of standards is a genuinely important shift.

For decades, identity systems have relied on over-disclosure. Every interaction reveals more information than necessary because credentials were designed as all-or-nothing artifacts.

The SD-JWT VC ecosystem changes that.

Instead of asking, “Who are you?”, systems can ask, “Can you prove this specific fact?” And, users can answer, “Yes”, without revealing everything else.

That’s a powerful idea.

It just happens to require enough specifications to keep standards lawyers, cryptographers, and protocol engineers employed for the foreseeable future.

Notes

  • AI / GenAI / ChatGPT / etc were not used to generate the text of this article.
  • ChatGPT was used to generate the images.
  • I used em dashes in my writing before the current GenAI wave was a thing. Not planning on changing now.
  • Names have been changed to protect the guilty.
  • None of the hostnames or users used in examples actually exist.
  • Feel free to post any comments or suggestions below.

Originally published on Medium.

More articles