Selective Disclosure for JWTs (SD-JWT)

Selective Disclosure for JWTs (SD-JWT) Authlete

mail@danielfett.de https://danielfett.de/

Keio University

kristina@sfc.keio.ac.jp

Ping Identity

bcampbell@pingidentity.com

Security Web Authorization Protocol security oauth2 This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure. It encompasses various applications, including but not limited to the selective disclosure of JSON Web Token (JWT) claims. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies conventions for creating JSON Web Signature (JWS) structures with JSON objects as the payload while supporting selective disclosure of individual elements of that JSON. Because JSON Web Token (JWT) is a very prevalent application of JWS with a JSON payload, the selective disclosure of JWT claims receives primary treatment herein. However, that does not preclude the mechanism's applicability to other or more general applications of JWS with JSON payloads. The JSON-based representation of claims in a signed JWT is secured against modification using JWS digital signatures. A consumer of a signed JWT that has checked the signature can safely assume that the contents of the token have not been modified. However, anyone receiving an unencrypted JWT can read all the claims. Likewise, anyone with the decryption key receiving encrypted JWT can also read all the claims. One of the common use cases of a signed JWT is representing a user's identity. As long as the signed JWT is one-time use, it typically only contains those claims the user has consented to disclose to a specific Verifier. However, there is an increasing number of use cases where a signed JWT is created once and then used a number of times by the user (the "Holder" of the JWT). In such use cases, the signed JWT needs to contain the superset of all claims the user of the signed JWT might want to disclose to Verifiers at some point. The ability to selectively disclose a subset of these claims depending on the Verifier becomes crucial to ensure minimum disclosure and prevent Verifiers from obtaining claims irrelevant for the transaction at hand. SD-JWTs defined in this document enable such selective disclosure of JWT claims. One example of a multi-use JWT is a verifiable credential, an Issuer-signed credential that contains the claims about a subject, and whose authenticity can be cryptographically verified. Similar to the JWT specification on which it builds, this document is a product of the Web Authorization Protocol (oauth) working group. However, while both JWT and SD-JWT have potential OAuth 2.0 applications, their utility and application is certainly not constrained to OAuth 2.0. JWT was developed as a general-purpose token format and has seen widespread usage in a variety of applications. SD-JWT is a selective disclosure mechanism for JWT and is similarly intended to be general-purpose specification. While JWTs with claims describing natural persons are a common use case, the mechanisms defined in this document can be used for other use cases as well. In an SD-JWT, claims can be hidden, but cryptographically protected against undetected modification. "Claims" here refers to both object properties (name-value pairs) as well as array elements. When issuing the SD-JWT to the Holder, the Issuer includes the cleartext counterparts of all hidden claims, the so-called Disclosures, outside the signed part of the SD-JWT. The Holder decides which claims to disclose to a particular Verifier and includes the respective Disclosures in the SD-JWT to that Verifier. The Verifier has to verify that all disclosed claim values were part of the original Issuer-signed JWT. The Verifier will not, however, learn any claim values not disclosed in the Disclosures. This document also defines a format for SD-JWTs with Key Binding (SD-JWT+KB). By optionally sending an SD-JWT+KB to a Verifier, the Holder can prove to the Verifier that they hold the private key associated to the SD-JWT (i.e., using the cnf claim ). The strength of the binding is conditional upon the trust in the protection of the private key of the key pair an SD-JWT is bound to. SD-JWT can be used with any JSON-based representation of claims, including JSON-LD. This specification aims to be easy to implement and to leverage established and widely used data formats and cryptographic algorithms wherever possible.

Feature Summary This specification defines two primary data formats:

SD-JWT is a composite structure enabling selective disclosure of its contents. The definition in this document comprises the following:
- A format for enabling selective disclosure in nested JSON data structures, supporting selectively disclosable object properties (name-value pairs) and array elements
- A format for encoding the selectively disclosable data items
- A format extending the JWS Compact Serialization, allowing for the combined transport of the Issuer-signed JSON data structure and the disclosable data items
- An alternate format extending the JWS JSON Serialization, also allowing for transport of the Issuer-signed JSON data structure and disclosure data
SD-JWT+KB is a composite structure enabling cryptographic key binding when presented to the Verifier. The definition in this document comprises the following:
- A facility for associating an SD-JWT to a key pair
- A format for a Key Binding JWT (KB-JWT) that proves possession of the private key of the associated key pair
- A format extending the SD-JWT format for the combined transport of the SD-JWT and the KB-JWT

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here. base64url denotes the URL-safe base64 encoding without padding defined in Section 2 of .

Terms and Definitions

Selective disclosure:: Process of a Holder disclosing to a Verifier a subset of claims contained in a claim set issued by an Issuer.
Selectively Disclosable JWT (SD-JWT):: A composite structure, consisting of an Issuer-signed JWT (JWS, ) and zero or more Disclosures, which supports selective disclosure as defined in this document. It can contain both regular claims and digests of selectively-disclosable claims.
Disclosure:: A JSON array containing a combination of a salt, a cleartext claim name (present when the claim is a name-value pair and absent when the claim is an array element), and a cleartext claim value, which is base64url-encoded and used to calculate a digest for the respective claim. The term Disclosure refers to the whole base64url-encoded string.
Key Binding:: Ability of the Holder to prove legitimate possession of an SD-JWT by proving control over a private key during the presentation. When utilizing Key Binding, an SD-JWT contains the public key corresponding to the private key controlled by the Holder (or a reference to this public key).
Key Binding JWT (KB-JWT):: A JWT for proving Key Binding as defined in . A Key Binding JWT is said to "be tied to" a particular SD-JWT when its payload includes a hash of the SD-JWT in its sd_hash claim.
Selectively Disclosable JWT with Key Binding (SD-JWT+KB):: A composite structure, comprising an SD-JWT and a Key Binding JWT tied to that SD-JWT.
Issuer:: An entity that creates SD-JWTs.
Holder:: An entity that received SD-JWTs from the Issuer and has control over them.
Verifier:: An entity that requests, checks, and extracts the claims from an SD-JWT with its respective Disclosures.

Flow Diagram

SD-JWT Issuance and Presentation Flow

Concepts This section describes SD-JWTs with their respective Disclosures and Key Binding at a conceptual level, abstracting from the data formats described in .

SD-JWT and Disclosures 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 modifying 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 as part of the SD-JWT in the format defined in . 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-JWT MAY also contain clear-text claims that are always disclosed to the Verifier.

Disclosing to a 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.

Optional Key Binding Key Binding is an optional feature. When Key Binding is required by the use-case, the SD-JWT MUST contain information about the key material controlled by the Holder. Note: How the public key is included in SD-JWT is out of scope of this document. It can be passed by value or by reference. 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

a hash of the SD-JWT,
a nonce to ensure the freshness of the signature, and
an audience value to indicate the intended audience for the document.

Details of the format of Key Binding JWTs are described in .

Verification At a high level, the Verifier

receives either an SD-JWT or an SD-JWT+KB from the Holder,
verifies the signature on the SD-JWT (or the the SD-JWT inside the SD-JWT+KB) using the Issuer's public key,
verifies the signature on the KB-JWT using the public key included (or referenced) in the SD-JWT, if the Verifier's policy requires Key Binding, and
calculates the digests over the Holder-Selected Disclosures and verifies that each digest is contained in the SD-JWT.

The detailed algorithm is described in .

SD-JWT and SD-JWT+KB Data Formats An SD-JWT is composed of

an Issuer-signed JWT, and
zero or more Disclosures.

An SD-JWT+KB is composed of

an SD-JWT, and
a Key Binding JWT.

The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in , , and respectively. The serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows: ~~~...~~ ]]> The order of the concatenated parts MUST 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 element MUST be an empty string and the last separating tilde character MUST NOT be omitted. The serialized format for an SD-JWT+KB extends the SD-JWT format by concatenating a Key Binding JWT. ~~~...~~ ]]> The two formats can be distinguished by the final ~ character that is present on an SD-JWT. A Verifier that expects an SD-JWT MUST verify that the final tilde-separated component is empty. A Verifier that expects an SD-JWT+KB MUST verify that its final tilde-separated component is a valid KB-JWT. The Disclosures are linked to the Issuer-signed JWT through the digest 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 Holder MAY 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 reveal to the Verifier, the Holder MUST NOT send Disclosures or reveal the salt values in any other way. A Holder MUST NOT send a Disclosure that was not included in the issued SD-JWT or send a Disclosure more than once. To further illustrate the SD-JWT format, the following examples show a few different SD-JWT permutations, both with and without various constituent parts. An SD-JWT without Disclosures and without a KB-JWT: ~ ]]> An SD-JWT with Disclosures and without a KB-JWT: ~~~ ]]> An SD-JWT+KB without Disclosures: ~ ]]> An SD-JWT+KB with Disclosures: ~~~ ]]> As an alternative illustration of the SD-JWT format, for those who celebrate, ABNF for the SD-JWT, SD-JWT+KB, and various constituent parts is provided here:

Issuer-signed JWT An SD-JWT has a JWT component that MUST be signed using the Issuer's private key. It MUST NOT use the none algorithm. The payload of an SD-JWT is a JSON object according to the following rules:

The payload MAY contain the _sd_alg key described in .
The payload MAY contain one or more digests of Disclosures to enable selective disclosure of the respective claims, created and formatted as described in .
The payload MAY contain one or more decoy digests to obscure the actual number of claims in the SD-JWT, created and formatted as described in .
The payload MAY contain one or more non-selectively disclosable claims.
The payload MAY contain the Holder's public key(s) or reference(s) thereto, as explained in .
The payload MAY contain further claims such as iss, iat, etc. as defined or required by the application using SD-JWTs.
The payload MUST NOT contain the reserved claims _sd or ... except for the purpose of transporting digests as described below.

