| RFC 9901 | SD-JWT | November 2025 |
| Fett, et al. | Standards Track | [Page] |
This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS).The primary use case is the selective disclosure of JSON Web Token (JWT) claims.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9901.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The exchange of JSON data between systems is often secured against modification using JSON Web Signatures (JWSs)[RFC7515].A popular application of JWS is the JSON Web Token (JWT)[RFC7519], a format that is often used to represent a user's identity.An ID Token as defined in OpenID Connect[OpenID.Core], for example, is a JWT containing the user's claims created by the server for consumption by a relying party.In cases where the JWT is sent immediately from the server to the relying party, as in OpenID Connect, the server can select at the time of issuance which user claims to include in the JWT, minimizing the information shared with the relying party who validates the JWT.¶
Another model is emerging that fully decouples the issuance of a JWT from its presentation.In this model, a JWT containing many claims is issued to an intermediate party, who holds the JWT (the Holder).The Holder can then present the JWT to different verifying parties (Verifiers) that each may only require a subset of the claims in the JWT.For example, the JWT may contain claims representing both an address and a birthdate.The Holder may elect to disclose only the address to one Verifier, and only the birthdate to a different Verifier.¶
Privacy principles of minimal disclosure in conjunction with this model demand a mechanism enabling selective disclosure of data elements while ensuring that Verifiers can still check the authenticity of the data provided.This specification defines such a mechanism for JSON payloads of JWSs, with JWTs as the primary use case.¶
Selectively Disclosable JWT (SD-JWT) is based on an approach called "salted hashes": For any data element that should be selectively disclosable, the Issuer of the SD-JWT does not include the cleartext of the data in the JSON payload of the JWS structure; instead, a digest of the data takes its place.For presentation to a Verifier, the Holder sends the signed payload along with the cleartext of those claims it wants to disclose.The Verifier can then compute the digest of the cleartext data and confirm it is included in the signed payload.To ensure that Verifiers cannot guess cleartext values of non-disclosed data elements, an additional salt value is used when creating the digest and sent along with the cleartext when disclosing it.¶
To prevent attacks in which an SD-JWT is presented to a Verifier without the Holder's consent, this specification additionally defines a mechanism for binding the SD-JWT to a key under the control of the Holder (Key Binding).When Key Binding is enforced, a Holder has to prove possession of a private key belonging to a public key contained in the SD-JWT itself.It usually does so by signing over a data structure containing transaction-specific data, herein defined as the Key Binding JWT.An SD-JWT with a Key Binding JWT is called "SD-JWT+KB" in this specification.¶
This specification defines two primary data formats:¶
SD-JWT is a composite structure, consisting of a JWS plus optional Disclosures, enabling selective disclosure of portions of the JWS payload. It comprises the following:¶
SD-JWT+KB is a composite structure of an SD-JWT and a cryptographic Key Binding that can be presented to and verified by the Verifier. It comprises the following:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
sd_hash claim. Its format is defined inSection 4.3.¶+------------+ | | | Issuer | | | +------------+ | Issues SD-JWT including all Disclosures | v +------------+ | | | Holder | | | +------------+ | Presents SD-JWT or SD-JWT+KB including selected Disclosures | v +-------------+ | |+ | Verifiers ||+ | ||| +-------------+|| +-------------+| +-------------+
This section describes SD-JWTs with their respective Disclosures and Key Binding at aconceptual level, abstracting from the data formats described inSection 4.¶
An SD-JWT, at its core, is a digitally signed JSON document containing digests over the selectively disclosable claims with the Disclosures outside the document. Disclosures can be omitted without breaking the signature, and modifications to them can be detected. Selectively disclosable claims can be individual object properties (name/value pairs) or array elements.¶
Each digest value ensures the integrity of, and maps to, the respective Disclosure. Digest values are calculated using a hash function over the Disclosures, each of which contains a cryptographically secure random salt, the claim name (only when the claim is an object property), and the claim value. The Disclosures are sent to the Holder with the SD-JWT in the format defined inSection 4.When presenting an SD-JWT to a Verifier, the Holder only includes the Disclosures for the claims that it wants to reveal to that Verifier.¶
An SD-JWTMAY also contain cleartext claims that are always disclosed to the Verifier.¶
To disclose to a Verifier a subset of the SD-JWT claim values, a Holder sends only the Disclosures of those selectively released claims to the Verifier as part of the SD-JWT.¶
Key Binding is an optional feature. When Key Binding is required by the use case, the SD-JWTMUST contain information about the key material controlled by the Holder.¶
Note: How the public key is included in SD-JWT is described inSection 4.1.2.¶
When a Verifier requires Key Binding, the Holder presents an SD-JWT+KB, consisting of an SD-JWT as well as a Key Binding JWT tied to that SD-JWT.The Key Binding JWT encodes a signature by the Holder's private key over¶
Details of the format of Key Binding JWTs are described inSection 4.3.¶
At a high level, the Verifier¶
The detailed algorithm is described inSection 7.3.¶
An SD-JWT is composed of¶
An SD-JWT+KB is composed of¶
The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in Sections4.1,4.2, and4.3, respectively.¶
The compact serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows, where "D.1" to "D.N" represent the respective Disclosures:¶
<Issuer-signed JWT>~<D.1>~<D.2>~...~<D.N>~¶
The order of the concatenated partsMUST be the Issuer-signed JWT,a tilde character, zero or more Disclosures each followed by a tilde character,and lastly the optional Key Binding JWT.In the case that there is no Key Binding JWT, the last elementMUST be an emptystring and the last separating tilde characterMUST NOT be omitted.¶
The serialized format for an SD-JWT+KB extends the SD-JWT format by concatenating a Key Binding JWT.¶
<Issuer-signed JWT>~<D.1>~<D.2>~...~<D.N>~<KB-JWT>¶
The two formats can be distinguished by the final~ character that is presenton an SD-JWT. A Verifier that expects an SD-JWTMUST verify that the finaltilde-separated component is empty. A Verifier that expects an SD-JWT+KBMUST verifythat its final tilde-separated component is a valid KB-JWT.¶
The Disclosures are linked to the Issuer-signed JWT through thedigest values included therein.¶
When issuing to a Holder, the Issuer includes all the relevant Disclosures in the SD-JWT.¶
When presenting to a Verifier, the Holder sends only the selected set of the Disclosures in the SD-JWT.¶
The HolderMAY send any subset of the Disclosures to the Verifier, i.e.,none, some, or all Disclosures. For data that the Holder does not want to revealto the Verifier, the HolderMUST NOT send Disclosures or reveal the salt values in anyother way. A HolderMUST NOT send a Disclosure that was not included in the issuedSD-JWT or send a Disclosure more than once.¶
To further illustrate the SD-JWT format, the following examples show a few differentSD-JWT permutations, both with and without various constituent parts.¶
An SD-JWT without Disclosures:¶
<Issuer-signed JWT>~¶
An SD-JWT with Disclosures:¶
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~¶
An SD-JWT+KB without Disclosures:¶
<Issuer-signed JWT>~<KB-JWT>¶
An SD-JWT+KB with Disclosures:¶
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~<KB-JWT>¶
As an alternative illustration of the SD-JWT format, ABNF[RFC5234] for theSD-JWT, SD-JWT+KB, and various constituent parts is provided here (for those who celebrate):¶
ALPHA = %x41-5A / %x61-7A ; A-Z / a-zDIGIT = %x30-39 ; 0-9BASE64URL = 1*(ALPHA / DIGIT / "-" / "_")JWT = BASE64URL "." BASE64URL "." BASE64URLDISCLOSURE = BASE64URLSD-JWT = JWT "~" *(DISCLOSURE "~")KB-JWT = JWTSD-JWT-KB = SD-JWT KB-JWT¶
An SD-JWT has a JWT component thatMUST be signed using the Issuer's privatekey. ItMUST NOT use thenone algorithm.¶
The payload of an SD-JWT is a JSON object according to the following rules:¶
_sd_alg key described inSection 4.1.1.¶iss,iat, etc. as defined or required by the application using SD-JWTs.¶_sd or... except for the purpose of conveying digests as described in Sections4.2.4.1 and4.2.4.2, respectively.¶The same digest valueMUST NOT appear more than once in the SD-JWT.¶
Application and profiles of SD-JWTSHOULD be explicitly typed. SeeSection 9.11 for more details.¶
It is the Issuer who decides which claims are selectively disclosable by the Holder and which are not. ClaimsMAY be included as plaintext as well, e.g., if hiding the particular claims from the Verifier is not required in the intended use case. SeeSection 9.7 for considerations on making validity-controlling claims such asexp selectively disclosable.¶
Claims that are not selectively disclosable are included in the SD-JWT in plaintext just as they would be in any other JSON structure.¶
The claim_sd_alg indicates the hash algorithm used by the Issuer to generatethe digests as described inSection 4.2. When used, this claimMUSTappear at the top level of the SD-JWT payload. ItMUST NOT be used in any object nested within the payload. If the_sd_algclaim is not present at the top level, a default value ofsha-256MUST be used.¶
This claim value is a case-sensitive string with the hash algorithm identifier.The hash algorithm identifierMUST be a hash algorithm value from the "Hash NameString" column in the "Named Information Hash Algorithm Registry"[Hash.Algs] or a value defined in another specification and/orprofile of this specification.¶
To promote interoperability, implementationsMUST support thesha-256 hashalgorithm.¶
SeeSection 9 for requirements regarding entropy of the salt,minimum length of the salt, and choice of a hash algorithm.¶
If the Issuer wants to enable Key Binding, it includes a public keyassociated with the Holder, or a reference thereto, using thecnf claim as defined in[RFC7800].Thejwk confirmation method, as defined inSection 3.2 of [RFC7800], issuggested for doing so, however, other confirmation methods can be used.¶
Note that, as was stated in[RFC7800],if an application needs to represent multiple proof-of-possessionkeys in the same SD-JWT, one way to achieve this is to use otherclaim names, in addition tocnf, to hold the additional proof-of-possession key information.¶
It is outside the scope of this document to describe how the Holder key pair isestablished. For example, the HolderMAY create a key pair and provide a public key to the Issuer,the IssuerMAY create the key pair for the Holder, orHolder and IssuerMAY use pre-established key material.¶
Note: The examples throughout this document use thecnf claim with thejwk member to includethe raw public key by value in SD-JWT.¶
Disclosures are created differently depending on whether a claim is an object property (name/value pair) or an array element.¶
For each claim that is an object property and that is to be made selectively disclosable, the IssuerMUST create a Disclosure as follows:¶
Create a JSON array of three elements in the following order:¶
_sd,..., or a claim name existing in the object as a permanently disclosed claim.¶Note: The order was decided based on readability considerations: Salts have aconstant length within the SD-JWT, claim names would be around the same lengthall the time, and claim values would vary in size, potentially being largeobjects.¶
The following example illustrates the steps described above.¶
The array is created as follows:¶
["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]¶
The resultant Disclosure is:¶
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0¶
Note that variations in whitespace, encoding of Unicode characters, ordering of object properties, etc., are allowedin the JSON representation and no canonicalization needs to be performed before base64url encoding because the digest is calculated over the base64url-encoded value itself.For example, the following strings are all valid and encode thesame claim value "Möbius":¶
A different way to encode the Unicode umlaut:¶
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNXHUwMGY2Yml1cyJd¶
No white space:¶
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Yml1cyJd¶
Newline characters between elements:¶
WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiTcO2Yml1cyIKXQ¶
However, the digest is calculated over the respective base64url-encoded value itself, which effectively signs the variation chosen by the Issuer and makes it immutable in the context of the particular SD-JWT.¶
SeeAppendix B for some further considerations on the Disclosure format approach.¶
For each claim that is an array element and that is to be made selectively disclosable, the IssuerMUST create a Disclosure as follows:¶
The arrayMUST contain two elements in this order:¶
The Disclosure string is created by base64url-encoding the UTF-8 byte sequence of the resultant JSON array as described inSection 4.2.1. The same considerations regardingvariations in the result of the JSON encoding apply.¶
For example, a Disclosure for the second element of thenationalities array in the following JWT Claims Set:¶
{ "nationalities": ["DE", "FR", "US"]}¶could be created by first creating the following array:¶
["lklxF5jMYlGTPUovMNIvCA", "FR"]¶
The resultant Disclosure would be:¶
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0¶
Note that the size of an array alone can potentially reveal unintended information.The use of decoys, as described inSection 4.2.5, to consistently pad the size of an array can help obscurethe actual number of elements present in any particular instance.¶
For embedding references to the Disclosures in the SD-JWT, each Disclosure is hashed using the hash algorithm specified in the_sd_alg claim described inSection 4.1.1, or SHA-256 if no algorithm is specified. The resultant digest is then included in the SD-JWT payload instead of the original claim value, as described next.¶
The digestMUST be computed over the US-ASCII bytes of the base64url-encoded value that is the Disclosure. This follows the convention in JWS[RFC7515] and JWE[RFC7516]. The bytes of the digestMUST then be base64url encoded.¶
It is important to note that:¶
For example, the base64url-encoded SHA-256 digest of the DisclosureWyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0for thefamily_name claim fromSection 4.2.1 above isX9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0.¶
For selectively disclosable claims, the digests of the Disclosures are embedded into the Issuer-signed JWT instead of the claims themselves. The precise way of embedding depends on whether a claim is an object property (name/value pair) or an array element.¶
Digests of Disclosures for object properties are added to an array under the newkey_sd in the object. The_sd keyMUST refer to an array of strings, eachstring being a digest of a Disclosure or a decoy digest as described inSection 4.2.5.An_sd key can be present at any level of the JSON object hierarchy, including at the top-level,nested deeper as described inSection 6, or in recursive Disclosures as described inSection 4.2.6.¶
The arrayMAY be empty in case the Issuer decided not to selectively discloseany of the claims at that level. However, it isRECOMMENDED to omit the_sdkey in this case to save space.¶
The IssuerMUST hide the original order of the claims in the array. To ensurethis, it isRECOMMENDED to shuffle the array of hashes, e.g., by sorting italphanumerically or randomly, after potentially addingdecoy digests as described inSection 4.2.5. The precise method does not matter as long as itdoes not depend on the original order of elements.¶
For example, using the digest of the Disclosure fromSection 4.2.3,the Issuer could create the following SD-JWT payload to makefamily_nameselectively disclosable:¶
{ "given_name": "Alice", "_sd": ["X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0"]}¶Digests of Disclosures for array elements are added to the array in the sameposition as the original claim value in the array. For each digest, an objectof the form{"...": "<digest>"} is added to the array. The keyMUST always be thestring... (three dots). The valueMUST be the digest of the Disclosure created asdescribed inSection 4.2.3. ThereMUST NOT be any other keys in theobject. Note that the string... was chosen because the ellipsis character, typically entered as three period characters, is commonly used in places where content is omitted from the present context.¶
For example, using the digest of the array element Disclosure created inSection 4.2.2,the Issuer could create the following SD-JWT payload to make the second elementof thenationalities array selectively disclosable:¶
{ "nationalities": ["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}, "US"]}¶As described inSection 7.3, Verifiers ignore all selectivelydisclosable array elements for which they did not receive a Disclosure. In theexample above, the verification process would output an array with only twoelements,["DE", "US"], unless the matching Disclosure for the second element is received,in which case the output would be a three-element array,["DE", "FR", "US"].¶
An IssuerMAY add additional digests to the SD-JWT payload that are not associated withany claim. The purpose of such "decoy" digests is to make it more difficult foran adversarial Verifier to see the original number of claims or array elements contained in the SD-JWT. DecoydigestsMAY be added both to the_sd array for objects as well as in arrays.¶
It isRECOMMENDED to create the decoy digests by hashing over acryptographically secure random number. The bytes of the digestMUST then bebase64url encoded as above. The same digest function as for the DisclosuresMUSTbe used.¶
For decoy digests, no Disclosure is sent to the Holder, i.e., the Holder willsee digests that do not correspond to any Disclosure. SeeSection 10.4 for additional privacy considerations.¶
To ensure readability and replicability, the examples in this specification donot contain decoy digests unless explicitly stated. For an examplewith decoy digests, seeAppendix A.1.¶
The algorithms above are compatible with "recursive Disclosures", in which oneselectively disclosed field reveals the existence of more selectivelydisclosable fields. For example, consider the following JSON structure:¶
{ "family_name": "Möbius", "nationalities": ["DE", "FR", "UK"]}¶When the Holder has multiple nationalities, the Issuer may wish to concealthe presence of any statement regarding nationalities while also allowing theHolder to reveal each of those nationalities individually.This can be accomplished by first making the entries within the "nationalities"array selectively disclosable, and then making the whole "nationalities" fieldselectively disclosable.¶
The following shows each of the entries within the "nationalities" array being made selectively disclosable:¶
{ "family_name": "Möbius", "nationalities": [ { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" } { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" }, { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" } ]}¶Content of Disclosures:¶
PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"]r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"]nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"]¶
Followed by making the whole "nationalities" array selectively disclosable:¶
{ "family_name": "Möbius", "_sd": [ "5G1srw3RG5W4pVTwSsYxeOWosRBbzd18ZoWKkC-hBL4" ]}¶Content of Disclosures:¶
PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"]r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"]nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"]5G1srw3... = ["4drfeTtSUK3aY_-PF12gcX","nationalities", [ { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" }, { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" }, { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" } ]]¶With this set of Disclosures, the Holder could include the Disclosure with hashPmnlrRj... to disclose only the "DE" nationality, or include bothPmnlrRj...andr823HFN... to disclose both the "DE" and "FR" nationalities, but hide the"UK" nationality. In either case, the Holder would also need to include theDisclosure with hash5G1srw3... to disclose thenationalities field thatcontains the respective elements.¶
Note that making recursive redactions introduces dependencies between theDisclosure objects in an SD-JWT. Ther823HFN... Disclosure cannot be usedwithout the5G1srw3... Disclosure; since a Verifier would not have a matchinghash that would tell it where the content of ther823HFN... Disclosure shouldbe inserted. If a Disclosure object is included in an SD-JWT, then the SD-JWTMUST include any other Disclosure objects necessary to process the firstDisclosure object. In other words, any Disclosure object in an SD-JWT must"connect" to the claims in the issuer-signed JWT, possibly via an intermediateDisclosure object. In the above example, it would be illegal to include any oneof thePmnlrRj...,r823HFN...,nP5GYjw... Disclosure objects without alsoincluding the5G1srw3... Disclosure object.¶
This section defines the Key Binding JWT, which encodes asignature over an SD-JWT by the Holder's private key.¶
The Key Binding JWTMUST be a JWT according to[RFC7519], and itMUST contain the following elements:¶
in the JOSE header,¶
typ:REQUIRED.MUST bekb+jwt, which explicitly types the Key Binding JWT as recommended inSection 3.11 of [RFC8725].¶alg:REQUIRED. A digital signature algorithm identifier such as per the IANA "JSON Web Signature and Encryption Algorithms" registry. ItMUST NOT be "none".¶in the JWT payload,¶
iat:REQUIRED. The value of this claimMUST be the time at which the Key Binding JWT was issued using the syntax defined in[RFC7519].¶aud:REQUIRED. The valueMUST be a single string that identifies the intended receiver of the Key Binding JWT. How the value is represented is up to the protocol used and is out of scope for this specification.¶sd_hash:REQUIRED. The base64url-encoded hash value over the Issuer-signed JWT and the selected Disclosures as defined below.¶The general extensibility model of JWT means that additional claims and header parameters can be added to the Key Binding JWT.However, unless there is a compelling reason, thisSHOULD be avoided, as it may harm interoperability and burden conceptual integrity.¶
The hash value in thesd_hash claim binds the KB-JWT to the specific SD-JWT.Thesd_hash valueMUST be computed over the US-ASCII bytes of theencoded SD-JWT, i.e.,the Issuer-signed JWT, a tilde character, and zero or more Disclosures selectedfor presentation to the Verifier, each followed by a tilde character:¶
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~¶
The bytes of the digestMUST then be base64url encoded.¶
The same hash algorithm as for the DisclosuresMUST be used (defined bythe_sd_alg element in the Issuer-signed JWT or the default value, as definedinSection 4.1.1).¶
Whether to require Key Binding is up to the Verifier's policy, based on the setof trust requirements (such as trust frameworks) it belongs to. SeeSection 9.5 for security considerations.¶
If the Verifier requires Key Binding, the VerifierMUST ensure that the key with which it validates the signature onthe Key Binding JWT is the key specified in the SD-JWT as the Holder's publickey. For example, if the SD-JWT contains acnf value with ajwk member, theVerifier would parse the provided JWK and use it to verify the Key Binding JWT.¶
Details of the validation process are defined inSection 7.3.¶
In this example, a simple SD-JWT is demonstrated. This example is split into issuance and presentation.¶
Note: Throughout the examples in this document, line breaks were added toJSON strings and base64-encoded strings to adhere to the line-length limit in RFCs and for readability. JSON does not allow line breaks within strings.¶
The following data about the user comprises the input JWT Claims Set used by the Issuer:¶
{ "sub": "user_42", "given_name": "John", "family_name": "Doe", "email": "johndoe@example.com", "phone_number": "+1-202-555-0101", "phone_number_verified": true, "address": { "street_address": "123 Main St", "locality": "Anytown", "region": "Anystate", "country": "US" }, "birthdate": "1940-01-01", "updated_at": 1570000000, "nationalities": [ "US", "DE" ]}¶In this example, the following decisions were made by the Issuer in constructing the SD-JWT:¶
nationalities array is always visible, but its contents are selectively disclosable.¶sub element as well as essential verification data (iss,exp,cnf, etc.) are always visible.¶address, the Issuer is using a flat structure, i.e., all the claimsin theaddress claim can only be disclosed in full. Other options arediscussed inSection 6.¶The following payload is used for the SD-JWT:¶
{ "_sd": [ "CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI", "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE", "PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI", "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo", "XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM", "XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE", "gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM", "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4" ], "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "sub": "user_42", "nationalities": [ { "...": "pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo" }, { "...": "7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0" } ], "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" } }}¶The respective Disclosures, created by the Issuer, are listed below.In the text below and in other locations in this specification,the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encoded SHA-256 Hash:".¶
Claimgiven_name:¶
Claimfamily_name:¶
Claimemail:¶
Claimphone_number:¶
Claimphone_number_verified:¶
Claimaddress:¶
SHA-256 Hash:¶
XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE¶
Disclosure:¶
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0¶
Contents:¶
["AJx-095VPrpTtN4QMOqROA", "address", {"street_address": "123 Main St", "locality": "Anytown", "region": "Anystate", "country": "US"}]¶
Claimbirthdate:¶
Claimupdated_at:¶
Array Entry:¶
Array Entry:¶
The payload is then signed by the Issuer to create the following Issuer-signed JWT:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBbIkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZakg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBLdVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tBTmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFrb2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpnbGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUuY29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjogInVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlGMkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz-CXo6R04b7jYrpj9mNRAvVssXou1iw¶
Adding the Disclosures produces the SD-JWT:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBbIkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZakg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBLdVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tBTmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFrb2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpnbGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUuY29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjogInVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlGMkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz-CXo6R04b7jYrpj9mNRAvVssXou1iw~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmllZCIsIHRydWVd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDAwMDAwXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0~¶
The following non-normative example shows an SD-JWT+KB asit would be sent from the Holder to the Verifier. Note that it consists of sixtilde-separated parts, with the Issuer-signed JWT as shown above in the beginning,four Disclosures (for the claimsgiven_name,family_name,address, and one of thenationalities) in the middle, and the Key Binding JWT as the last element.¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBbIkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZakg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBLdVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tBTmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFrb2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpnbGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUuY29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjogInVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlGMkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz-CXo6R04b7jYrpj9mNRAvVssXou1iw~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIjBfQWYtMkItRWhMV1g1eWRoX3cyeHp3bU82aU02NkJfMlFDRWFuSTRmVVkifQ.T3SIus2OidNl41nmVkTZVCKKhOAX97aOldMyHFiYjHm261eLiJ1YiuONFiMN8QlCmYzDlBLAdPvrXh52KaLgUQ¶
The following Key Binding JWT payload was created and signed for this presentation by the Holder:¶
{ "nonce": "1234567890", "aud": "https://verifier.example.org", "iat": 1748537244, "sd_hash": "0_Af-2B-EhLWX5ydh_w2xzwmO6iM66B_2QCEanI4fUY"}¶If the Verifier did not require Key Binding, then the Holder could havepresented the SD-JWT with selected Disclosures directly, instead of encapsulating it inan SD-JWT+KB.¶
After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:¶
{ "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "sub": "user_42", "nationalities": [ "US" ], "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" } }, "family_name": "Doe", "address": { "street_address": "123 Main St", "locality": "Anytown", "region": "Anystate", "country": "US" }, "given_name": "John"}¶Being JSON, an object in an SD-JWT payloadMAY contain name/value pairs where the value is another object or objectsMAY be elements in arrays. In SD-JWT, the Issuer decides for each claim individually, on each level of the JSON, whether or not the claim should be selectively disclosable. This choice can be made on each level independent of whether keys higher in the hierarchy are selectively disclosable.¶
From this it follows that the_sd key containing digestsMAY appear multipletimes in an SD-JWT, and likewise, thereMAY be multiple arrays within thehierarchy with each having selectively disclosable elements. Digests ofselectively disclosable claimsMAY even appear within other Disclosures.¶
The following examples illustrate some of the options an Issuer has. It is up to the Issuer to decide which structure to use, depending on, for example, the expected use cases for the SD-JWT, requirements for privacy, size considerations, or operating environment requirements. For more examples with nested structures, see AppendicesA.1 andA.2.¶
The following input JWT Claims Set is used as an example throughout this section:¶
{ "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "address": { "street_address": "Schulstr. 12", "locality": "Schulpforta", "region": "Sachsen-Anhalt", "country": "DE" }}¶Note: The following examples of the structures are non-normative and are not intended torepresent all possible options. They are also not meant to define or restricthowaddress claim can be represented in an SD-JWT.¶
The Issuer can decide to treat theaddress claim as a block that can either be disclosed completely or not at all. The following example shows that in this case, the entireaddress claim is treated as an object in the Disclosure.¶
{ "_sd": [ "fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do" ], "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "_sd_alg": "sha-256"}¶The Issuer would create the following Disclosure referenced by the one hash in the SD-JWT:¶
Claimaddress:¶
SHA-256 Hash:¶
fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do¶
Disclosure:¶
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1bHBmb3J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRyeSI6ICJERSJ9XQ¶
Contents:¶
["2GLC42sKQveCfGfryNRN9w", "address", {"street_address": "Schulstr. 12", "locality": "Schulpforta", "region": "Sachsen-Anhalt", "country": "DE"}]¶
The Issuer may instead decide to make theaddress claim contents selectively disclosable individually:¶
{ "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "address": { "_sd": [ "6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88", "WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM" ] }, "_sd_alg": "sha-256"}¶In this case, the Issuer would use the following data in the Disclosures for theaddress sub-claims:¶
The Issuer may also make one sub-claim ofaddress permanently disclosed and hide only the other sub-claims:¶
{ "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "address": { "_sd": [ "6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88" ], "country": "DE" }, "_sd_alg": "sha-256"}¶In this case, there would be no Disclosure forcountry, since it is provided in the clear.¶
The Issuer may also decide to make theaddress claim contents selectively disclosable recursively, i.e., theaddress claim is made selectively disclosable as well as its sub-claims:¶
{ "_sd": [ "HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg" ], "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "_sd_alg": "sha-256"}¶The Issuer first creates Disclosures for the sub-claims and then includes their digests in the Disclosure for theaddress claim:¶
Claimstreet_address:¶
Claimlocality:¶
Claimregion:¶
Claimcountry:¶
Claimaddress:¶
SHA-256 Hash:¶
HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg¶
Disclosure:¶
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCIsICI5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgIktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8ycm8yamZYTSJdfV0¶
Contents:¶
["Qg_O64zqAxe412a108iroA", "address", {"_sd": ["6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88", "WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]¶
Upon receiving an SD-JWT, either directly or as a component of an SD-JWT+KB, a Holderor Verifier needs to ensure that:¶
The Holder or the VerifierMUST perform the following checks when receivingan SD-JWT to validate the SD-JWT and extract the payload:¶
Validate the Issuer-signed JWT:¶
_sd_alg claim value is understood and the hash algorithm is deemed secure according to the Holder or Verifier's policy (seeSection 4.1.1).¶Process the Disclosures and embedded digests in the Issuer-signed JWT as follows:¶
For each Disclosure provided:¶
(*) Identify all embedded digests in the Issuer-signed JWT as follows:¶
(**) For each embedded digest found in the previous step:¶
If the digest was found in an object's_sd key:¶
_sd or..., the SD-JWTMUST be rejected.¶_sd key, the SD-JWTMUST be rejected.¶_sd key, a new claim using the claim name and claim value from the Disclosure.¶If the digest was found in an array element:¶
_sd keys and their contents from the Issuer-signed JWT payload. If this results in an object with no properties, it should be represented as an empty object{}.¶_sd_alg from the SD-JWT payload.¶nbf,exp, andaud in the processed payload, if present. If a required validity-controlling claim is missing (seeSection 9.7), the SD-JWTMUST be rejected.¶If any step fails, the SD-JWT is not valid, and processingMUST be aborted. Otherwise, the JSON document resulting from the preceding processing and verification steps, herein referred to as the "Processed SD-JWT Payload", can be made available to the application to be used for its intended purpose.¶
Note that these processing steps do not yield any guarantees to the Holder about having received a complete set of Disclosures. That is, for some digest values in the Issuer-signed JWT (which are not decoy digests), there may be no corresponding Disclosures, for example, if the message from the Issuer was truncated.It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the user when needed.¶
The Issuer provides the Holder with an SD-JWT, not an SD-JWT+KB. If the Holderreceives an SD-JWT+KB, itMUST be rejected.¶
When receiving an SD-JWT, the HolderMUST do the following:¶
For presentation to a Verifier, the HolderMUST perform the following (or equivalent) steps (in addition to the checks described inSection 7.1 performed after receiving the SD-JWT):¶
Verify that each selected Disclosure satisfies one of the two following conditions:¶
If Key Binding is not required:¶
If Key Binding is required:¶
Upon receiving a presentation from a Holder, in the form of either an SD-JWT oran SD-JWT+KB, in addition to the checks described inSection 7.1, Verifiers need to ensure that¶
To this end, VerifiersMUST follow the following steps (or equivalent):¶
If Key Binding is required:¶
typ of the Key Binding JWT iskb+jwt (seeSection 4.3).¶iat claim, is within an acceptable window.¶nonce andaud claims.¶sd_hash claim in the Key Binding JWT.¶If any step fails, the presentation is not valid and processingMUST be aborted.¶
Otherwise, the Processed SD-JWT Payload can be passed to the application to be used for the intended purpose.¶
This section describes an alternative format for SD-JWTs and SD-JWT+KBs using the JWS JSONSerialization from[RFC7515]. Supporting this format isOPTIONAL.¶
For both the General and Flattened JSON Serialization, the SD-JWT or SD-JWT+KB is representedas a JSON object according toSection 7.2 of [RFC7515]. The following newunprotected header parameters are defined:¶
disclosures:kb_jwt:In an SD-JWT+KB,kb_jwtMUST be present when using the JWS JSON Serialization,and the digest in thesd_hash claimMUST be computed over the SD-JWT as describedinSection 4.3.1. This means that even when usingthe JWS JSON Serialization, the representation as a regular SD-JWT Compact SerializationMUST becreated temporarily to calculate the digest. In detail, the SD-JWT Compact Serialization part is builtby concatenating the protected header, the payload, and the signature of the JWSJSON serialized SD-JWT using a. character as a separator, and using theDisclosures from thedisclosures member of the unprotected header.¶
Unprotected headers other thandisclosures are not covered by the digest, andtherefore, as usual, are not protected against tampering.¶
In the case of Flattened JSON Serialization, there is only one unprotectedheader.¶
The following is a non-normative example of a JWS JSON serialized SD-JWT asissued using the Flattened JSON Serialization:¶
{ "header": { "disclosures": [ "WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICJqb2huX2RvZV80M iJd", "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob iJd", "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ SJd", "WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImJpcnRoZGF0ZSIsICIxOTQwL TAxLTAxIl0" ] }, "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", "signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"}¶The following is an SD-JWT+KB with two Disclosures:¶
{ "header": { "disclosures": [ "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ SJd", "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob iJd" ], "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25j ZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW 1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlZqdFBz Z1pwUVRSeEtKdkRwU0otblhsWktFOVo5TGdENEZ5Q3d3b05NUncifQ.GrDvJ2j hYNmUvqdwVEIrxeTFEuI5qKSM7I6P95JmA6Wko-FBB5vPGQn0wvmdgjLCE2iDR h1r82zchjmABQ3V8w" }, "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", "signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"}¶In the case of General JSON Serialization, there are multiple unprotectedheaders (one per signature). If present,disclosures andkb_jwtMUST beincluded in the first unprotected header andMUST NOT be present in anyfollowing unprotected headers.¶
The following is a non-normative example of a presentation of a JWS JSONserialized SD-JWT, including a Key Binding JWT using the General JSONSerialization:¶
{ "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", "signatures": [ { "header": { "disclosures": [ "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgI kRvZSJd", "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiS m9obiJd" ], "kid": "issuer-key-1", "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJu b25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaW VyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNo IjogInFieUlXUDNwaFZneEVzRFJpd2R3OVc2QkozZHhpUEx1bWNZcFBidT RFYjgifQ.VyZqxaVHh1XE6M-kuax_7Laq42uFDrx17lLG2jluyKgy_PqC8 5z4DVpISdMZDdSANGs-0zN2N7xnM-E1Pg0sOw" }, "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", "signature": "dz1N3uvhVHJjldyXwppmBLieTj0vuBMbzL06rnrLIuxEQb9B HoIOwGrWh-UadW4orRpEiEtjf7xyHDONMJ6tBw" }, { "header": { "kid": "issuer-key-2" }, "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", "signature": "kuXio_U88RH_-fihAPET4AFUjj0BpxsT6yddMFIr6pfHKtAe 0FOJNWQxU42rfnORuNQNTgGsf2A8LjEba5inNg" } ]}¶Verification of the JWS JSON serialized SD-JWT follows the rules defined inSection 3.4, except for the following aspects:¶
disclosures member of the unprotected header.¶sd_hash in the Key Binding JWT of an SD-JWT+KB, the VerifierMUSTassemble the string to be hashed as described inSection 8.1.¶The security considerations help achieve the following properties:¶
A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier.¶
Additionally, as described inSection 9.5, the application of Key Binding can ensure that the presenter of an SD-JWT credential is the Holder of the credential.¶
The JWTMUST be signed by the Issuer to protect the integrity of the issuedclaims. An attacker can modify or add claims if this JWT is not signed (e.g.,change the "email" attribute to take over the victim's account or add anattribute indicating a fake academic qualification).¶
The VerifierMUST always check the signature of the Issuer-signed JWT to ensure that ithas not been tampered with since its issuance. The Issuer-signed JWTMUST be rejected if the signature cannot be verified.¶
The security of the Issuer-signed JWT depends on the security of the signature algorithm.Per the last paragraph ofSection 5.2 of [RFC7515], it is anapplication-specific decision to choose the appropriate JWSalgorithm from[JWS.Algs], including post-quantum algorithms, when they are ready.¶
Holders can manipulate the Disclosures by changing the values of the claimsbefore sending them to the Verifier. The VerifierMUST check the Disclosures toensure that the values of the claims are correct, i.e., the digests of the Disclosures are actually present in the signed SD-JWT.¶
A naive Verifier that extractsall claim values from the Disclosures (without checking the hashes) and inserts them into the SD-JWT payloadis vulnerable to this attack. However, in a structured SD-JWT, without comparing the digests of theDisclosures, such an implementation could not determine the correct place in anested object where a claim needs to be inserted. Therefore, the naive implementationwould not only be insecure, but also incorrect.¶
The steps described inSection 7.3 ensure that the Verifierchecks the Disclosures correctly.¶
The security model that conceals the plaintext claims relies on the high entropyrandom data of the salt as additional input to the hash function. The randomnessensures that the same plaintext claim value does not produce the same digest value. It alsomakes it infeasible to guess the preimage of the digest (thereby learning theplaintext claim value) by enumerating the potential valuespace for a claim into the hash function to search for a matching digest value.It is therefore vitally important that unrevealed salts cannot be learned or guessed,even if other salts have been revealed. As such, each saltMUST be createdin such a manner that it is cryptographically random, sufficiently long, andhas high enough entropy that it is infeasible to guess. Anew saltMUST be chosen for each claim independently of other salts.See "Randomness Requirements for Security"[RFC4086] for considerationson generating random values.¶
TheRECOMMENDED minimum length of the randomly generated portion of the salt is 128 bits.¶
The IssuerMUST ensure that a new salt value is chosen for each claim,including when the same claim name occurs at different places in thestructure of the SD-JWT. This can be seen in the example inAppendix A.2,where multiple claims with the nametype appear, but each of them hasa different salt.¶
To ensure privacy of claims that are selectively disclosable but are not being disclosed in a given presentation,the hash functionMUST ensure that it is infeasible to calculate any portion of the three elements(salt, claim name, claim value) from a particular digest. This implies the hash functionMUSTbe preimage resistant and should also not allow an observer to infer any partial information aboutthe undisclosed content. In the terminology of cryptographic commitment schemes, the hash functionneeds to be computationally hiding.¶
To ensure the integrity of selectively disclosable claims, the hash functionMUST be second-preimageresistant. That is, for any combination of salt, claim name, and claim value, it is infeasible to find a different combination of salt,claim name, and claim value that results in the same digest.¶
The hash functionSHOULD also be collision resistant. Although not essential to the anticipated uses ofSD-JWT, without collision resistance an Issuer may be able to find multiple Disclosures that have thesame hash value. In which case, the signature over the SD-JWT would not then commit the Issuer to the contents of theJWT. The collision resistance of the hash function used to generate digestsSHOULDmatch the collision resistance of the hash function used by the signature scheme. For example, use ofthe ES512 signature algorithm would require a Disclosure hash function with at least 256-bit collisionresistance, such as SHA-512.¶
Inclusion in the "Named Information Hash Algorithm Registry"[Hash.Algs]alone does not indicate a hash algorithm's suitability for use in SD-JWT (it contains severalheavily truncated digests, such assha-256-32 andsha-256-64, which are unfit for securityapplications).¶
Key Binding aims to ensure that the presenter of an SD-JWT credential is actually the Holder of the credential.An SD-JWT compatible with Key Binding contains a public key, or a reference to a public key, that corresponds to a private key possessed by the Holder.The Verifier requires that the Holder prove possession of that private key when presenting the SD-JWT credential.¶
Without Key Binding, a Verifier only gets the proof that thecredential was issued by a particular Issuer, but the credential itselfcan be replayed by anyone who gets access to it. This means that, forexample, after the credential was leaked to an attacker, the attacker canpresent the credential to any Verifier that does not require abinding. Also, a malicious Verifier to which the Holder presented thecredential can present the credential to another Verifier if that otherVerifier does not require Key Binding.¶
VerifiersMUST decide whether Key Binding is required for aparticular use case before verifying a credential. This decisioncan be informed by various factors including but not limited to the following:business requirements, the use case, the type ofbinding between a Holder and its credential that is required for a usecase, the sensitivity of the use case, the expected properties of acredential, the type and contents of other credentials expected to bepresented at the same time, etc.¶
It is important that a Verifier not make its security policydecisions based on data that can be influenced by an attacker. For this reason, when deciding whether or not KeyBinding is required, VerifiersMUST NOT take into accountwhether the Holder has provided an SD-JWT+KB or a bare SD-JWT; otherwise, anattacker could strip the KB-JWT from an SD-JWT+KB and present the resultant SD-JWT.¶
Furthermore, Verifiers should be aware that Key Binding information may have been added to an SD-JWT in a format that they do not recognize and therefore may not be able to tell whether or not the SD-JWT supports Key Binding.¶
If a Verifier determines that Key Binding is required for aparticular use case and the Holder presents either a bare SD-JWT or an SD-JWT+KB withan invalid Key Binding JWT, then the Verifier will reject the presentationwhen following the verification steps described inSection 7.3.¶
SD-JWT ensures that names of claims that are selectively disclosable arealways concealed unless the claim's value is disclosed. This prevents an attacker from learning the names of suchclaims. However, the names of the claims that are permanentlydisclosed are not hidden. This includes the keys of objects that themselvesare not concealed, but contain concealed claims. This limitationneeds to be taken into account by Issuers when creating the structure ofthe SD-JWT.¶
An IssuerMUST NOT allow any content to be selectively disclosable that is critical for evaluating theSD-JWT's authenticity or validity.The exact list of such content will depend on the applicationandSHOULD be listed by any application-specific profiles of SD-JWT.The following is a list of registered JWT claim names thatSHOULD be considered assecurity critical:¶
iss (Issuer)¶aud (Audience), although issuersMAY allow individual entries in the array to be selectively disclosable¶exp (Expiration Time)¶nbf (Not Before)¶cnf (Confirmation Key)¶Issuers will typically include claims controlling the validity of the SD-JWTin plaintext in the SD-JWT payload, but there is no guarantee they will do so. Therefore, Verifiers cannotreliably depend on that and need to operate as though security-critical claims might beselectively disclosable.¶
Verifiers thereforeMUST ensure that all claims they deem necessary for checkingthe validity of an SD-JWT in the given context are present (or disclosed, respectively) duringvalidation of the SD-JWT. This is implemented in the laststep of the verification defined inSection 7.1.¶
The precise set of required validity claims will typically be defined byoperating environment rules, an application-specific profile, or the credential format, andMAY include claims other thanthose listed herein.¶
This specification does not define how signature verification keys ofIssuers are distributed to Verifiers. However, it isRECOMMENDED thatIssuers publish their keys in a way that allows for efficient and securekey rotation and revocation, for example, by publishing keys at apredefined location using the JSON Web Key Set (JWKS) format[RFC7517].Verifiers need to ensure that they are not using expired or revoked keysfor signature verification using reasonable and appropriate means for the givenkey-distribution method.¶
Any entity in possession of an SD-JWT (including an SD-JWT extracted from an SD-JWT+KB) can forward it to any third partythat does not enforce Key Binding.When doing so, that entity may remove Disclosures such that the receiverlearns only a subset of the claims contained in the original SD-JWT.¶
For example, a device manufacturer might produce an SD-JWTcontaining information about upstream and downstream supply chain contributors.Each supply chain party can verify only the claims that were selectively disclosed to themby an upstream party, and they can choose to further reduce the disclosed claimswhen presenting to a downstream party.¶
In some scenarios, this behavior could be desirable;if it is not, Issuers need to support and Verifiers need to enforce Key Binding.¶
With an SD-JWT, the Issuer-signed JWT is integrity protected by the Issuer'ssignature, and the values of the Disclosures are integrity protected by the digestsincluded therein. The specific set of Disclosures, however,is not integrity protected; the SD-JWT can be modified by adding orremoving Disclosures and still be valid.¶
With an SD-JWT+KB, the set of selected Disclosures is integrity protected.The signature in the Key Binding JWT covers aspecific SD-JWT, with a specific Issuer-signed JWT and a specific set ofDisclosures. Thus, the signature on the Key Binding JWT, in addition to provingKey Binding, also assures the authenticity and integrity of the set ofDisclosures the Holder disclosed. The set of Disclosures in an SD-JWT+KB is the setthat the Holder intended to send; no intermediate party has added, removed, ormodified the list of Disclosures.¶
Section 3.11 of [RFC8725] describes the use of explicit typing as one mechanism to prevent confusion attacks(described inSection 2.8 of [RFC8725]) in which one kind of JWT is mistaken for another. SD-JWTs are also potentiallysubject to such confusion attacks, so in the absence of other techniques, it isRECOMMENDED that application profiles of SD-JWT specify an explicit typeby including thetyp header parameter when the SD-JWT is issued, and that Verifiers check this value.¶
When explicit typing using thetyp header is employed for an SD-JWT, it isRECOMMENDED that a media type name of the format"application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD-JWT.The definition oftyp inSection 4.1.9 of [RFC7515] recommends that the "application/" prefix be omitted, so"example+sd-jwt" would be the value of thetyp header parameter.¶
Use of thecty content type header parameter to indicate the content type of the SD-JWT payload can also be used to distinguish different types of JSON objects or different kinds of JWT Claim Sets.¶
Implementations of SD-JWT rely on asymmetric cryptographic keys and must therefore ensure that key pair generation,handling, storage, and lifecycle management are performed securely.¶
While the specific mechanisms for secure key management are out of scope for this document, implementersshould follow established best practices, such as those outlined in NIST SP 800-57 Part 1[NIST.SP.800-57pt1r5].This includes:¶
Appropriate key management is essential, as any compromise can lead to unauthorized disclosure or forgery of SD-JWTs.¶
Unlinkability is a property whereby adversaries are prevented from correlatingcredential presentations of the same user beyond the user's consent.Without unlinkability, an adversary might be able to learn more about the user than the userintended to disclose, for example:¶
The following types of unlinkability are discussed below:¶
In all cases, unlinkability is limited to cases where the disclosed claims donot contain information that directly or indirectly identifies the user. Forexample, when a taxpayer identification number is contained in the disclosed claims, the Issuer andVerifier can easily link the user's transactions. However, when the user onlydiscloses a birthdate to one Verifier and a postal code to another Verifier, the two Verifiers should not be able to determine that they were interacting with the same user.¶
Issuer/Verifier unlinkability with a careless, colluding, compromised, or coerced Verifier cannot beachieved in salted hash-based selective disclosure approaches, such as SD-JWT, as theissued credential with the Issuer's signature is directly presented to the Verifier, who can forward it tothe Issuer. To reduce the risk of revealing the data later on,Section 10.2 definesrequirements to reduce the amount of data stored.¶
In considering Issuer/Verifier unlinkability, it is important to note the potential for an asymmetric power dynamicbetween Issuers and Verifiers. This dynamic can compel an otherwise Honest Verifier into collusion.For example, a governmental Issuer might have the authority to mandate that a Verifier report back informationabout the credentials presented to it. Legal requirements could further enforce this, explicitly underminingIssuer/Verifier unlinkability. Similarly, a large service provider issuing credentials might implicitly pressureVerifiers into collusion by incentivizing participation in their larger operating environment.Deployers of SD-JWT must be aware of these potential power dynamics,mitigate them as much as possible, and/or make the risks transparent to the user.¶
Contrary to that, Issuer/Verifier unlinkability with an Honest Verifier can generally be achieved.However, a callback from the Verifier to the Issuer, such as a revocation check, could potentiallydisclose information about the credential's usage to the Issuer.Where such callbacks are necessary, they need to be executed in a manner thatpreserves privacy and does not disclose details about the credential to the Issuer(the mechanism described in[TSL] is an example of an approachthat discloses minimal information towards the Issuer). It isimportant to note that the timing of such requests could potentially serve as a side channel.¶
Verifier/Verifier unlinkability and presentation unlinkability can be achieved using batch issuance: A batchof credentials based on the same claims is issued to the Holder instead of justa single credential. The Holder can then use a different credential for eachVerifier or even for each session with a Verifier. New Key Binding keys andsaltsMUST be used for each credential in the batch to ensure that the Verifierscannot link the credentials using these values. Likewise, claims carrying timeinformation, likeiat,exp, andnbf,MUST either be randomized within atime period considered appropriate (e.g., randomizeiat within the last 24hours and calculateexp accordingly) or rounded (e.g., rounded down to thebeginning of the day).¶
SD-JWT only conceals the value of claims that are not revealed.It does not meet the security properties for anonymous credentials[CL01]. Inparticular, colluding Verifiers and Issuers can know when they have seen the samecredential no matter what fields have been disclosed, even when none have been disclosed.This behavior may not align with what users naturally anticipate or are guided toexpect from user-interface interactions, potentially causing them to make decisionsthey might not otherwise make. Workarounds such as batch issuance, asdescribed above, help with keepingVerifiers from linking different presentations, but cannot work for Issuer/Verifier unlinkability.This issue applies to all salted hash-based approaches,including mDL/mDoc[ISO.18013-5] and SD-CWT[SD-CWT].¶
Wherever user data is stored, it represents a potentialtarget for an attacker. This target can be of particularlyhigh value when the data is signed by a trusted authority like anofficial national identity service. For example, in OpenID Connect[OpenID.Core],signed ID Tokens can be stored by Relying Parties. In the case ofSD-JWT, Holders have to store SD-JWTs,and Issuers and Verifiers may decide to do so as well.¶
Not surprisingly, a leak of such data risks revealing private data of usersto third parties. Signed user data, the authenticity of whichcan be easily verified by third parties, further exacerbates the risk.As discussed inSection 9.5, leakedSD-JWTs may also allow attackers to impersonate Holders unless KeyBinding is enforced and the attacker does not have access to theHolder's cryptographic keys.¶
Due to these risks, and the risks described inSection 10.1, systems implementing SD-JWTSHOULD be designed to minimizethe amount of data that is stored. All involved partiesSHOULD NOT store SD-JWTslonger than strictly necessary, including in log files.¶
After Issuance, IssuersSHOULD NOT store the Issuer-signed JWT or the respectiveDisclosures.¶
HoldersSHOULD store SD-JWTs only inencrypted form, and, wherever possible, use hardware-backed encryptionin particular for the private Key Binding key. Decentralized storageof data, e.g., on user devices,SHOULD be preferred for usercredentials over centralized storage. Expired SD-JWTsSHOULD be deletedas soon as possible.¶
After Verification, VerifiersSHOULD NOT store the Issuer-signed JWT or therespective Disclosures. It may besufficient to store the result of the verification and any user data that isneeded for the application.¶
Exceptions from the rules above can be made if there are strong requirements to doso (e.g., functional requirements or legal audit requirements), secure storage canbe ensured, and the privacy impact has been assessed.¶
If an SD-JWT or SD-JWT+KB is transmitted over an insecurechannel during issuance or presentation, an adversary may be able tointercept and read the user's personal data or correlate the information with previous uses.¶
Usually, transport protocols for issuance and presentation of credentialsare designed to protect the confidentiality of the transmitted data, forexample, by requiring the use of TLS.¶
This specification therefore considers the confidentiality of the data to beprovided by the transport protocol and does not specify any encryptionmechanism.¶
ImplementersMUST ensure that the transport protocol provides confidentialityif the privacy of user data or correlation attacks by passive observers are a concern.¶
To encrypt an SD-JWT or SD-JWT+KB during transit over potentially insecure or leakage-prone channels, implementersMAY use JSON Web Encryption (JWE)[RFC7516], encapsulating the SD-JWT or SD-JWT+KB as the plaintext payload of the JWE.Especially, when an SD-JWT is transmitted via a URL and information may be stored/cached in the browser or end up in web server logs, the SD-JWTSHOULD be encrypted using JWE.¶
The use of decoy digests isRECOMMENDED when the number of claims (or the existence of particular claims) can be a side channel disclosing information about otherwise undisclosed claims. In particular, if a claim in an SD-JWT is present only if a certain condition is met (e.g., a membership number is only contained if the user is a member of a group), the IssuerSHOULD add decoy digests when the condition is not met.¶
Decoy digests increase the size of the SD-JWT. The number of decoy digests (or whether to use them at all) is a trade-off between the size of the SD-JWT and the privacy of the user's data.¶
An Issuer issuing only one type of SD-JWT might have privacy implications, because if the Holder has an SD-JWT issued by that Issuer, its type and claim names can be determined.¶
For example, if a cancer research institute only issued SD-JWTs with cancer registry information, it is possible to deduce that the Holder owning its SD-JWT is a cancer patient.¶
Moreover, the Issuer identifier alone may reveal information about the user.¶
For example, when a military organization or a drug rehabilitation center issues a vaccine credential, Verifiers can deduce that the Holder is a military member or may have a substance use disorder.¶
To mitigate this issue, a group of issuers may elect to use a common Issuer identifier. A group signature scheme outside the scope of this specification may also be used, instead of an individual signature.¶
IANA has registered the following Claims in the"JSON Web Token Claims" registry[JWT.Claims] established by[RFC7519].¶
_sd¶...¶_sd_alg¶sd_hash¶IANA has registered the following media types[RFC2046] inthe "Media Types" registry[MediaTypes] in the manner describedin[RFC6838].¶
Note: For the media type value used in thetyp header in the Issuer-signed JWTitself, seeSection 9.11.¶
To indicate that the content is an SD-JWT:¶
To indicate that the content is a JWS JSON serialized SD-JWT:¶
To indicate that the content is a Key Binding JWT:¶
IANA has registered "+sd-jwt" inthe "Structured Syntax Suffixes" registry[StructuredSuffix] inthe manner described in[RFC6838], which can be used to indicate thatthe media type is encoded as an SD-JWT.¶
The following examples are not normative and are provided forillustrative purposes only. In particular, neither the structure of the claimsnor the selection of selectively disclosable claims is normative.¶
Line breaks have been added for readability.¶
In this example, in contrast toSection 5, the Issuer decided to create a structured object for theaddress claim, allowing individual members of the claim to be disclosed separately.¶
The following data about the user comprises the input JWT Claims Set used by the Issuer:¶
{ "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "given_name": "太郎", "family_name": "山田", "email": "\"unusual email address\"@example.jp", "phone_number": "+81-80-1234-5678", "address": { "street_address": "東京都港区芝公園４丁目２−８", "locality": "東京都", "region": "港区", "country": "JP" }, "birthdate": "1940-01-01"}¶The Issuer also decided to add decoy digests to prevent the Verifier from deducing the true number of claims.¶
The following payload is used for the SD-JWT:¶
{ "_sd": [ "C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU", "Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE", "MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY", "X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g", "Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE", "fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs", "ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q", "s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U" ], "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "address": { "_sd": [ "6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E", "AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg", "PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k", "b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek", "cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ", "glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4", "rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA", "uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4" ] }, "_sd_alg": "sha-256"}¶The digests in the SD-JWT payload reference the following Disclosures:¶
Claimsub:¶
Claimgiven_name:¶
Claimfamily_name:¶
Claimemail:¶
Claimphone_number:¶
Claimstreet_address:¶
SHA-256 Hash:¶
6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E¶
Disclosure:¶
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwgIlx1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1NTcxMlx1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd¶
Contents:¶
["AJx-095VPrpTtN4QMOqROA", "street_address", "\u6771\u4eac\u90fd\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u2212\uff18"]¶
Claimlocality:¶
Claimregion:¶
Claimcountry:¶
Claimbirthdate:¶
The following decoy digests are added:¶
AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg¶cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ¶glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4¶b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek¶fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs¶Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE¶The following is a presentation of the SD-JWT that discloses onlyregionandcountry of theaddress property:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBbIkM5aW5wNllvUmFFWFI0Mjd6WUpQN1FyazFXSF84YmR3T0FfWVVyVW5HUVUiLCAiS3VldDF5QWEwSElRdlluT1ZkNTloY1ZpTzlVZzZKMmtTZnFZUkJlb3d2RSIsICJNTWxkT0ZGekIyZDB1bWxtcFRJYUdlcmhXZFVfUHBZZkx2S2hoX2ZfOWFZIiwgIlg2WkFZT0lJMnZQTjQwVjd4RXhad1Z3ejd5Um1MTmNWd3Q1REw4Ukx2NGciLCAiWTM0em1JbzBRTExPdGRNcFhHd2pCZ0x2cjE3eUVoaFlUMEZHb2ZSLWFJRSIsICJmeUdwMFdUd3dQdjJKRFFsbjFsU2lhZW9iWnNNV0ExMGJRNTk4OS05RFRzIiwgIm9tbUZBaWNWVDhMR0hDQjB1eXd4N2ZZdW8zTUhZS08xNWN6LVJaRVlNNVEiLCAiczBCS1lzTFd4UVFlVTh0VmxsdE03TUtzSVJUckVJYTFQa0ptcXhCQmY1VSJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUuY29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAiYWRkcmVzcyI6IHsiX3NkIjogWyI2YVVoelloWjdTSjFrVm1hZ1FBTzN1MkVUTjJDQzFhSGhlWnBLbmFGMF9FIiwgIkF6TGxGb2JrSjJ4aWF1cFJFUHlvSnotOS1OU2xkQjZDZ2pyN2ZVeW9IemciLCAiUHp6Y1Z1MHFiTXVCR1NqdWxmZXd6a2VzRDl6dXRPRXhuNUVXTndrclEtayIsICJiMkRrdzBqY0lGOXJHZzhfUEY4WmN2bmNXN3p3Wmo1cnlCV3ZYZnJwemVrIiwgImNQWUpISVo4VnUtZjlDQ3lWdWIyVWZnRWs4anZ2WGV6d0sxcF9KbmVlWFEiLCAiZ2xUM2hyU1U3ZlNXZ3dGNVVEWm1Xd0JUdzMyZ25VbGRJaGk4aEdWQ2FWNCIsICJydkpkNmlxNlQ1ZWptc0JNb0d3dU5YaDlxQUFGQVRBY2k0MG9pZEVlVnNBIiwgInVOSG9XWWhYc1poVkpDTkUyRHF5LXpxdDd0NjlnSkt5NVFhRnY3R3JNWDQiXX0sICJfc2RfYWxnIjogInNoYS0yNTYifQ.EOZa2YqK8j4i7cqBDkfPcTMaFsgPwcx3aYJkFoMfvV46LxL-PPqrWsIyNukB4x8Y2LT31eIHDc4Wg4XNzaqu4w~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZcdTUzM2EiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ~¶
After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:¶
{ "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "address": { "region": "港区", "country": "JP" }}¶In this example, an SD-JWT with a complex object is represented. The datastructures defined in OpenID Connect for Identity Assurance[OIDC.IDA] are used.¶
The Issuer is using the following user data as the input JWT Claims Set:¶
{ "verified_claims": { "verification": { "trust_framework": "de_aml", "time": "2012-04-23T18:25Z", "verification_process": "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7", "evidence": [ { "type": "document", "method": "pipp", "time": "2012-04-22T11:30Z", "document": { "type": "idcard", "issuer": { "name": "Stadt Augsburg", "country": "DE" }, "number": "53554554", "date_of_issuance": "2010-03-23", "date_of_expiry": "2020-03-22" } } ] }, "claims": { "given_name": "Max", "family_name": "Müller", "nationalities": [ "DE" ], "birthdate": "1956-01-28", "place_of_birth": { "country": "IS", "locality": "Þykkvabæjarklaustur" }, "address": { "locality": "Maxstadt", "postal_code": "12344", "country": "DE", "street_address": "Weidenstraße 22" } } }, "birth_middle_name": "Timotheus", "salutation": "Dr.", "msisdn": "49123456789"}¶The following payload is used for the SD-JWT:¶
{ "_sd": [ "-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw", "IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg", "otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI" ], "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "verified_claims": { "verification": { "_sd": [ "7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc", "vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw" ], "trust_framework": "de_aml", "evidence": [ { "...": "tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k" } ] }, "claims": { "_sd": [ "RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo", "S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo", "WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk", "Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk", "_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ", "hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE" ] } }, "_sd_alg": "sha-256"}¶The digests in the SD-JWT payload reference the following Disclosures:¶
Claimtime:¶
Claimverification_process:¶
Claimtype:¶
Claimmethod:¶
Claimtime:¶
Claimdocument:¶
SHA-256 Hash:¶
IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4¶
Disclosure:¶
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBlIjogImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1cmciLCAiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0IiwgImRhdGVfb2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4cGlyeSI6ICIyMDIwLTAzLTIyIn1d¶
Contents:¶
["AJx-095VPrpTtN4QMOqROA", "document", {"type": "idcard", "issuer": {"name": "Stadt Augsburg", "country": "DE"}, "number": "53554554", "date_of_issuance": "2010-03-23", "date_of_expiry": "2020-03-22"}]¶
Array Entry:¶
SHA-256 Hash:¶
tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k¶
Disclosure:¶
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDdQSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdGcldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d¶
Contents:¶
["Pc33JM2LchcU_lHggv_ufQ", {"_sd": ["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI", "G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk", "IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4", "WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]¶
Claimgiven_name:¶
Claimfamily_name:¶
Claimnationalities:¶
Claimbirthdate:¶
Claimplace_of_birth:¶
SHA-256 Hash:¶
RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo¶
Disclosure:¶
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwgeyJjb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1MDBlNmphcmtsYXVzdHVyIn1d¶
Contents:¶
["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", {"country": "IS", "locality": "\u00deykkvab\u00e6jarklaustur"}]¶
Claimaddress:¶
SHA-256 Hash:¶
_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ¶
Disclosure:¶
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2FsaXR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0¶
Contents:¶
["y1sVU5wdfJahVdgwPgS7RQ", "address", {"locality": "Maxstadt", "postal_code": "12344", "country": "DE", "street_address": "Weidenstra\u00dfe 22"}]¶
Claimbirth_middle_name:¶
Claimsalutation:¶
Claimmsisdn:¶
The following is a presentation of the SD-JWT:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBbIi1hU3puSWQ5bVdNOG9jdVFvbENsbHN4VmdncTEtdkhXNE90bmhVdFZtV3ciLCAiSUticllObjN2QTdXRUZyeXN2YmRCSmpERFVfRXZRSXIwVzE4dlRScFVTZyIsICJvdGt4dVQxNG5CaXd6TkozTVBhT2l0T2w5cFZuWE9hRUhhbF94a3lOZktJIl0sICJpc3MiOiAiaHR0cHM6Ly9pc3N1ZXIuZXhhbXBsZS5jb20iLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6IDE4ODMwMDAwMDAsICJ2ZXJpZmllZF9jbGFpbXMiOiB7InZlcmlmaWNhdGlvbiI6IHsiX3NkIjogWyI3aDRVRTlxU2N2REtvZFhWQ3VvS2ZLQkpwVkJmWE1GX1RtQUdWYVplM1NjIiwgInZUd2UzcmFISUZZZ0ZBM3hhVUQyYU14Rno1b0RvOGlCdTA1cUtsT2c5THciXSwgInRydXN0X2ZyYW1ld29yayI6ICJkZV9hbWwiLCAiZXZpZGVuY2UiOiBbeyIuLi4iOiAidFlKMFREdWN5WlpDUk1iUk9HNHFSTzV2a1BTRlJ4RmhVRUxjMThDU2wzayJ9XX0sICJjbGFpbXMiOiB7Il9zZCI6IFsiUmlPaUNuNl93NVpIYWFka1FNcmNRSmYwSnRlNVJ3dXJSczU0MjMxRFRsbyIsICJTXzQ5OGJicEt6QjZFYW5mdHNzMHhjN2NPYW9uZVJyM3BLcjdOZFJtc01vIiwgIldOQS1VTks3Rl96aHNBYjlzeVdPNklJUTF1SGxUbU9VOHI4Q3ZKMGNJTWsiLCAiV3hoX3NWM2lSSDliZ3JUQkppLWFZSE5DTHQtdmpoWDFzZC1pZ09mXzlsayIsICJfTy13SmlIM2VuU0I0Uk9IbnRUb1FUOEptTHR6LW1oTzJmMWM4OVhvZXJRIiwgImh2RFhod21HY0pRc0JDQTJPdGp1TEFjd0FNcERzYVUwbmtvdmNLT3FXTkUiXX19LCAiX3NkX2FsZyI6ICJzaGEtMjU2In0.QoWYWtikm-AtjmPnNVshbGXQl5raEz15PByTmZwfTQg9W2O3oR6j2tMmysTZZawdo6mNLR_PsZSI25qrUpiNTg~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1QxODoyNVoiXQ~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDdQSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdGcldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTAwZmNsbGVyIl0~WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2FsaXR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0~¶
The Verifier will have this Processed SD-JWT Payload available after validation:¶
{ "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "verified_claims": { "verification": { "trust_framework": "de_aml", "evidence": [ { "method": "pipp" } ], "time": "2012-04-23T18:25Z" }, "claims": { "given_name": "Max", "family_name": "Müller", "address": { "locality": "Maxstadt", "postal_code": "12344", "country": "DE", "street_address": "Weidenstraße 22" } } }}¶This example shows how the artifacts defined in this specification could be used in the context of SD-JWT-based Verifiable Credentials (SD-JWT VC)[SD-JWT-VC] to represent a hypothetical identity credential with the data of a fictional German citizen.¶
Key Binding is appliedusing the Holder's public key passed in acnf claim in the SD-JWT.¶
The following citizen data is the input JWT Claims Set:¶
{ "vct": "urn:eudi:pid:de:1", "iss": "https://pid-issuer.bund.de.example", "given_name": "Erika", "family_name": "Mustermann", "birthdate": "1963-08-12", "address": { "street_address": "Heidestraße 17", "locality": "Köln", "postal_code": "51147", "country": "DE" }, "nationalities": [ "DE" ], "sex": 2, "birth_family_name": "Gabler", "place_of_birth": { "locality": "Berlin", "country": "DE" }, "age_equal_or_over": { "12": true, "14": true, "16": true, "18": true, "21": true, "65": false }, "age_in_years": 62, "age_birth_year": 1963, "issuance_date": "2020-03-11", "expiry_date": "2030-03-12", "issuing_authority": "DE", "issuing_country": "DE"}¶The following is the issued SD-JWT:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJXclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0FrYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWkwQnFoV3FaM3dxRDRqRi1xREdrIiwgIkkwMGZjRlVvRFhDdWNwNXl5MnVqcVBzc0RWR2FXTmlVbGlOel9hd0QwZ2MiLCAiS2pBWGdBQTlONVdIRUR0UkloNHU1TW4xWnNXaXhoaFdBaVgtQTRRaXdnQSIsICJMYWk2SVU2ZDdHUWFnWFI3QXZHVHJuWGdTbGQzejhFSWdfZnYzZk9aMVdnIiwgIkxlemphYlJxaVpPWHpFWW1WWmY4Uk1pOXhBa2QzX00xTFo4VTdFNHMzdTQiLCAiUlR6M3FUbUZOSGJwV3JyT01aUzQxRjQ3NGtGcVJ2M3ZJUHF0aDZQVWhsTSIsICJXMTRYSGJVZmZ6dVc0SUZNanBTVGIxbWVsV3hVV2Y0Tl9vMmxka2tJcWM4IiwgIldUcEk3UmNNM2d4WnJ1UnBYemV6U2JrYk9yOTNQVkZ2V3g4d29KM2oxY0UiLCAiX29oSlZJUUlCc1U0dXBkTlM0X3c0S2IxTUhxSjBMOXFMR3NoV3E2SlhRcyIsICJ5NTBjemMwSVNDaHlfYnNiYTFkTW9VdUFPUTVBTW1PU2ZHb0VlODF2MUZVIl0sICJpc3MiOiAiaHR0cHM6Ly9waWQtaXNzdWVyLmJ1bmQuZGUuZXhhbXBsZSIsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgInZjdCI6ICJ1cm46ZXVkaTpwaWQ6ZGU6MSIsICJfc2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlGMkhaUSJ9fX0.ZOZQTqmq8X1mCyFXi0wbV8xjctX1AlEa5TkdnkKOyWvLfW40XDb5oj9tzkgwff5s44IDnrfAdgLtmTcojs97_Q~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJpa2EiXQ~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11c3Rlcm1hbm4iXQ~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA4LTEyIl0~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwgIkhlaWRlc3RyYVx1MDBkZmUgMTciXQ~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAwZjZsbiJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUxMTQ3Il0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiQUxaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3OCIsICJEX19XX3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNfdzlrIiwgImVCcENYVTFKNWRoSDJnNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZb1BobzAiLCAieE9QeTktZ0pBTEs2VWJXS0ZMUjg1Y09CeVVEM0FiTndGZzNJM1lmUUVfSSJdfV0~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgInNleCIsIDJd~WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX2ZhbWlseV9uYW1lIiwgIkdhYmxlciJd~WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImxvY2FsaXR5IiwgIkJlcmxpbiJd~WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImNvdW50cnkiLCAiREUiXQ~WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwgeyJfc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BNalphR2t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVaY2xGSFhmLVVTUSJdfV0~WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0~WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0~WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0~WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0~WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1ZV0~WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd~WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiwgeyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlkaHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ~WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3IiwgImFnZV9pbl95ZWFycyIsIDYyXQ~WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgImFnZV9iaXJ0aF95ZWFyIiwgMTk2M10~WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgImlzc3VhbmNlX2RhdGUiLCAiMjAyMC0wMy0xMSJd~WyI0S3lSMzJvSVp0LXprV3ZGcWJVTEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzAtMDMtMTIiXQ~WyJjaEJDc3loeWgtSjg2SS1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5IiwgIkRFIl0~WyJmbE5QMW5jTXo5TGctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJERSJd~¶
The following payload is used for the SD-JWT:¶
{ "_sd": [ "0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg", "1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow", "2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8", "6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os", "78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM", "90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk", "I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc", "KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA", "Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg", "LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4", "RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM", "W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8", "WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE", "_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs", "y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU" ], "iss": "https://pid-issuer.bund.de.example", "iat": 1683000000, "exp": 1883000000, "vct": "urn:eudi:pid:de:1", "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" } }}¶The digests in the SD-JWT payload reference the following Disclosures:¶
Claimgiven_name:¶
Claimfamily_name:¶
Claimbirthdate:¶
Claimstreet_address:¶
Claimlocality:¶
Claimpostal_code:¶
Claimcountry:¶
Claimaddress:¶
SHA-256 Hash:¶
RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM¶
Disclosure:¶
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiQUxaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3OCIsICJEX19XX3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNfdzlrIiwgImVCcENYVTFKNWRoSDJnNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZb1BobzAiLCAieE9QeTktZ0pBTEs2VWJXS0ZMUjg1Y09CeVVEM0FiTndGZzNJM1lmUUVfSSJdfV0¶
Contents:¶
["G02NSrQfjFXQ7Io09syajA", "address", {"_sd": ["ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8", "D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k", "eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0", "xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I"]}]¶
Claimnationalities:¶
Claimsex:¶
Claimbirth_family_name:¶
Claimlocality:¶
Claimcountry:¶
Claimplace_of_birth:¶
SHA-256 Hash:¶
1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow¶
Disclosure:¶
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwgeyJfc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BNalphR2t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVaY2xGSFhmLVVTUSJdfV0¶
Contents:¶
["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd": ["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE", "YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ"]}]¶
Claim12:¶
Claim14:¶
Claim16:¶
Claim18:¶
Claim21:¶
Claim65:¶
Claimage_equal_or_over:¶
SHA-256 Hash:¶
2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8¶
Disclosure:¶
WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiwgeyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlkaHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ¶
Contents:¶
["eK5o5pHfgupPpltj1qhAJw", "age_equal_or_over", {"_sd": ["1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk", "CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg", "a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg", "gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU", "hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI", "y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI"]}]¶
Claimage_in_years:¶
Claimage_birth_year:¶
Claimissuance_date:¶
Claimexpiry_date:¶
Claimissuing_authority:¶
Claimissuing_country:¶
The following is an example of an SD-JWT+KB that discloses only nationality and the fact that the person is over 18 years old:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJXclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0FrYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWkwQnFoV3FaM3dxRDRqRi1xREdrIiwgIkkwMGZjRlVvRFhDdWNwNXl5MnVqcVBzc0RWR2FXTmlVbGlOel9hd0QwZ2MiLCAiS2pBWGdBQTlONVdIRUR0UkloNHU1TW4xWnNXaXhoaFdBaVgtQTRRaXdnQSIsICJMYWk2SVU2ZDdHUWFnWFI3QXZHVHJuWGdTbGQzejhFSWdfZnYzZk9aMVdnIiwgIkxlemphYlJxaVpPWHpFWW1WWmY4Uk1pOXhBa2QzX00xTFo4VTdFNHMzdTQiLCAiUlR6M3FUbUZOSGJwV3JyT01aUzQxRjQ3NGtGcVJ2M3ZJUHF0aDZQVWhsTSIsICJXMTRYSGJVZmZ6dVc0SUZNanBTVGIxbWVsV3hVV2Y0Tl9vMmxka2tJcWM4IiwgIldUcEk3UmNNM2d4WnJ1UnBYemV6U2JrYk9yOTNQVkZ2V3g4d29KM2oxY0UiLCAiX29oSlZJUUlCc1U0dXBkTlM0X3c0S2IxTUhxSjBMOXFMR3NoV3E2SlhRcyIsICJ5NTBjemMwSVNDaHlfYnNiYTFkTW9VdUFPUTVBTW1PU2ZHb0VlODF2MUZVIl0sICJpc3MiOiAiaHR0cHM6Ly9waWQtaXNzdWVyLmJ1bmQuZGUuZXhhbXBsZSIsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgInZjdCI6ICJ1cm46ZXVkaTpwaWQ6ZGU6MSIsICJfc2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlGMkhaUSJ9fX0.ZOZQTqmq8X1mCyFXi0wbV8xjctX1AlEa5TkdnkKOyWvLfW40XDb5oj9tzkgwff5s44IDnrfAdgLtmTcojs97_Q~WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiwgeyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlkaHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ~WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlBqTVlmTTA3VmJKZE14TElsdXZSTmI4OEpGbGpTWDRuLUc0M1VjX0JTUk0ifQ.f3TeS_1BWEG78EbIJRh5wgv8nYumk7euzu6xgbgpNB4pbQQqgRPWK-vQjlhhgU1EFGZ9LFakFX_0mgul1G_3mw¶
This is the payload of the corresponding Key Binding JWT:¶
{ "nonce": "1234567890", "aud": "https://verifier.example.org", "iat": 1748537244, "sd_hash": "PjMYfM07VbJdMxLIluvRNb88JFljSX4n-G43Uc_BSRM"}¶After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:¶
{ "iss": "https://pid-issuer.bund.de.example", "iat": 1683000000, "exp": 1883000000, "vct": "urn:eudi:pid:de:1", "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" } }, "age_equal_or_over": { "18": true }, "nationalities": [ "DE" ]}¶This non-normative example illustrates how the artifacts defined in this specificationcould be used to express a W3C Verifiable Credentials Data Model v2.0 payload[VC_DATA_v2.0].¶
Key Binding is appliedusing the Holder's public key passed in acnf claim in the SD-JWT.¶
The following is the input JWT Claims Set:¶
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://w3id.org/vaccination/v1" ], "type": [ "VerifiableCredential", "VaccinationCertificate" ], "issuer": "https://example.com/issuer", "issuanceDate": "2023-02-09T11:01:59Z", "expirationDate": "2028-02-08T11:01:59Z", "name": "COVID-19 Vaccination Certificate", "description": "COVID-19 Vaccination Certificate", "credentialSubject": { "vaccine": { "type": "Vaccine", "atcCode": "J07BX03", "medicinalProductName": "COVID-19 Vaccine Moderna", "marketingAuthorizationHolder": "Moderna Biotech" }, "nextVaccinationDate": "2021-08-16T13:40:12Z", "countryOfVaccination": "GE", "dateOfVaccination": "2021-06-23T13:40:12Z", "order": "3/3", "recipient": { "type": "VaccineRecipient", "gender": "Female", "birthDate": "1961-08-17", "givenName": "Marion", "familyName": "Mustermann" }, "type": "VaccinationEvent", "administeringCentre": "Praxis Sommergarten", "batchNumber": "1626382736", "healthProfessional": "883110000015376" }}¶The following is the issued SD-JWT:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjogImh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIzLTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDExOjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlIiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlIiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhiWlk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3NGdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5eDFYc3RJaVM2QjFZYmwySlo0IiwgIlRDbXpybDdLMmdldl9kdTdwY01JeXpSTEhwLVllZy1GbF9jeHRyVXZQeGciLCAiVjdrSkJMSzc4VG1WRE9tcmZKN1p1VVBIdUtfMmNjN3laUmE0cVYxdHh3TSIsICJiMGVVc3ZHUC1PRERkRm9ZNE5semxYYzN0RHNsV0p0Q0pGNzVOdzhPal9nIiwgInpKS19lU01YandNOGRYbU1aTG5JOEZHTTA4ekozX3ViR2VFTUotNVRCeTAiXSwgInZhY2NpbmUiOiB7Il9zZCI6IFsiMWNGNWhMd2toTU5JYXFmV0pyWEk3Tk1XZWRMLTlmNlkyUEE1MnlQalNaSSIsICJIaXk2V1d1ZUxENWJuMTYyOTh0UHY3R1hobWxkTURPVG5CaS1DWmJwaE5vIiwgIkxiMDI3cTY5MWpYWGwtakM3M3ZpOGViT2o5c214M0MtX29nN2dBNFRCUUUiXSwgInR5cGUiOiAiVmFjY2luZSJ9LCAicmVjaXBpZW50IjogeyJfc2QiOiBbIjFsU1FCTlkyNHEwVGg2T0d6dGhxLTctNGw2Y0FheHJZWE9HWnBlV19sbkEiLCAiM256THE4MU0yb04wNndkdjFzaEh2T0VKVnhaNUtMbWREa0hFREpBQldFSSIsICJQbjFzV2kwNkc0TEpybm4tX1JUMFJiTV9IVGR4blBKUXVYMmZ6V3ZfSk9VIiwgImxGOXV6ZHN3N0hwbEdMYzcxNFRyNFdPN01HSnphN3R0N1FGbGVDWDRJdHciXSwgInR5cGUiOiAiVmFjY2luZVJlY2lwaWVudCJ9LCAidHlwZSI6ICJWYWNjaW5hdGlvbkV2ZW50In0sICJfc2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlGMkhaUSJ9fX0.OZomvwO8iw4db89MYCeeomBVStXkT6u7G7FkicPWZnd2_hGgr0l_u1NHgPVocuOt-m32Uu6kwtPmYFxKk0AOeA~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGUiLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0aW9uIiwgIkdFIl0~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYxLTA4LTE3Il0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJpb24iXQ~WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVzdGVybWFubiJd~WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd~WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzODI3MzYiXQ~WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCIsICI4ODMxMTAwMDAwMTUzNzYiXQ~¶
The following payload is used for the SD-JWT:¶
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://w3id.org/vaccination/v1" ], "type": [ "VerifiableCredential", "VaccinationCertificate" ], "issuer": "https://example.com/issuer", "issuanceDate": "2023-02-09T11:01:59Z", "expirationDate": "2028-02-08T11:01:59Z", "name": "COVID-19 Vaccination Certificate", "description": "COVID-19 Vaccination Certificate", "credentialSubject": { "_sd": [ "1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww", "JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg", "R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4", "TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg", "V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM", "b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g", "zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0" ], "vaccine": { "_sd": [ "1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI", "Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo", "Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE" ], "type": "Vaccine" }, "recipient": { "_sd": [ "1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA", "3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI", "Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU", "lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw" ], "type": "VaccineRecipient" }, "type": "VaccinationEvent" }, "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" } }}¶The digests in the SD-JWT payload reference the following Disclosures:¶
ClaimatcCode:¶
ClaimmedicinalProductName:¶
ClaimmarketingAuthorizationHolder:¶
ClaimnextVaccinationDate:¶
ClaimcountryOfVaccination:¶
ClaimdateOfVaccination:¶
Claimorder:¶
Claimgender:¶
ClaimbirthDate:¶
ClaimgivenName:¶
ClaimfamilyName:¶
ClaimadministeringCentre:¶
ClaimbatchNumber:¶
ClaimhealthProfessional:¶
This is an example of an SD-JWT+KB that discloses onlytype,medicinalProductName,atcCode of the vaccine,type of therecipient,type,order, anddateOfVaccination:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjogImh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIzLTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDExOjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlIiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlIiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhiWlk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3NGdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5eDFYc3RJaVM2QjFZYmwySlo0IiwgIlRDbXpybDdLMmdldl9kdTdwY01JeXpSTEhwLVllZy1GbF9jeHRyVXZQeGciLCAiVjdrSkJMSzc4VG1WRE9tcmZKN1p1VVBIdUtfMmNjN3laUmE0cVYxdHh3TSIsICJiMGVVc3ZHUC1PRERkRm9ZNE5semxYYzN0RHNsV0p0Q0pGNzVOdzhPal9nIiwgInpKS19lU01YandNOGRYbU1aTG5JOEZHTTA4ekozX3ViR2VFTUotNVRCeTAiXSwgInZhY2NpbmUiOiB7Il9zZCI6IFsiMWNGNWhMd2toTU5JYXFmV0pyWEk3Tk1XZWRMLTlmNlkyUEE1MnlQalNaSSIsICJIaXk2V1d1ZUxENWJuMTYyOTh0UHY3R1hobWxkTURPVG5CaS1DWmJwaE5vIiwgIkxiMDI3cTY5MWpYWGwtakM3M3ZpOGViT2o5c214M0MtX29nN2dBNFRCUUUiXSwgInR5cGUiOiAiVmFjY2luZSJ9LCAicmVjaXBpZW50IjogeyJfc2QiOiBbIjFsU1FCTlkyNHEwVGg2T0d6dGhxLTctNGw2Y0FheHJZWE9HWnBlV19sbkEiLCAiM256THE4MU0yb04wNndkdjFzaEh2T0VKVnhaNUtMbWREa0hFREpBQldFSSIsICJQbjFzV2kwNkc0TEpybm4tX1JUMFJiTV9IVGR4blBKUXVYMmZ6V3ZfSk9VIiwgImxGOXV6ZHN3N0hwbEdMYzcxNFRyNFdPN01HSnphN3R0N1FGbGVDWDRJdHciXSwgInR5cGUiOiAiVmFjY2luZVJlY2lwaWVudCJ9LCAidHlwZSI6ICJWYWNjaW5hdGlvbkV2ZW50In0sICJfc2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlGMkhaUSJ9fX0.OZomvwO8iw4db89MYCeeomBVStXkT6u7G7FkicPWZnd2_hGgr0l_u1NHgPVocuOt-m32Uu6kwtPmYFxKk0AOeA~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIklvV1VIOTFsbGYzWEVybDQyYlEzc3hfNTNWMW8xdWpDejA4aERxSEs3RGsifQ.n0vzyIwCFMDVauEaeJIWEKZZchxXMpXTQewHgAkARbOSZxB09IbXXtHfpoGqO_BtNFN2lShJEIQBGyc-XpHigA¶
After the validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:¶
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://w3id.org/vaccination/v1" ], "type": [ "VerifiableCredential", "VaccinationCertificate" ], "issuer": "https://example.com/issuer", "issuanceDate": "2023-02-09T11:01:59Z", "expirationDate": "2028-02-08T11:01:59Z", "name": "COVID-19 Vaccination Certificate", "description": "COVID-19 Vaccination Certificate", "credentialSubject": { "vaccine": { "type": "Vaccine", "atcCode": "J07BX03", "medicinalProductName": "COVID-19 Vaccine Moderna" }, "recipient": { "type": "VaccineRecipient" }, "type": "VaccinationEvent", "order": "3/3", "dateOfVaccination": "2021-06-23T13:40:12Z" }, "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" } }}¶The following Elliptic Curve public key, represented in JWK format, can be used to validate the Issuer signatures in the above examples:¶
{ "kty": "EC", "crv": "P-256", "x": "b28d4MwZMjw8-00CG4xfnn9SLMVMM19SlqZpVb_uNtQ", "y": "Xv5zWwuoaTgdS6hV43yI6gBwTnjukmFQQnJ_kCxzqk8"}¶The public key used to validate a Key Binding JWT can be found in the examples as the content of thecnf claim.¶
As described inSection 4.2, the Disclosure structure is JSON containing a salt and thecleartext content of a claim, which is base64url encoded. The encoded value is the input used to calculatea digest for the respective claim. The inclusion of digest value in the signed JWT ensures the integrity ofthe claim value. Using encoded content as the input to the integrity mechanism is conceptually similar to theapproach in JWS and particularly useful when the content, like JSON, can have different representations but is semantically equivalent, thus avoiding canonicalization. Some further discussion of the considerations around this design decision follows.¶
When receiving an SD-JWT, a Verifier mustbe able to recompute digests of the disclosed claim values and, giventhe same input values, obtain the same digest values as signed by theIssuer.¶
Usually, JSON-based formats transport claim values as simple properties of a JSON object such as this:¶
... "family_name": "Möbius", "address": { "street_address": "Schulstr. 12", "locality": "Schulpforta" }...¶However, a problem arises when computation over the data needs to be performed and verified, like signing or computing digests. Common signature schemes require the same byte string as input to thesignature verification as was used for creating the signature. In the digest approach outlined above, the same problem exists: for the Issuer and theVerifier to arrive at the same digest, the same byte string must be hashed.¶
JSON, however, does not prescribe a unique encoding for data, but allows for variations in the encoded string. The data above, for example, can be encoded as¶
..."family_name": "M\u00f6bius","address": { "street_address": "Schulstr. 12", "locality": "Schulpforta"}...¶or as¶
..."family_name": "Möbius","address": {"locality":"Schulpforta", "street_address": "Schulstr. 12"}...¶The two representations of the value infamily_name are very different on the byte level, but they yieldequivalent objects. The same is true for the representations ofaddress, which vary in white space and order of elements in the object.¶
The variations in white space, ordering of object properties, andencoding of Unicode characters are all allowed by the JSONspecification, including further variations, e.g., concerningfloating-point numbers, as described in[RFC8785]. Variations can beintroduced whenever JSON data is serialized or deserialized and unlessdealt with, will lead to different digests and the inability to verifysignatures.¶
There are generally two approaches to deal with this problem:¶
Mixed approaches are conceivable, i.e., transferring both the original JSON dataand a string suitable for computing a digest, but such approaches can easily lead toundetected inconsistencies resulting in time-of-check-time-of-use type securityvulnerabilities.¶
In this specification, the source string hardening approach is used, asit allows for simple and reliable interoperability without therequirement for a canonicalization library. To harden the source string,any serialization format that supports the necessary data types couldbe used in theory, like protobuf, msgpack, or pickle. In thisspecification, JSON is used and plaintext contents of each Disclosure are encoded using base64url encodingfor transport. This approach means that SD-JWTs can be implemented purely basedon widely available JWT, JSON, and Base64 encoding and decoding libraries.¶
A Verifier can then easily check the digest over the source string beforeextracting the original JSON data. Variations in the encoding of the sourcestring are implicitly tolerated by the Verifier, as the digest is computed over apredefined byte string and not over a JSON object.¶
It is important to note that the Disclosures are neither intended norsuitable for direct consumption byan application that needs to access the disclosed claim values after the verification by the Verifier. TheDisclosures are only intended to be used by a Verifier to checkthe digests over the source strings and to extract the original JSONdata. The original JSON data is then used by the application. SeeSection 7.3 for details.¶
We would like to thankAlen Horvat,Alex Hodder,Anders Rundgren,Arjan Geluk,Chad Parry,Christian Bormann,Christian Paquin,Dale Bowie,Dan Moore,David Bakker,David Waite,Deb Cooley,Fabian Hauck,Filip Skokan,Giuseppe De Marco,Jacob Ward,Jeffrey Yasskin,John Preuß Mattsson,Joseph Heenan,Justin Richer,Kushal Das,Martin Thomson,Matthew Miller,Michael Fraser,Michael B. Jones,Mike Prorock,Nat Sakimura,Neil Madden,Oliver Terbu,Orie Steele,Paul Bastian,Peter Altmann,Pieter Kasselman,Richard Barnes,Rohan Mahy,Roman Danyliw,Ryosuke Abe,Sami Rosendahl,Shawn Butterfield,Shawn Emery,Simon Schulz,Takahiko Kawasaki,Tobias Looker,Torsten Lodderstedt,Vittorio Bertocci,Watson Ladd,andYaron Sheffer for their contributions (some of whichwere substantial) to this document and to the initial set of implementations.¶
The work on this document was started at the OAuth Security Workshop 2022 in Trondheim,Norway.¶