1. Birth of RFC 9901
November 19, 2025, "Selective Disclosure for JSON Web Tokens," a.k.a. SD-JWT The specifications that define (SDJOT) RFC 9901 It was released as.
The authors are the following three people.
- Daniel Fett (Authlete）
- Kristina Yasuda (SPRING）
- Brian Campbell (ping identity）
JSON Web Token (JWT) [RFC 7519]と JSON Web Signature (JWS) [RFC 7515]It is,ID Token,JWT Access Token [RFC 9068]It is an Internet standard that has been widely used in
SD-JWT gives us the new ability to extract and display only the parts we need later.
In the lineage of the JOSE family (JWS / JWT / JWE),
This can be seen as the addition of a new pillar called "Selective Disclosure" as an official RFC.
2. What is the SD-JWT specification for?
2-1. Issues with conventional JWT: "issued on demand" or "all-inclusive"
Traditional JWTs were based on a model in which a "block of signed JSON" was passed directly to the service.
- The issuer (IdP or authentication server) compiles user information into a JWT.
- The receiving service (relying party) can read the entire contents
This means that if you use a model like OpenID Connect, where certificates are issued dynamically as needed, it is possible to achieve selective disclosure, data minimization, and unlinkability between RPs (RP+RP'-U Unlinkability) (typically using PPID = Pairwise Pseudonymous Identifier). However, if you want to "issue a certificate in advance without knowing its purpose and then use it later," you have the problem that none of these are possible.
For example, if a single JWT contains "age," "address," "name," and "email address," the service side may only need to know whether the user is over 20 years old, but if it uses a JWT that has been issued and saved in advance, it will be able to see everything, including the address and name.
This "all-in-one" structure is simple to implement, but if you want to save and use,
- Selective disclosure is not possible = data collection minimization principle cannot be met
- RP+RP'-U Unlinkability is also not satisfied
These were the limitations (although this was a trade-off with the simplicity of the implementation).
2-2. Compatibility with wallet models
On the other hand, there are certainly use cases where you want to use saved data later. Typical use cases include using it in places where there is no signal or presenting a graduation certificate after a school has closed down. You might think, "Is it really that common to have no signal?", but that's because Japan is in a favorable environment. In Europe, the signal quality is poor, especially inside stone buildings, and even if you go just a little way from the station, you can lose signal even outdoors, even in major cities like Mannheim. This is of course also the case in the vast United States. Perhaps for this reason, in Europe, EUDI Wallet Recent identity wallets include:
- One wallet (smartphone app) can handle multiple transactions Verifiable Credentials (VC) Save up the
- The user selects "Show only this item for this service" and presents it.
This model is the premise. In this case, the wallet and issuer only need to be connected online when issuing.
What is needed here is
"A format that allows you to select and safely display a portion of a stored signed data file later."
This is defined by RFC 9901 This is SD-JWT.
3. SD-JWT in a nutshell
Very roughly speaking, SD-JWT works as follows:
- The base is the same as before Signed JWT (JWS)
- However, some claims areOnly the hash value" in the JWT
- Putting the original value and salt together Disclosure Keep it separate and pass it to the Verifier only when necessary
- Verifier is
- Recalculate the hash from the Disclosure
- By verifying that it matches the hash in the signed JWT
- You can confirm that "it is indeed part of the data signed by the issuer"
Furthermore, to prevent unauthorized transfer of tokens, A mechanism for linking to a user's key pair (Key Binding) Is also available.
The combined structure SD-JWT+KB called.
4. Three characters and the flow of SD-JWT
The basic cast of characters in SD-JWT is the same as in the VC world.
- Issuer
Government offices, banks, universities, etc. Organizations that are responsible for facts. - Holder
The user himself/herself holds the credentials in the wallet app on his/her smartphone. - Verifier
Service providers, such as bank account opening, age verification, and entrance control.
The typical flow is as follows:
- Issuance
- The issuer compiles the user's attribute information (address, date of birth, etc.) into JSON.
- Regarding "items you would like to selectively disclose later,"
Calculate a hash from the value + a random salt and embed only that hash in the JWT - The original value + salt is prepared separately as a Disclosure
- The signed JWT and multiple Disclosures are bundled together and passed to the Holder as an "SD-JWT".
- Presentation
- A user tries to use a service
- The wallet selects only the disclosures it wants to show to the verifier from the SD-JWT.
- Send the signed JWT + selected Disclosure + (and Key Binding JWT, if necessary) to the Verifier
- Verification
- Verifier is
- Verify the JWT signature with the Issuer's public key
- Use Disclosure to recalculate the hash for each item and verify that it matches the hash in the JWT
- This ensures that the data is part of the data signed by the Issuer, while protecting undisclosed items.
- Verifier is
5. A bit of technical talk: Salt and Disclosure
5-1. Selective disclosure using salted hashing
Each claim (address, date of birth, etc.)
- Salt + Value + (possibly claim name)
Calculate the hash from the JWT and embed the hash value in the JWT.
When actually disclosing, it should be stated as Disclosure.
- "Salt, Claim Name, Value"
to the Verifier.
The verifier recalculates the hash using the same procedure and checks whether it matches the hash in the JWT to see if it has been tampered with.
The salt makes it difficult to guess the value of undisclosed claims.
5-2. Disclosure
The RFC defines a Disclosure as a Base64url encoded JSON array, for example:
- Element 0: Salt
- Element 1: Claim name (may be omitted for array elements)
- Element 2: Claim Value
Inside the wallet,
"Keep one large credential as a collection of small Disclosures, and send only what you need."
I think it's easier to understand if you think of it this way.
5-3. Key Binding and SD-JWT+KB
With only SD-JWT, there remains the risk of an attack (replay attack) in which a token is copied and presented by someone else.
Therefore, RFC 9901 specifies a mechanism for binding an SD-JWT to a Holder's key pair. Key Binding defines:
- Include the Holder's public key (or a reference to it) in the SD-JWT
- The Holder signs with that key upon presentation. Key Binding JWT (KB-JWT) Send together
- Verifier is
- SD-JWT and KB-JWT are bound to the same key
- Verify that the holder actually has the private key
Key Binding is now required SD-JWT+KB This will increase the resistance to VC copying.
noteHolder Binding can be Key Binding, Claim Binding, or Biometrics Binding. +KB implements Key Binding. However, with Key Binding, if the device or other media storing the key itself is transferred, it is possible for someone to impersonate you (this is known as an Alice-to-Bob Attack). Buying and selling a bank account is a perfect example of this. To prevent this, Biometrics Binding is usually required.
5-4. Support for JSON structures and arrays
RFC 9901 goes beyond simple flat JSON.
- Nested Objects
- Element-by-element disclosure of arrays
- Hiding patterns with "dummy hashes (decoy digests)"
It also defines how to handle such cases.
This
- Prevent people from guessing that "everyone has the same credentials"
- Reduce the risk of being tracked solely by the number of items disclosed
This makes it possible to come up with ideas such as:
6. SD-JWT and VC Identity Wallets
6-1. SD-JWT VC: Positioning as a VC format
The IETF uses SD-JWT in RFC 9901. A specification for expressing Verifiable Credentials As
"SD-JWT-based Verifiable Credentials (SD-JWT VC)" A draft is being prepared.
this is,
- VC in JSON format
- SD-JWT allows selective disclosure
- Determine the verification method
This is a specification that has the following role. Currently, the WG is in review before entering the WG Last Call, and I am also a reviewer.Approximately 28 editorial improvements(Some of the suggestions may be considered technical.) (These suggestions include breaking down sentences that are long and difficult to read when written by Americans or Germans, addressing the issue of the executor of obligations becoming unclear due to the excessive use of passive voice, and considerations of security, privacy, and fairness.) In addition, in order to verify the examples included in the specification draft, we have created a static HTML/JavaScript page "sd-jwt-decoder" was also created.It's also available on GitHub(It's just a single HTML page, so it can be easily run locally - I needed it to verify the draft on an airplane), so if you find any bugs, please submit a pull request.
6-2. Use with EUDI wallet
European Commission EUDI Architecture Reference Framework (ARF) So, the standard to be used in European digital ID wallets is:
- OpenID for Verifiable Credentials (OpenID4VCI / OpenID4VP)
- SD-JWT / SD-JWT VC
- ISO/IEC 18013-5 Mobile Driver's License (mDL)
It has been shown that a combination of the following can be used.
In this context, RFC 9901 states:
"VC stored in identity wallets such as EUDI wallets
Core format for JWT/JOSE-based implementation
It is positioned as follows.
6-3. Benefits from the perspective of wallet users
The general user experience will look something like this:
- Age confirmation
At convenience stores, you only need to provide the truth that you are over 20 years old, not your date of birth. - Address Verification
Only provide the address required for delivery to the online shopping site and hide other attributes - Know Your Customer (KYC)
Present only the necessary attributes to banks and securities companies, and reuse the same VC for other services.
All of this is made possible by the nature of SD-JWT, which allows you to break down a single signed piece of data into smaller pieces and extract only the parts you need.
7. Expansion of the ecosystem (overview)
Several OSS and commercial solutions are already incorporating SD-JWT/SD-JWT VC into their implementations.
- SD-JWT support in various wallet frameworks:Siros Foundation One of them is wwWallet, developed by .
- Provision of SD-JWT VC issuing endpoints by Authlete and other organizations
- Adoption in the EUDI Wallet Project and SPRIND Initiative
- The OpenID Foundation has developed a High-Security Profile (HAIP) that combines OpenID4VC and SD-JWT VC.
RFC 9901 is positioned as a "foundational piece" on top of this movement.
8. Summary
- RFC 9901 is an Internet standard that gives JWT/JWS the ability to "selectively disclose."
- SD-JWT is
- The signed JWT contains only the hash.
- The original value and salt are presented as Disclosures only when necessary.
- However, the signature of the issuer still ensures authenticity.
It defines the format.
- Added Key Binding SD-JWT+KB This allows for secure presentation that is tied to the wallet owner.
- Combined with the SD-JWT VC draft, EUDI ARF, and OpenID4VC profile,
One of the core formats for VC stored in identity wallets It will be used as.
This new piece has been added to the JOSE/JWT family of technologies, and it can be said that a realistic implementation pattern for wallet-based digital identity infrastructure has become clear.