The same digest value MUST NOT appear more than once in the SD-JWT. Applications of SD-JWT SHOULD be explicitly typed using the typ header parameter. See for more details. It is the Issuer who decides which claims are selectively disclosable and which are not. End-User claims MAY be included as plaintext as well, e.g., if hiding the particular claims from the Verifier is not required in the intended use case. See for considerations on making validity-controlling claims such as exp 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.

Hash Function Claim The claim _sd_alg indicates the hash algorithm used by the Issuer to generate the digests as described in . When used, this claim MUST appear at the top level of the SD-JWT payload. It MUST NOT be used in any object nested within the payload. If the _sd_alg claim is not present at the top level, a default value of sha-256 MUST be used. The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry or a value defined in another specification and/or profile of this specification. To promote interoperability, implementations MUST support the sha-256 hash algorithm. See for requirements regarding entropy of the salt, minimum length of the salt, and choice of a hash algorithm.

Key Binding If the Issuer wants to enable Key Binding, it includes a public key associated with the Holder, or a reference thereto, using the cnf claim as defined in . The jwk confirmation method, as defined in Section 3.2 of , is suggested for doing so, however, other confirmation methods can be used. Note that, as was stated in , if an application needs to represent multiple proof-of-possession keys in the same SD-JWT, one way to achieve this is to use other claim names, in addition to cnf, to hold the additional proof-of-possession key information. It is out of the scope of this document to describe how the Holder key pair is established. For example, the Holder MAY create a key pair and provide a public key to the Issuer, the Issuer MAY create the key pair for the Holder, or Holder and Issuer MAY use pre-established key material. Note: The examples throughout this document use the cnf claim with the jwk member to include the raw public key by value in SD-JWT.

Disclosures Disclosures are created differently depending on whether a claim is an object property (name-value pair) or an array element.

For a claim that is an object property, the Issuer creates a Disclosure as described in .
For a claim that is an array element, the Issuer creates a Disclosure as described in .

Disclosures for Object Properties For each claim that is an object property and that is to be made selectively disclosable, the Issuer MUST create a Disclosure as follows:

Create an array of three elements in this order:
1. A salt value. MUST be a string. See for security considerations. It is RECOMMENDED to base64url-encode minimum 128 bits of cryptographically secure random data, producing a string. The salt value MUST be unique for each claim that is to be selectively disclosed. The Issuer MUST NOT reveal the salt value to any party other than the Holder.
2. The claim name, or key, as it would be used in a regular JWT payload. It MUST be a string and MUST NOT be _sd, ..., or a claim name existing in the object as a non-selectively disclosable claim.
3. The claim value, as it would be used in a regular JWT payload. The value MAY be of any type that is allowed in JSON, including numbers, strings, booleans, arrays, and objects.
JSON-encode the array, producing an UTF-8 string.
base64url-encode the byte representation of the UTF-8 string, producing a US-ASCII string. This string is the Disclosure.

The order is decided based on the readability considerations: salts would have a constant length within the SD-JWT, claim names would be around the same length all the time, and claim values would vary in size, potentially being large objects. The following example illustrates the steps described above. The array is created as follows: The resulting Disclosure would be: WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0 Note that variations in whitespace, encoding of Unicode characters, ordering of object properties, etc., are allowed in the JSON representation and no canonicalization needs be performed before base64url-encoding. For example, the following strings are all valid and encode the same claim value "Möbius":

A different way to encode the unicode umlaut:
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNX
HUwMGY2Yml1cyJd
No white space:
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Y
ml1cyJd
Newline characters between elements:
WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiT
cO2Yml1cyIKXQ

See for some further considerations on the Disclosure format approach.

Disclosures for Array Elements For each claim that is an array element and that is to be made selectively disclosable, the Issuer MUST create a Disclosure as follows:

The array MUST contain two elements in this order:
1. The salt value as described in .
2. The array element that is to be hidden. This value MAY be of any type that is allowed in JSON, including numbers, strings, booleans, arrays, and objects.

The Disclosure string is created by JSON-encoding this array and base64url-encoding the byte representation of the resulting string as described in . The same considerations regarding variations in the result of the JSON encoding apply. For example, a Disclosure for the second element of the nationalities array in the following claim set: could be created by first creating the following array: The resulting Disclosure would be: WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0

Hashing Disclosures 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 in . The resulting digest is then included in the SD-JWT payload instead of the original claim value, as described next. The digest MUST be taken over the US-ASCII bytes of the base64url-encoded value that is the Disclosure. This follows the convention in JWS and JWE . The bytes of the digest MUST then be base64url-encoded. It is important to note that:

The input to the hash function MUST be the base64url-encoded Disclosure, not the bytes encoded by the base64url string.
The bytes of the output of the hash function MUST be base64url-encoded, and are not the bytes making up the (often used) hex representation of the bytes of the digest.

For example, the SHA-256 digest of the Disclosure WyI2cU1RdlJMNWhhaiIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0 would be uutlBuYeMDyjLLTpf6Jxi7yNkEF35jdyWMn9U7b_RYY. The SHA-256 digest of the Disclosure WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0 would be w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs.

Embedding Disclosure Digests in SD-JWTs 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.

For a claim that is an object property, the Issuer embeds a Disclosure digest as described in .
For a claim that is an array element, the Issuer creates a Disclosure digest as described in .

Object Properties Digests of Disclosures for object properties are added to an array under the new key _sd in the object. The _sd key MUST refer to an array of strings, each string being a digest of a Disclosure or a decoy digest as described in . The array MAY be empty in case the Issuer decided not to selectively disclose any of the claims at that level. However, it is RECOMMENDED to omit the _sd key in this case to save space. The Issuer MUST hide the original order of the claims in the array. To ensure this, it is RECOMMENDED to shuffle the array of hashes, e.g., by sorting it alphanumerically or randomly, after potentially adding decoy digests as described in . The precise method does not matter as long as it does not depend on the original order of elements. For example, using the digest of the object property Disclosure created above, the Issuer could create the following SD-JWT payload to make family_name selectively disclosable:

Array Elements Digests of Disclosures for array elements are added to the array in the same position as the original claim value in the array. For each digest, an object of the form {"...": "<digest>"} is added to the array. The key MUST always be the string ... (three dots). The value MUST be the digest of the Disclosure created as described in . There MUST NOT be any other keys in the object. For example, using the digest of the array element Disclosure created above, the Issuer could create the following SD-JWT payload to make the second element of the nationalities array selectively disclosable: As described in , Verifiers ignore all selectively disclosable array elements for which they did not receive a Disclosure. In the example above, the verification process would output an array with only one element unless a matching Disclosure for the second element is received.

Decoy Digests An Issuer MAY add additional digests to the SD-JWT payload that are not associated with any claim. The purpose of such "decoy" digests is to make it more difficult for an attacker to see the original number of claims contained in the SD-JWT. Decoy digests MAY be added both to the _sd array for objects as well as in arrays. It is RECOMMENDED to create the decoy digests by hashing over a cryptographically secure random number. The bytes of the digest MUST then be base64url-encoded as above. The same digest function as for the Disclosures MUST be used. For decoy digests, no Disclosure is sent to the Holder, i.e., the Holder will see digests that do not correspond to any Disclosure. See for additional privacy considerations. To ensure readability and replicability, the examples in this specification do not contain decoy digests unless explicitly stated. For an example with decoy digests, see .

Key Binding JWT This section defines the Key Binding JWT, which encodes a signature over an SD-JWT by the Holder's private key. The Key Binding JWT MUST be a JWT according to and its payload MUST contain the following elements:

in the JOSE header,
- typ: REQUIRED. MUST be kb+jwt, which explicitly types the Key Binding JWT as recommended in Section 3.11 of .
- alg: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. MUST NOT be none.
in the JWT payload,
- iat: REQUIRED. The value of this claim MUST be the time at which the Key Binding JWT was issued using the syntax defined in .
- aud: REQUIRED. The intended receiver of the Key Binding JWT. How the value is represented is up to the protocol used and out of scope of this specification.
- nonce: REQUIRED. Ensures the freshness of the signature. The value type of this claim MUST be a string. How this value is obtained is up to the protocol used and out of scope of this specification.
- sd_hash: REQUIRED. The base64url-encoded hash value over the Issuer-signed JWT and the selected Disclosures as defined below.

Binding to an SD-JWT The hash value in the sd_hash claim binds the KB-JWT to the specific SD-JWT. The sd_hash value MUST be taken over the US-ASCII bytes of the encoded SD-JWT, i.e., the Issuer-signed JWT, a tilde character, and zero or more Disclosures selected for presentation to the Verifier, each followed by a tilde character: ~~~...~~ ]]> The bytes of the digest MUST then be base64url-encoded. The same hash algorithm as for the Disclosures MUST be used (defined by the _sd_alg element in the Issuer-signed JWT or the default value, as defined in ).

Validating the Key Binding JWT The Verifier MUST ensure that the key with which it validates the signature on the Key Binding JWT is the key specified in the SD-JWT as the Holder's public key. For example, if the SD-JWT contains a cnf value with a jwk member, the Verifier could parse the provided JWK and use it to verify the Key Binding JWT. Whether to require Key Binding is up to the Verifier's policy, based on the set of trust requirements such as trust frameworks it belongs to. See for security considerations.

Example SD-JWT 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 had to be added to JSON strings and base64-encoded strings to adhere to the 72-character limit for lines in RFCs and for readability. JSON does not allow line breaks within strings.

Issuance The Issuer is using the following input claim set: The Issuer in this case made the following decisions:

The nationalities array is always visible, but its contents are selectively disclosable.
The sub element and essential verification data (iss, iat, cnf, etc.) are always visible.
All other End-User claims are selectively disclosable.
For address, the Issuer is using a flat structure, i.e., all of the claims in the address claim can only be disclosed in full. Other options are discussed in .

The following payload is used for the SD-JWT: The following Disclosures are created by the Issuer: Claim given_name:

SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4
Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o
biJd
Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]

Claim family_name:

SHA-256 Hash: TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo
Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRv
ZSJd
Contents: ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]

Claim email:

SHA-256 Hash: JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE
Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VA
ZXhhbXBsZS5jb20iXQ
Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "email", "johndoe@example.com"]

Claim phone_number:

SHA-256 Hash: PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI
Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIr
MS0yMDItNTU1LTAxMDEiXQ
Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number",
"+1-202-555-0101"]

Claim phone_number_verified:

SHA-256 Hash: XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM
Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJp
ZmllZCIsIHRydWVd
Contents: ["Qg_O64zqAxe412a108iroA", "phone_number_verified", true]

Claim address:

SHA-256 Hash: XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE
Disclosure:
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVl
dF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRv
d24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0
Contents: ["AJx-095VPrpTtN4QMOqROA", "address", {"street_address":
"123 Main St", "locality": "Anytown", "region": "Anystate",
"country": "US"}]

Claim birthdate:

SHA-256 Hash: gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM
Disclosure:
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQw
LTAxLTAxIl0
Contents: ["Pc33JM2LchcU_lHggv_ufQ", "birthdate", "1940-01-01"]

Claim updated_at:

SHA-256 Hash: CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI
Disclosure:
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcw
MDAwMDAwXQ
Contents: ["G02NSrQfjFXQ7Io09syajA", "updated_at", 1570000000]

Array Entry:

SHA-256 Hash: pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo
Disclosure:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0
Contents: ["lklxF5jMYlGTPUovMNIvCA", "US"]

Array Entry:

SHA-256 Hash: 7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0
Disclosure:
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0
Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "DE"]

The payload is then signed by the Issuer to create a JWT like the following: The issued SD-JWT might look as follows:

Presentation The following non-normative example shows an SD-JWT+KB as it would be sent from the Holder to the Verifier. Note that it consists of six tilde-separated parts, with the Issuer-signed JWT as shown above in the beginning, four Disclosures (for the claims given_name, family_name, address, and nationalities) in the middle, and the Key Binding JWT as the last element. The following Key Binding JWT payload was created and signed for this presentation by the Holder: If the Verifier did not require Key Binding, then the Holder could have presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in an SD-JWT+KB.

Considerations on Nested Data in SD-JWTs Being JSON, an object in an SD-JWT payload MAY contain name-value pairs where the value is another object or objects MAY be elements in arrays. In SD-JWT, the Issuer decides for each claim individually, on each level of the JSON, whether the claim should be selectively disclosable or not. This choice can be made on each level independent from whether keys higher in the hierarchy are selectively disclosable. From this it follows that the _sd key containing digests MAY appear multiple times in an SD-JWT, and likewise, there MAY be multiple arrays within the hierarchy with each having selectively disclosable elements. Digests of selectively disclosable claims MAY 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 ecosystem requirements. For more examples with nested structures, see and . The following input claim set is used as an example throughout this section: Important: The following examples of the structures are non-normative and are not intended to represent all possible options. They are also not meant to define or restrict how address can be represented in an SD-JWT.

Example: Flat SD-JWT The Issuer can decide to treat the address claim as a block that can either be disclosed completely or not at all. The following example shows that in this case, the entire address claim is treated as an object in the Disclosure. The Issuer would create the following Disclosure: Claim address:

SHA-256 Hash: fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do
Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVl
dF9hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1
bHBmb3J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRy
eSI6ICJERSJ9XQ
Contents: ["2GLC42sKQveCfGfryNRN9w", "address", {"street_address":
"Schulstr. 12", "locality": "Schulpforta", "region":
"Sachsen-Anhalt", "country": "DE"}]

Example: Structured SD-JWT The Issuer may instead decide to make the address claim contents selectively disclosable individually: In this case, the Issuer would use the following data in the Disclosures for the address sub-claims: Claim street_address:

SHA-256 Hash: 9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwg
IlNjaHVsc3RyLiAxMiJd
Contents: ["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]

Claim locality:

SHA-256 Hash: 6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVs
cGZvcnRhIl0
Contents: ["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]

Claim region:

SHA-256 Hash: KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2Vu
LUFuaGFsdCJd
Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]

Claim country:

SHA-256 Hash: WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]

The Issuer may also make one sub-claim of address non-selectively disclosable and hide only the other sub-claims: In this case there would be no Disclosure for country since it is provided in the clear.

Example: SD-JWT with Recursive Disclosures The Issuer may also decide to make the address claim contents selectively disclosable recursively, i.e., the address claim is made selectively disclosable as well as its sub-claims: The Issuer creates Disclosures first for the sub-claims and then includes their digests in the Disclosure for the address claim: Claim street_address:

SHA-256 Hash: 9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwg
IlNjaHVsc3RyLiAxMiJd
Contents: ["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]

Claim locality:

SHA-256 Hash: 6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVs
cGZvcnRhIl0
Contents: ["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]

Claim region:

SHA-256 Hash: KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2Vu
LUFuaGFsdCJd
Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]

Claim country:

SHA-256 Hash: WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]

Claim address:

SHA-256 Hash: HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg
Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6
IFsiNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVk
MCIsICI5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3Nmtt
WXlNIiwgIktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEy
TjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8y
cm8yamZYTSJdfV0
Contents: ["Qg_O64zqAxe412a108iroA", "address", {"_sd":
["6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
"KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88",
"WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]

Verification and Processing

Verification of the SD-JWT Upon receiving an SD-JWT, either directly or as a component of an SD-JWT+KB, a Holder or a Verifier needs to ensure that:

the Issuer-signed JWT is valid, i.e., it is signed by the Issuer and the signature is valid, and
all Disclosures are valid and correspond to a respective digest value in the Issuer-signed JWT (directly in the payload or recursively included in the contents of other Disclosures).

The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT:

Separate the SD-JWT into the Issuer-signed JWT and the Disclosures (if any).
Validate the Issuer-signed JWT:
1. Ensure that a signing algorithm was used that was deemed secure for the application. Refer to , Sections 3.1 and 3.2 for details. The none algorithm MUST NOT be accepted.
2. Validate the signature over the Issuer-signed JWT per Section 5.2 of .
3. Validate the Issuer and that the signing key belongs to this Issuer.
4. Check that the _sd_alg claim value is understood and the hash algorithm is deemed secure (see ).
Process the Disclosures and embedded digests in the Issuer-signed JWT as follows:
1. For each Disclosure provided:
  1. Calculate the digest over the base64url-encoded string as described in .
2. (*) Identify all embedded digests in the Issuer-signed JWT as follows:
  1. Find all objects having an _sd key that refers to an array of strings.
  2. Find all array elements that are objects with one key, that key being ... and referring to a string.
3. (**) For each embedded digest found in the previous step:
  1. Compare the value with the digests calculated previously and find the matching Disclosure. If no such Disclosure can be found, the digest MUST be ignored.
  2. If the digest was found in an object's _sd key:
    1. If the contents of the respective Disclosure is not a JSON-encoded array of three elements (salt, claim name, claim value), the SD-JWT MUST be rejected.
    2. If the claim name is _sd or ..., the SD-JWT MUST be rejected.
    3. If the claim name already exists at the level of the _sd key, the SD-JWT MUST be rejected.
    4. Insert, at the level of the _sd key, a new claim using the claim name and claim value from the Disclosure.
    5. Recursively process the value using the steps described in (*) and (**).
  3. If the digest was found in an array element:
    1. If the contents of the respective Disclosure is not a JSON-encoded array of two elements (salt, value), the SD-JWT MUST be rejected.
    2. Replace the array element with the value from the Disclosure.
    3. Recursively process the value using the steps described in (*) and (**).
4. Remove all array elements for which the digest was not found in the previous step.
5. Remove all _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 {}.
6. Remove the claim _sd_alg from the SD-JWT payload.
If any digest value is encountered more than once in the Issuer-signed JWT payload (directly or recursively via other Disclosures), the SD-JWT MUST be rejected.
If any Disclosure was not referenced by digest value in the Issuer-signed JWT (directly or recursively via other Disclosures), the SD-JWT MUST be rejected.
Check that the SD-JWT is valid using claims such as nbf, iat, and exp in the processed payload. If a required validity-controlling claim is missing (see ), the SD-JWT MUST be rejected.

If any step fails, the SD-JWT is not valid and processing MUST be aborted. 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 End-User when needed.

Processing by the Holder The Issuer MUST provide the Holder an SD-JWT, not an SD-JWT+KB. If the Holder receives an SD-JWT+KB, it SHOULD be rejected. For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps:

Decide which Disclosures to release to the Verifier, obtaining proper End-User consent if necessary.
Assemble the SD-JWT, including the Issuer-signed JWT and the selected Disclosures (see for the format).
If Key Binding is not required:
1. Send the SD-JWT to the Verifier.
If Key Binding is required:
1. Create a Key Binding JWT tied to the SD-JWT.
2. Assemble the SD-JWT+KB by concatenating the SD-JWT and the Key Binding JWT.
3. Send the SD-JWT+KB to the Verifier.

Verification by the Verifier Upon receiving a presentation from a Holder, in the form of either an SD-JWT or an SD-JWT+KB, in addition to the checks outlined in , Verifiers need to ensure that

if Key Binding is required, then the Holder has provided an SD-JWT+KB, and
the Key Binding JWT is signed by the Holder and valid.

To this end, Verifiers MUST follow the following steps (or equivalent):

Determine if Key Binding is to be checked according to the Verifier's policy for the use case at hand. This decision MUST NOT be based on whether a Key Binding JWT is provided by the Holder or not. Refer to for details.
If Key Binding is required and the Holder has provided an SD-JWT (without Key Binding), the Verifier MUST reject the presentation.
If the Holder has provided an SD-JWT+KB, parse it into an SD-JWT and a Key Binding JWT.
Process the SD-JWT as defined in .
If Key Binding is required:
1. Determine the public key for the Holder from the SD-JWT (see ).
2. Ensure that a signing algorithm was used that was deemed secure for the application. Refer to , Sections 3.1 and 3.2 for details. The none algorithm MUST NOT be accepted.
3. Validate the signature over the Key Binding JWT per Section 5.2 of .
4. Check that the typ of the Key Binding JWT is kb+jwt (see ).
5. Check that the creation time of the Key Binding JWT, as determined by the iat claim, is within an acceptable window.
6. Determine that the Key Binding JWT is bound to the current transaction and was created for this Verifier (replay protection) by validating nonce and aud claims.
7. Calculate the digest over the Issuer-signed JWT and Disclosures as defined in and verify that it matches the value of the sd_hash claim in the Key Binding JWT.
8. Check that the Key Binding JWT is a valid JWT in all other respects, per and .

If any step fails, the presentation is not valid and processing MUST be aborted. Otherwise, the processed SD-JWT payload can be passed to the application to be used for the intended purpose.

JWS JSON Serialization This section describes an alternative format for SD-JWTs and SD-JWT+KBs using the JWS JSON Serialization from . Supporting this format is OPTIONAL.

New Unprotected Header Parameters For both the General and Flattened JSON Serialization, the SD-JWT or SD-JWT+KB is represented as a JSON object according to Section 7.2 of . The following new unprotected header parameters are defined:

disclosures: An array of strings where each element is an individual Disclosure as described in .
kb_jwt: Present only in an SD-JWT+KB, the Key Binding JWT as described in .

In an SD-JWT+KB, kb_jwt MUST be present when using the JWS JSON Serialization, and the digest in the sd_hash claim MUST be taken over the SD-JWT as described in . This means that even when using the JWS JSON Serialization, the representation as a regular SD-JWT MUST be created temporarily to calculate the digest. In detail, the SD-JWT part is built by concatenating the protected header, the payload, and the signature of the JWS JSON serialized SD-JWT using a . character as a separator, and using the Disclosures from the disclosures member of the unprotected header. Unprotected headers other than disclosures are not covered by the digest, and therefore, as usual, are not protected against tampering.

Flattened JSON Serialization In case of the Flattened JSON Serialization, there is only one unprotected header. The following is a non-normative example of a JWS JSON serialized SD-JWT as issued using the Flattened JSON Serialization: The following is an SD-JWT+KB with two Disclosures:

General JSON Serialization In case of the General JSON Serialization, there are multiple unprotected headers (one per signature). If present, disclosures and kb_jwt, MUST be included in the first unprotected header and MUST NOT be present in any following unprotected headers. The following is a non-normative example of a presentation of a JWS JSON serialized SD-JWT including a Key Binding JWT using the General JSON Serialization:

Verification of the JWS JSON Serialized SD-JWT Verification of the JWS JSON serialized SD-JWT follows the rules defined in , except for the following aspects:

The SD-JWT or SD-JWT+KB does not need to be split into component parts and the Disclosures can be found in the disclosures member of the unprotected header.
To verify the digest in sd_hash in the Key Binding JWT of an SD-JWT+KB, the Verifier MUST assemble the string to be hashed as described in .

Security Considerations Security considerations in this section help achieve the following properties: Selective Disclosure: An adversary in the role of the Verifier cannot obtain information from an SD-JWT about any claim name or claim value that was not explicitly disclosed by the Holder unless that information can be derived from other disclosed claims or sources other than the presented SD-JWT. Integrity: A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier. Additionally, as described in , the application of Key Binding can ensure that the presenter of an SD-JWT credential is the legitimate Holder of the credential.

Mandatory Signing of the Issuer-signed JWT The Issuer-signed JWT MUST be signed by the Issuer to protect integrity of the issued claims. 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 an attribute indicating a fake academic qualification). The Verifier MUST always check the signature of the Issuer-signed JWT to ensure that it has not been tampered with since the issuance. The Issuer-signed JWT MUST be rejected if the signature cannot be verified. The security of the Issuer-signed JWT depends on the security of the signature algorithm. Any of the JWS asymmetric digital signature algorithms registered in can be used, including post-quantum algorithms, when they are ready.

Manipulation of Disclosures Holders can manipulate the Disclosures by changing the values of the claims before sending them to the Verifier. The Verifier MUST check the Disclosures to ensure 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 extracts all claim values from the Disclosures (without checking the hashes) and inserts them into the SD-JWT payload is vulnerable to this attack. However, in a structured SD-JWT, without comparing the digests of the Disclosures, such an implementation could not determine the correct place in a nested object where a claim needs to be inserted. Therefore, the naive implementation would not only be insecure, but also incorrect. The steps described in ensure that the Verifier checks the Disclosures correctly.

Entropy of the salt The security model that conceals the plaintext claims relies on the high entropy random data of the salt as additional input to the hash function. The randomness ensures that the same plaintext claim value does not produce the same digest value. It also makes it infeasible to guess the preimage of the digest (thereby learning the plaintext claim value) by enumerating the potential value space 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 salt MUST be created in such a manner that it is cryptographically random, sufficiently long, and has high enough entropy that it is infeasible to guess. A new salt MUST be chosen for each claim independently of other salts. See Randomness Requirements for Security for considerations on generating random values. The RECOMMENDED minimum length of the randomly-generated portion of the salt is 128 bits. The Issuer MUST ensure that a new salt value is chosen for each claim, including when the same claim name occurs at different places in the structure of the SD-JWT. This can be seen in the example in , where multiple claims with the name type appear, but each of them has a different salt.

Choice of a Hash Algorithm To ensure privacy of claims that are selectively disclosable, but are not being disclosed in a given presentation, the hash function MUST 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 function MUST be preimage resistant, but should also not allow an observer to infer any partial information about the undisclosed content. In the terminology of cryptographic commitment schemes, the hash function MUST be computationally hiding. To ensure the integrity of selectively disclosable claims, the hash function MUST be second-preimage resistant. 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 result in the same digest. The hash function SHOULD also be collision resistant. Although not essential to the anticipated uses of SD-JWT, without collision resistance an Issuer may be able to find multiple disclosures that have the same hash value. In which case, the signature over the SD-JWT would not then commit the Issuer to the contents of the JWT. The collision resistance of the hash function used to generate digests SHOULD match the collision resistance of the hash function used by the signature scheme. For example, use of the ES512 signature algorithm would require a disclosure hash function with at least 256-bit collision resistance, such as SHA-512. Note that inclusion in the "Named Information Hash Algorithm" registry alone does not indicate a hash algorithm's suitability for use in SD-JWT (it contains several heavily truncated digests, such as sha-256-32 and sha-256-64, which are unfit for security applications). Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed fundamental weaknesses and MUST NOT be used.

Key Binding Key Binding aims to ensure that the presenter of an SD-JWT credential is actually the legitimate 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 the credential was issued by a particular Issuer, but the credential itself can be replayed by anyone who gets access to it. This means that, for example, after a credential was leaked to an attacker, the attacker can present the credential to any verifier that does not require a binding. But also a malicious Verifier to which the Holder presented the credential can present the credential to another Verifier if that other Verifier does not require Key Binding. Verifiers MUST decide whether Key Binding is required for a particular use case before verifying a credential. This decision can be informed by various factors including, but not limited to the following: business requirements, the use case, the type of binding between a Holder and its credential that is required for a use case, the sensitivity of the use case, the expected properties of a credential, the type and contents of other credentials expected to be presented at the same time, etc. It is important that a Verifier does not make its security policy decisions based on data that can be influenced by an attacker. For this reason, when deciding whether Key Binding is required or not, Verifiers MUST NOT take into account whether the Holder has provided an SD-JWT+KB or a bare SD-JWT, since otherwise an attacker could strip the KB-JWT from an SD-JWT+KB and present the resulting 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 the SD-JWT supports Key Binding or not. If a Verifier determines that Key Binding is required for a particular use case and the Holder presents either a bare SD-JWT or an SD-JWT+KB with an invalid Key Binding JWT, then the Verifier will reject the presentation when following the verification steps described in .

Blinding Claim Names SD-JWT ensures that names of claims that are selectively disclosable are always blinded. This prevents an attacker from learning the names of the disclosable claims. However, the names of the claims that are not disclosable are not blinded. This includes the keys of objects that themselves are not blinded, but contain disclosable claims. This limitation needs to be taken into account by Issuers when creating the structure of the SD-JWT.

Selectively-Disclosable Validity Claims An Issuer MUST NOT allow any content to be selectively disclosable that is critical for evaluating the SD-JWT's authenticity or validity. The exact list of such content will depend on the application and SHOULD be listed by any application-specific profile of SD-JWT. The following is a list of registered JWT claim names that SHOULD be considered as security-critical:

iss (Issuer)
aud (Audience), although issuers MAY 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-JWT in plaintext in the SD-JWT payload, but there is no guarantee they would do so. Therefore, Verifiers cannot reliably depend on that and need to operate as though security-critical claims might be selectively disclosable. Verifiers therefore MUST ensure that all claims they deem necessary for checking the validity of an SD-JWT in the given context are present (or disclosed, respectively) during validation of the SD-JWT. This is implemented in the last step of the verification defined in . The precise set of required validity claims will typically be defined by ecosystem rules, application-specific profile, or the credential format and MAY include claims other than those listed herein.

Issuer Signature Key Distribution and Rotation This specification does not define how signature verification keys of Issuers are distributed to Verifiers. However, it is RECOMMENDED that Issuers publish their keys in a way that allows for efficient and secure key rotation and revocation, for example, by publishing keys at a predefined location using the JSON Web Key Set (JWKS) format . Verifiers need to ensure that they are not using expired or revoked keys for signature verification using reasonable and appropriate means for the given key-distribution method.

Forwarding Credentials Any entity in possession of an SD-JWT (including an SD-JWT extracted from an SD-JWT+KB) can forward it to any third party that does not enforce Key Binding. When doing so, that entity may remove Disclosures such that the receiver learns only a subset of the claims contained in the original SD-JWT. For example, a device manufacturer might produce an SD-JWT containing information about upstream and downstream supply chain contributors. Each supply chain party can verify only the claims that were selectively disclosed to them by an upstream party, and they can choose to further reduce the disclosed claims when presenting to a downstream party. In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Key Binding.

Integrity of SD-JWTs and SD-JWT+KBs With an SD-JWT, the Issuer-signed JWT is integrity-protected by the Issuer's signature, and the values of the Disclosures are integrity-protected by the digests included therein. The specific set of Disclosures, however, is not integrity-protected - the SD-JWT can be modified by adding or removing 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 a specific SD-JWT, with a specific Issuer-signed JWT and a specific set of Disclosures. Thus, the signature on the Key Binding JWT, in addition to proving Key Binding, also assures the authenticity and integrity of the set of Disclosures the Holder disclosed. The set of Disclosures in an SD-JWT+KB is the set that the Holder intended to send; no intermediate party has added, removed, or modified the list of Disclosures.

Explicit Typing Section 3.11 of describes the use of explicit typing to prevent confusion attacks in which one kind of JWT is mistaken for another. SD-JWTs are also potentially vulnerable to such confusion attacks, so it is RECOMMENDED to specify an explicit type by including the typ header parameter when the SD-JWT is issued, and for Verifiers to check this value. When explicit typing is employed for an SD-JWT, it is RECOMMENDED 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 of typ in Section 4.1.9 of recommends that the "application/" prefix be omitted, so "example+sd-jwt" would be the value of the typ header parameter.

Privacy Considerations The privacy principles of should be adhered to.

Storage of Signed User Data Wherever End-User data is stored, it represents a potential target for an attacker. This target can be of particularly high value when the data is signed by a trusted authority like an official national identity service. For example, in OpenID Connect, signed ID Tokens can be stored by Relying Parties. In the case of SD-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 End-Users to third parties. Signed End-User data, the authenticity of which can be easily verified by third parties, further exacerbates the risk. As discussed in , leaked SD-JWTs may also allow attackers to impersonate Holders unless Key Binding is enforced and the attacker does not have access to the Holder's cryptographic keys. Altogether, leaked SD-JWT credentials may have a high monetary value on black markets. Due to these risks, systems implementing SD-JWT SHOULD be designed to minimize the amount of data that is stored. All involved parties SHOULD store SD-JWTs containing privacy-sensitive data only for as long as needed, including in log files. After Issuance, Issuers SHOULD NOT store the Issuer-signed JWT or the respective Disclosures if they contain privacy-sensitive data. Holders SHOULD store SD-JWTs only in encrypted form, and, wherever possible, use hardware-backed encryption in particular for the private Key Binding key. Decentralized storage of data, e.g., on End-User devices, SHOULD be preferred for End-User credentials over centralized storage. Expired SD-JWTs SHOULD be deleted as soon as possible. After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT or the respective Disclosures if they contain privacy-sensitive data. It may be sufficient to store the result of the verification and any End-User data that is needed for the application. If reliable and secure key rotation and revocation is ensured according to , Issuers may opt to publish expired or revoked private signing keys (after a grace period that ensures that the keys are not cached any longer at any Verifier). This reduces the value of any leaked credentials as the signatures on them can no longer be trusted to originate from the Issuer.

Confidentiality during Transport If the SD-JWT is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the End-User's personal data or correlate the information with previous uses of the same SD-JWT. Usually, transport protocols for issuance and presentation of credentials are designed to protect the confidentiality of the transmitted data, for example, by requiring the use of TLS. This specification therefore considers the confidentiality of the data to be provided by the transport protocol and does not specify any encryption mechanism. Implementers MUST ensure that the transport protocol provides confidentiality if the privacy of End-User data or correlation attacks by passive observers are a concern. To encrypt the SD-JWT when transmitted over an insecure channel, implementers MAY use JSON Web Encryption (JWE) by nesting the SD-JWT as the plaintext payload of a 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-JWT SHOULD be encrypted using JWE.

Decoy Digests The use of decoy digests is RECOMMENDED 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 End-User is a member of a group), the Issuer SHOULD 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 End-User's data.

Unlinkability Unlinkability is a property whereby adversaries are prevented from correlating credential 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 user intended to disclose, for example:

Cooperating Verifiers might want to track users across services to build advertising profiles.
Issuers might want to track where users present their credentials to enable surveillance.
After a data breach at multiple Verifiers, publicly available information might allow linking identifiable information presented to Verifier A with originally anonymous information presented to Verifier B, therefore revealing the identities of users of Verifier B.

The following types of unlinkability are considered here:

Presentation Unlinkability: A Verifier should not be able to link two presentations of the same credential.
Verifier/Verifier Unlinkability: Two colluding Verifiers should not be able to learn that they have received presentations of the same credential.
Issuer/Verifier Unlinkability (Honest Verifier): An Issuer of a credential should not be able to know that a user presented the credential to a certain Verifier that is not behaving maliciously.
Issuer/Verifier Unlinkability (Colluding/Compromised Verifier): An Issuer of a credential should not be able to tell that a user presented the credential to a certain Verifier, even if the Verifier colludes with the Issuer or becomes compromised and leaks stored credentials from presentations.

In all cases, unlinkability is limited to cases where the disclosed claims do not contain information that directly or indirectly identifies the user. For example, when a taxpayer identification number is contained in the disclosed claims, the Issuer and Verifier can easily link the user's transactions. However, when the user only discloses 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 colluding or compromised Verifier cannot be achieved in salted-hash based selective disclosure approaches, such as SD-JWT, as the issued credential with the Issuer's signature is directly presented to the Verifier, who can forward it to the Issuer. 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 potentially disclose information about the credential's usage to the Issuer. Where such callbacks are necessary, they MUST be executed in a manner that preserves privacy and does not disclose details about the credential to the Issuer. It is important to note that the timing of such requests could potentially serve as a side-channel. Verifier/Verifier unlinkablility and presentation unlinkablility can be achieved using batch issuance: A batch of credentials based on the same claims is issued to the Holder instead of just a single credential. The Holder can then use a different credential for each Verifier or even for each session with a Verifier. New key binding keys and salts MUST be used for each credential in the batch to ensure that the Verifiers cannot link the credentials using these values. Likewise, claims carrying time information, like iat, exp, and nbf, MUST either be randomized within a time period considered appropriate (e.g., randomize iat within the last 24 hours and calculate exp accordingly) or rounded (e.g., rounded down to the beginning of the day).

Issuer Identifier 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 the National Cancer 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.

Acknowledgements We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

IANA Considerations

JSON Web Token Claims Registration This specification requests registration of the following Claims in the IANA "JSON Web Token Claims" registry established by .

Claim Name: _sd
Claim Description: Digests of Disclosures for object properties
Change Controller: IETF
Specification Document(s): [[ of this specification ]]

Claim Name: ...
Claim Description: Digest of the Disclosure for an array element
Change Controller: IETF
Specification Document(s): [[ of this specification ]]

Claim Name: _sd_alg
Claim Description: Hash algorithm used to generate Disclosure digests and digest over presentation
Change Controller: IETF
Specification Document(s): [[ of this specification ]]

Claim Name: sd_hash
Claim Description: Digest of the SD-JWT to which the KB-JWT is tied
Change Controller: IETF
Specification Document(s): [[ of this specification ]]

Media Type Registration This section requests registration of the following media types in the "Media Types" registry in the manner described in . Note: For the media type value used in the typ header in the Issuer-signed JWT itself, see . To indicate that the content is an SD-JWT:

Type name: application
Subtype name: sd-jwt
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: binary; application/sd-jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') or tilde ('~') characters.
Security considerations: See the Security Considerations section of [[ this specification ]], , and .
Interoperability considerations: n/a
Published specification: [[ this specification ]]
Applications that use this media type: TBD
Fragment identifier considerations: n/a
Additional information:
- Magic number(s): n/a
- File extension(s): n/a
- Macintosh file type code(s): n/a
Person & email address to contact for further information: Daniel Fett, mail@danielfett.de
Intended usage: COMMON
Restrictions on usage: none
Author: Daniel Fett, mail@danielfett.de
Change Controller: IETF
Provisional registration? No

To indicate that the content is a JWS JSON serialized SD-JWT:

Type name: application
Subtype name: sd-jwt+json
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: binary; application/sd-jwt+json values are represented as a JSON Object; UTF-8 encoding SHOULD be employed for the JSON object.
Security considerations: See the Security Considerations section of [[ this specification ]], and .
Interoperability considerations: n/a
Published specification: [[ this specification ]]
Applications that use this media type: TBD
Fragment identifier considerations: n/a
Additional information:
- Magic number(s): n/a
- File extension(s): n/a
- Macintosh file type code(s): n/a
Person & email address to contact for further information: Daniel Fett, mail@danielfett.de
Intended usage: COMMON
Restrictions on usage: none
Author: Daniel Fett, mail@danielfett.de
Change Controller: IETF
Provisional registration? No

To indicate that the content is a Key Binding JWT:

Type name: application
Subtype name: kb+jwt
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: binary; A Key Binding JWT is a JWT; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters.
Security considerations: See the Security Considerations section of [[ this specification ]], , and .
Interoperability considerations: n/a
Published specification: [[ this specification ]]
Applications that use this media type: TBD
Fragment identifier considerations: n/a
Additional information:
- Magic number(s): n/a
- File extension(s): n/a
- Macintosh file type code(s): n/a
Person & email address to contact for further information: Daniel Fett, mail@danielfett.de
Intended usage: COMMON
Restrictions on usage: none
Author: Daniel Fett, mail@danielfett.de
Change Controller: IETF
Provisional registration? No

Structured Syntax Suffix Registration This section requests registration of the "+sd-jwt" structured syntax suffix in the "Structured Syntax Suffix" registry in the manner described in [RFC6838], which can be used to indicate that the media type is encoded as an SD-JWT.

Name: SD-JWT
+suffix: +sd-jwt
References: [[ this specification ]]
Encoding considerations: binary; SD-JWT values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') or tilde ('~') characters.
Interoperability considerations: n/a
Fragment identifier considerations: n/a
Security considerations: See the Security Considerations section of [[ this specification ]], , and .
Contact: Daniel Fett, mail@danielfett.de
Author/Change controller: IETF

References Normative References Informative References The European Digital Identity Wallet Architecture and Reference Framework Named Information Hash Algorithm JSON Web Signature and Encryption Algorithms JSON Web Token Claims IANA Media Types Structured Syntax Suffixs ISO/IEC 29100:2011 Information technology — Security techniques — Privacy framework OpenID Connect for Identity Assurance 1.0 yes.com yes.com Considrd.Consulting Ltd Santander 1&1 Mail & Media Development & Technology GmbH KDDI Corporation Verifiable Credentials Data Model 2.0 Digital Bazaar Transmute Invited Expert Block Spruce Systems. Inc.

Additional Examples Important: The following examples are not normative and are provided for illustrative purposes only. In particular, neither the structure of the claims nor the selection of selectively disclosable claims is normative. Line breaks have been added for readability.

Simple Structured SD-JWT In this example, in contrast to , the Issuer decided to create a structured object for the address claim, allowing to separately disclose individual members of the claim. The Issuer is using the following input claim set: 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: The following Disclosures are created: Claim sub:

SHA-256 Hash: X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g
Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1i
NTg5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ
Contents: ["2GLC42sKQveCfGfryNRN9w", "sub",
"6c5c0a49-b589-431d-bae7-219122a9ec2c"]

Claim given_name:

SHA-256 Hash: ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q
Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1
OTJhXHU5MGNlIl0
Contents: ["eluV5Og3gSNII8EYnsxA_A", "given_name", "\u592a\u90ce"]

Claim family_name:

SHA-256 Hash: C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU
Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1
NWM3MVx1NzUzMCJd
Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "family_name", "\u5c71\u7530"]

Claim email:

SHA-256 Hash: Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE
Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3Vh
bCBlbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd
Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual email
address\"@example.jp"]

Claim phone_number:

SHA-256 Hash: s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U
Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIr
ODEtODAtMTIzNC01Njc4Il0
Contents: ["Qg_O64zqAxe412a108iroA", "phone_number",
"+81-80-1234-5678"]

Claim street_address:

SHA-256 Hash: 6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E
Disclosure:
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwg
Ilx1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1
NTcxMlx1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd
Contents: ["AJx-095VPrpTtN4QMOqROA", "street_address", "\u6771\u4eac\u
90fd\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u
2212\uff18"]

Claim locality:

SHA-256 Hash: rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA
Disclosure:
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3
MVx1NGVhY1x1OTBmZCJd
Contents: ["Pc33JM2LchcU_lHggv_ufQ", "locality", "\u6771\u4eac\u90fd"]

Claim region:

SHA-256 Hash: PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k
Disclosure:
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZc
dTUzM2EiXQ
Contents: ["G02NSrQfjFXQ7Io09syajA", "region", "\u6e2f\u533a"]

Claim country:

SHA-256 Hash: uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4
Disclosure:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ
Contents: ["lklxF5jMYlGTPUovMNIvCA", "country", "JP"]

Claim birthdate:

SHA-256 Hash: MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY
Disclosure:
WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQw
LTAxLTAxIl0
Contents: ["yytVbdAPGcgl2rI4C9GSog", "birthdate", "1940-01-01"]

The following decoy digests are added:

AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg
cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ
glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4
b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek
fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs
Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE

The following is how a presentation of the SD-JWT that discloses only region and country of the address property could look like:

Complex Structured SD-JWT In this example, an SD-JWT with a complex object is represented. The data structures defined in OIDC4IDA are used. The Issuer is using the following input claim set: The following payload is used for the SD-JWT: The following Disclosures are created by the Issuer: Claim time:

SHA-256 Hash: vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw
Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0y
M1QxODoyNVoiXQ
Contents: ["2GLC42sKQveCfGfryNRN9w", "time", "2012-04-23T18:25Z"]

Claim verification_process:

SHA-256 Hash: 7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc
Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9j
ZXNzIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ
Contents: ["eluV5Og3gSNII8EYnsxA_A", "verification_process",
"f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"]

Claim type:

SHA-256 Hash: G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk
Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQi
XQ
Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "type", "document"]

Claim method:

SHA-256 Hash: WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ
Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0
Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "method", "pipp"]

Claim time:

SHA-256 Hash: 9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI
Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0y
MlQxMTozMFoiXQ
Contents: ["Qg_O64zqAxe412a108iroA", "time", "2012-04-22T11:30Z"]

Claim document:

SHA-256 Hash: IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4
Disclosure:
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBl
IjogImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1
cmciLCAiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0Iiwg
ImRhdGVfb2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4
cGlyeSI6ICIyMDIwLTAzLTIyIn1d
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:
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1
RDdQSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhP
QU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdG
cldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldw
eFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d
Contents: ["Pc33JM2LchcU_lHggv_ufQ", {"_sd":
["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI",
"G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk",
"IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4",
"WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]

Claim given_name:

SHA-256 Hash: S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo
Disclosure:
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4
Il0
Contents: ["G02NSrQfjFXQ7Io09syajA", "given_name", "Max"]

Claim family_name:

SHA-256 Hash: Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk
Disclosure:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1c
dTAwZmNsbGVyIl0
Contents: ["lklxF5jMYlGTPUovMNIvCA", "family_name", "M\u00fcller"]

Claim nationalities:

SHA-256 Hash: hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE
Disclosure:
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBb
IkRFIl1d
Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]

Claim birthdate:

SHA-256 Hash: WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk
Disclosure:
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2
LTAxLTI4Il0
Contents: ["5bPs1IquZNa0hkaFzzzZNw", "birthdate", "1956-01-28"]

Claim place_of_birth:

SHA-256 Hash: RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo
Disclosure:
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwg
eyJjb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1
MDBlNmphcmtsYXVzdHVyIn1d
Contents: ["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", {"country":
"IS", "locality": "\u00deykkvab\u00e6jarklaustur"}]

Claim address:

SHA-256 Hash: _O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ
Disclosure:
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2Fs
aXR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNv
dW50cnkiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1
MDBkZmUgMjIifV0
Contents: ["y1sVU5wdfJahVdgwPgS7RQ", "address", {"locality":
"Maxstadt", "postal_code": "12344", "country": "DE",
"street_address": "Weidenstra\u00dfe 22"}]

Claim birth_middle_name:

SHA-256 Hash: otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI
Disclosure:
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1l
IiwgIlRpbW90aGV1cyJd
Contents: ["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name", "Timotheus"]

Claim salutation:

SHA-256 Hash: -aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw
Disclosure:
WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIu
Il0
Contents: ["C9GSoujviJquEgYfojCb1A", "salutation", "Dr."]

Claim msisdn:

SHA-256 Hash: IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg
Disclosure:
WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1
Njc4OSJd
Contents: ["kx5kF17V-x0JmwUx9vgvtw", "msisdn", "49123456789"]

The following is how a presentation of the SD-JWT could look like: After the validation, the Verifier will have the following data for further processing:

SD-JWT-based Verifiable Credentials (SD-JWT VC) 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) to represent the concept of a Person Identification Data (PID) using the data of a German citizen. Key Binding is applied using the Holder's public key passed in a cnf claim in the SD-JWT. The Issuer is using the following input claim set: The following is the issued SD-JWT: The following payload is used for the SD-JWT: The following Disclosures are created by the Issuer: Claim given_name:

SHA-256 Hash: 0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg
Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJp
a2EiXQ
Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]

Claim family_name:

SHA-256 Hash: I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc
Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11
c3Rlcm1hbm4iXQ
Contents: ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Mustermann"]

Claim birthdate:

SHA-256 Hash: Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg
Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYz
LTA4LTEyIl0
Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1963-08-12"]

Claim source_document_type:

SHA-256 Hash: qvzNLj2vh9o4SEXOfMiYDuvTykdsWCNg0wTdlr0AEIM
Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInNvdXJjZV9kb2N1bWVudF90
eXBlIiwgImlkX2NhcmQiXQ
Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "source_document_type",
"id_card"]

Claim street_address:

SHA-256 Hash: bd1EVzgNopUk4EW3_eQ2n3_NU4iuXOHv9XbGHN3g1TE
Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInN0cmVldF9hZGRyZXNzIiwg
IkhlaWRlc3RyYVx1MDBkZmUgMTciXQ
Contents: ["Qg_O64zqAxe412a108iroA", "street_address",
"Heidestra\u00dfe 17"]

Claim locality:

SHA-256 Hash: f_FQYgvQWvyVqNnIXsARlNye7YGp8E77gRAjaq-wvnw
Disclosure:
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImxvY2FsaXR5IiwgIktcdTAw
ZjZsbiJd
Contents: ["AJx-095VPrpTtN4QMOqROA", "locality", "K\u00f6ln"]

Claim postal_code:

SHA-256 Hash: XFc7zXPm7zzVdMywm2EuBflka5HHqvf8Up_szNGqvig
Disclosure:
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgInBvc3RhbF9jb2RlIiwgIjUx
MTQ3Il0
Contents: ["Pc33JM2LchcU_lHggv_ufQ", "postal_code", "51147"]

Claim country:

SHA-256 Hash: v4kkb_pP1jlvUbSjtyc5bqcWyA-i8XLvhVYY7ZT0tb0
Disclosure:
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImNvdW50cnkiLCAiREUiXQ
Contents: ["G02NSrQfjFXQ7Io09syajA", "country", "DE"]

Claim address:

SHA-256 Hash: zOeBXhxvIS4ZzmQcLlxKuEAOGGByjOqa1z2IoVx_YDQ
Disclosure:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImFkZHJlc3MiLCB7Il9zZCI6
IFsiWEZjN3pYUG03enpWZE15d20yRXVCZmxrYTVISHF2ZjhVcF9zek5HcXZp
ZyIsICJiZDFFVnpnTm9wVWs0RVczX2VRMm4zX05VNGl1WE9IdjlYYkdITjNn
MVRFIiwgImZfRlFZZ3ZRV3Z5VnFObklYc0FSbE55ZTdZR3A4RTc3Z1JBamFx
LXd2bnciLCAidjRra2JfcFAxamx2VWJTanR5YzVicWNXeUEtaThYTHZoVllZ
N1pUMHRiMCJdfV0
Contents: ["lklxF5jMYlGTPUovMNIvCA", "address", {"_sd":
["XFc7zXPm7zzVdMywm2EuBflka5HHqvf8Up_szNGqvig",
"bd1EVzgNopUk4EW3_eQ2n3_NU4iuXOHv9XbGHN3g1TE",
"f_FQYgvQWvyVqNnIXsARlNye7YGp8E77gRAjaq-wvnw",
"v4kkb_pP1jlvUbSjtyc5bqcWyA-i8XLvhVYY7ZT0tb0"]}]

Claim nationalities:

SHA-256 Hash: hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE
Disclosure:
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBb
IkRFIl1d
Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]

Claim gender:

SHA-256 Hash: IEBYSJGNhXIlrQo58ykXm2Zx3yll9ZlTtToPo17QQiY
Disclosure:
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImdlbmRlciIsICJmZW1hbGUi
XQ
Contents: ["5bPs1IquZNa0hkaFzzzZNw", "gender", "female"]

Claim birth_family_name:

SHA-256 Hash: ikuur8Q4k8q3VcyA7dC-mNjZBkReDTU-CG4niTE7OTU
Disclosure:
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImJpcnRoX2ZhbWlseV9uYW1l
IiwgIkdhYmxlciJd
Contents: ["5a2W0_NrlEZzfqmk_7Pq-w", "birth_family_name", "Gabler"]

Claim locality:

SHA-256 Hash: WphHoIDyoWbApDC4zbuwR40xl0xLhDC_cv4tsS71rEA
Disclosure:
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImxvY2FsaXR5IiwgIkJlcmxp
biJd
Contents: ["y1sVU5wdfJahVdgwPgS7RQ", "locality", "Berlin"]

Claim place_of_birth:

SHA-256 Hash: wzW15bhCkvksxVvuJ8RF3xi8i64ln1jo_76BC2oa1ug
Disclosure:
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwg
eyJfc2QiOiBbIldwaEhvSUR5b1diQXBEQzR6YnV3UjQweGwweExoRENfY3Y0
dHNTNzFyRUEiXSwgImNvdW50cnkiOiAiREUifV0
Contents: ["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd":
["WphHoIDyoWbApDC4zbuwR40xl0xLhDC_cv4tsS71rEA"], "country":
"DE"}]

Claim also_known_as:

SHA-256 Hash: 9ZbplC7TdEW7qal6BBZlMtqJdmeEOiXevdJloXVJdRQ
Disclosure:
WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgImFsc29fa25vd25fYXMiLCAi
U2Nod2VzdGVyIEFnbmVzIl0
Contents: ["C9GSoujviJquEgYfojCb1A", "also_known_as", "Schwester
Agnes"]

Claim 12:

SHA-256 Hash: Fc8I_07LOcgPwrDJKQyIGO97wVsOplMLjHvRC4R4-Wg
Disclosure:
WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjEyIiwgdHJ1ZV0
Contents: ["kx5kF17V-x0JmwUx9vgvtw", "12", true]

Claim 14:

SHA-256 Hash: f1-P0A2dKWavv1uFnMX2A7-EXxvhoxv5aHhuEIN-W64
Disclosure:
WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE0IiwgdHJ1ZV0
Contents: ["H3o1uswP760Fi2yeGdVCEQ", "14", true]

Claim 16:

SHA-256 Hash: k5hy2r018vrsJjo-Vjd6g6yt7AaonKonniuJ9zel3jo
Disclosure:
WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE2IiwgdHJ1ZV0
Contents: ["OBKlTVlvLg-AdwqYGbP8ZA", "16", true]

Claim 18:

SHA-256 Hash: qp7Z_Ky1Yip0sYgDO3zVug2MFuPNjHxksBDnJZ4aI-c
Disclosure:
WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjE4IiwgdHJ1ZV0
Contents: ["M0Jb57t41ubrkSuyrDT3xA", "18", true]

Claim 21:

SHA-256 Hash: aoCCzsC7p4qhZIAh_idRCSCa641uycnc8zPfNWz8nx0
Disclosure:
WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjIxIiwgdHJ1ZV0
Contents: ["DsmtKNgpV4dAHpjrcaosAw", "21", true]

Claim 65:

SHA-256 Hash: XLtLjadUWc9zN_9hMJRoqy46UsCKb1IshZuuqUFKSCA
Disclosure:
WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgIjY1IiwgZmFsc2Vd
Contents: ["eK5o5pHfgupPpltj1qhAJw", "65", false]

The following is how an SD-JWT+KB that discloses only nationality and the fact that the person is over 18 years old could look like: The following is the payload of a corresponding Key Binding JWT: After the validation, the Verifier will have the following data for further processing:

W3C Verifiable Credentials Data Model v2.0 This non-normative example illustrates how the artifacts defined in this specification could be used to express a W3C Verifiable Credentials Data Model v2.0 payload. Key Binding is applied using the Holder's public key passed in a cnf claim in the SD-JWT. The Issuer is using the following input claim set: The following is the issued SD-JWT: The following payload is used for the SD-JWT: The following Disclosures are created by the Issuer: Claim atcCode:

SHA-256 Hash: 1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI
Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3Qlgw
MyJd
Contents: ["2GLC42sKQveCfGfryNRN9w", "atcCode", "J07BX03"]

Claim medicinalProductName:

SHA-256 Hash: Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo
Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3RO
YW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd
Contents: ["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName", "COVID-19
Vaccine Moderna"]

Claim marketingAuthorizationHolder:

SHA-256 Hash: Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE
Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6
YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0
Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHolder",
"Moderna Biotech"]

Claim nextVaccinationDate:

SHA-256 Hash: R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4
Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRh
dGUiLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ
Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate",
"2021-08-16T13:40:12Z"]

Claim countryOfVaccination:

SHA-256 Hash: JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg
Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0
aW9uIiwgIkdFIl0
Contents: ["Qg_O64zqAxe412a108iroA", "countryOfVaccination", "GE"]

Claim dateOfVaccination:

SHA-256 Hash: zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0
Disclosure:
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9u
IiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0
Contents: ["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination",
"2021-06-23T13:40:12Z"]

Claim order:

SHA-256 Hash: b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g
Disclosure:
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd
Contents: ["Pc33JM2LchcU_lHggv_ufQ", "order", "3/3"]

Claim gender:

SHA-256 Hash: 3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI
Disclosure:
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUi
XQ
Contents: ["G02NSrQfjFXQ7Io09syajA", "gender", "Female"]

Claim birthDate:

SHA-256 Hash: Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU
Disclosure:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYx
LTA4LTE3Il0
Contents: ["lklxF5jMYlGTPUovMNIvCA", "birthDate", "1961-08-17"]

Claim givenName:

SHA-256 Hash: lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw
Disclosure:
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJp
b24iXQ
Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "givenName", "Marion"]

Claim familyName:

SHA-256 Hash: 1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA
Disclosure:
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVz
dGVybWFubiJd
Contents: ["5bPs1IquZNa0hkaFzzzZNw", "familyName", "Mustermann"]

Claim administeringCentre:

SHA-256 Hash: TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg
Disclosure:
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50
cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd
Contents: ["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre", "Praxis
Sommergarten"]

Claim batchNumber:

SHA-256 Hash: V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM
Disclosure:
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2
MjYzODI3MzYiXQ
Contents: ["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber", "1626382736"]

Claim healthProfessional:

SHA-256 Hash: 1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww
Disclosure:
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25h
bCIsICI4ODMxMTAwMDAwMTUzNzYiXQ
Contents: ["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional",
"883110000015376"]

The following is how an SD-JWT+KB that discloses only type, medicinalProductName, atcCode of the vaccine, type of the recipient, type, order and dateOfVaccination could look like: After the validation, the Verifier will have the following data for further processing:

Elliptic Curve Key Used in the Examples The following Elliptic Curve public key, represented in JWK format, can be used to validate the Issuer signatures in the above examples: The public key used to validate a Key Binding JWT can be found in the examples as the content of the cnf claim.

Disclosure Format Considerations As described in , the Disclosure structure is JSON containing salt and the cleartext content of a claim, which is base64url encoded. The encoded value is the input used to calculate a digest for the respective claim. The inclusion of digest value in the signed JWT ensures the integrity of the claim value. Using encoded content as the input to the integrity mechanism is conceptually similar to the approach in JWS and particularly useful when the content, like JSON, can have differences but be semantically equivalent. Some further discussion of the considerations around this design decision follows. When receiving an SD-JWT, a Verifier must be able to re-compute digests of the disclosed claim values and, given the same input values, obtain the same digest values as signed by the Issuer. Usually, JSON-based formats transport claim values as simple properties of a JSON object such as this: However, a problem arises when computation over the data need to be performed and verified, like signing or computing digests. Common signature schemes require the same byte string as input to the signature verification as was used for creating the signature. In the digest approach outlined above, the same problem exists: for the Issuer and the Verifier 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 or as The two representations of the value in family_name are very different on the byte-level, but yield equivalent objects. Same for the representations of address, varying in white space and order of elements in the object. The variations in white space, ordering of object properties, and encoding of Unicode characters are all allowed by the JSON specification, including further variations, e.g., concerning floating-point numbers, as described in . Variations can be introduced whenever JSON data is serialized or deserialized and unless dealt with, will lead to different digests and the inability to verify signatures. There are generally two approaches to deal with this problem:

Canonicalization: The data is transferred in JSON format, potentially introducing variations in its representation, but is transformed into a canonical form before computing a digest. Both the Issuer and the Verifier must use the same canonicalization algorithm to arrive at the same byte string for computing a digest.
Source string hardening: Instead of transferring data in a format that may introduce variations, a representation of the data is serialized. This representation is then used as the hashing input at the Verifier, but also transferred to the Verifier and used for the same digest calculation there. This means that the Verifier can easily compute and check the digest of the byte string before finally deserializing and accessing the data.

Mixed approaches are conceivable, i.e., transferring both the original JSON data plus a string suitable for computing a digest, but such approaches can easily lead to undetected inconsistencies resulting in time-of-check-time-of-use type security vulnerabilities. In this specification, the source string hardening approach is used, as it allows for simple and reliable interoperability without the requirement for a canonicalization library. To harden the source string, any serialization format that supports the necessary data types could be used in theory, like protobuf, msgpack, or pickle. In this specification, JSON is used and plaintext contents of each Disclosure are encoded using base64url-encoding for transport. This approach means that SD-JWTs can be implemented purely based on widely available JWT, JSON, and Base64 encoding and decoding libraries. A Verifier can then easily check the digest over the source string before extracting the original JSON data. Variations in the encoding of the source string are implicitly tolerated by the Verifier, as the digest is computed over a predefined byte string and not over a JSON object. It is important to note that the Disclosures are neither intended nor suitable for direct consumption by an application that needs to access the disclosed claim values after the verification by the Verifier. The Disclosures are only intended to be used by a Verifier to check the digests over the source strings and to extract the original JSON data. The original JSON data is then used by the application. See for details.

Document History [[ To be removed from the final specification ]] -09

Distinguished SD-JWT from SD-JWT+KB
Provide ABNF for the SD-JWT, SD-JWT+KB, and various constituent parts
New structure for JSON-serialized SD-JWTs/KB-JWTs to better align with JAdES.
Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible
Consolidate salt entropy and length security consideration subsections
Unnumbered most of the examples for improved clarity
More definitive language around the exclusive use of the cnf claim for enabling Key Binding

-08

Make RFCs 0020 and 7515 normative references
Be a bit more prescriptive in suggesting RFC7800 cnf/jwk be used to convey the Key Binding key
Editorial changes aimed at improved clarity
Improve unlinkability considerations, mention that different KB keys must be used
Remove the explicit prohibition on HMAC
Remove mention of unspecified key binding methods and the Enveloping SD-JWTs section
Editorial updates aimed at more consistent treatment of a Disclosure vs the contents of a Disclosure
Update PID example
Be more explicit that the VCDM and SD-JWT VC examples are only illustrative and do not define anything

-07

Reference RFC4086 in security considerations about salt entropy
Update change controller for the Structured Syntax Suffix registration from IESG to IETF per IANA suggestion
Strengthen security considerations around claims controlling the validity of the SD-JWT not being selectively disclosable
Expand/rework considerations on the choice of hash algorithm
Clarify validation around no duplicate digests in the payload (directly or recursively) and no unused disclosures at the end of processing
Better describe and illustrate the tilde separated format
Change claim name from _sd_hash to sd_hash

-06

Added hash of Issuer-signed part and Disclosures in KB-JWT
Fix minor issues in some examples
Added IANA media type registration request for the JSON Serialization
More precise wording around storing artifacts with sensitive data
The claim name _sd or ... must not be used in a disclosure.
Added JWT claims registration requests to IANA
Ensure claims that control validity are checked after decoding payload
Restructure sections around data formats and Example 1
Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere
Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs

-05

Consolidate processing rules for Holder and Verifier
Add support for selective disclosure of array elements.
Consolidate SD-JWT terminology and format
Use the term Key Binding rather than Holder Binding
Defined the structure of the Key Binding JWT
Added a JWS JSON Serialization
Added initial IANA media type and structured suffix registration requests
Added recommendation for explicit typing of SD-JWTs
Added considerations around forwarding credentials
Removed Example 2b and merged the demo of decoy digests into Example 2a
Improved example for allowed variations in Disclosures
Added some text to the Abstract and Introduction to be more inclusive of JWS with JSON
Added some security considerations text about the scope of the Key Binding JWT
Aligned examples structure and used the term input claim set
Replaced the general SD-JWT VC example with one based on Person Identification Data (PID) from the European Digital Identity Wallet Architecture and Reference Framework
Added/clarified some privacy considerations in Confidentiality during Transport
No longer recommending a claim name for enveloped SD-JWTs
Mention prospective future PQ algs for JWS
Include the public key in the draft, which can be used to verify the issuer signature examples
Clarify that _sd_alg can only be at the top level of the SD-JWT payload
Externalized the SD-JWT library that generates examples
Attempt to improve description of security properties

-04

Improve description of processing of disclosures

-03

Clarify that other specifications may define enveloping multiple Combined Formats for Presentation
Add an example of W3C vc-data-model that uses a JSON-LD object as the claims set
Clarify requirements for the combined formats for issuance and presentation
Added overview of the Security Considerations section
Enhanced examples in the Privacy Considerations section
Allow for recursive disclosures
Discussion on holder binding and privacy of stored credentials
Add some context about SD-JWT being general-purpose despite being a product of the OAuth WG
More explicitly say that SD-JWTs have to be signed asymmetrically (no MAC and no none)
Make sha-256 the default hash algorithm, if the hash alg claim is omitted
Use ES256 instead of RS256 in examples
Rename and move the c14n challenges section to an appendix
A bit more in security considerations for Choice of a Hash Algorithm (1st & 2nd preimage resistant and not majorly truncated)
Remove the notational figures from the Concepts section
Change salt to always be a string (rather than any JSON type)
Fix the Document History (which had a premature list for -03)

-02

Disclosures are now delivered not as a JWT but as separate base64url-encoded JSON objects.
In the SD-JWT, digests are collected under a _sd claim per level.
Terms "II-Disclosures" and "HS-Disclosures" are replaced with "Disclosures".
Holder Binding is now separate from delivering the Disclosures and implemented, if required, with a separate JWT.
Examples updated and modified to properly explain the specifics of the new SD-JWT format.
Examples are now pulled in from the examples directory, not inlined.
Updated and automated the W3C VC example.
Added examples with multibyte characters to show that the specification and demo code work well with UTF-8.
reverted back to hash alg from digest derivation alg (renamed to _sd_alg)
reformatted

-01

introduced blinded claim names
explained why JSON-encoding of values is needed
explained merging algorithm ("processing model")
generalized hash alg to digest derivation alg which also enables HMAC to calculate digests
_sd_hash_alg renamed to sd_digest_derivation_alg
Salt/Value Container (SVC) renamed to Issuer-Issued Disclosures (II-Disclosures)
SD-JWT-Release (SD-JWT-R) renamed to Holder-Selected Disclosures (HS-Disclosures)
sd_disclosure in II-Disclosures renamed to sd_ii_disclosures
sd_disclosure in HS-Disclosures renamed to sd_hs_disclosures
clarified relationship between sd_hs_disclosure and SD-JWT
clarified combined formats for issuance and presentation
clarified security requirements for blinded claim names
improved description of Holder Binding security considerations - especially around the usage of "alg=none".
updated examples
text clarifications
fixed cnf structure in examples
added feature summary

-00

Upload as draft-ietf-oauth-selective-disclosure-jwt-00

[[ pre Working Group Adoption: ]] -02

Added acknowledgements
Improved Security Considerations
Stressed entropy requirements for salts
Python reference implementation clean-up and refactoring
hash_alg renamed to _sd_hash_alg

-01

Editorial fixes
Added hash_alg claim
Renamed _sd to sd_digests and sd_release
Added descriptions on Holder Binding - more work to do
Clarify that signing the SD-JWT is mandatory

-00

Renamed to SD-JWT (focus on JWT instead of JWS since signature is optional)
Make Holder Binding optional
Rename proof to release, since when there is no signature, the term "proof" can be misleading
Improved the structure of the description
Described verification steps
All examples generated from python demo implementation
Examples for structured objects