| Internet-Draft | SD-JWT | March 2024 |
| Fett, et al. | Expires 5 September 2024 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/.¶
Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-selective-disclosure-jwt.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 September 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document specifies conventions for creating JSON Web Signature (JWS) [RFC7515] structures with JSON [RFC8259] objects as the payload while supporting selective disclosure of individual elements of that JSON. Because JSON Web Token (JWT) [RFC7519] 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 specifies an optional mechanism for Key Binding, which is the concept of binding an SD-JWT to a Holder's public key and requiring that the Holder prove possession of the corresponding private key when presenting the SD-JWT. 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.¶
This specification defines¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
base64url denotes the URL-safe base64 encoding without padding defined in Section 2 of [RFC7515].¶
+------------+
| |
| Issuer |
| |
+------------+
|
Issues SD-JWT
including all Disclosures
|
v
+------------+
| |
| Holder |
| |
+------------+
|
Presents SD-JWT
including selected Disclosures
|
v
+-------------+
| |+
| Verifiers ||+
| |||
+-------------+||
+-------------+|
+-------------+
This section describes SD-JWTs with their respective Disclosures and Key Binding at a conceptual level, abstracting from the data formats described in Section 5.¶
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 Section 5. 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.¶
To disclose to a Verifier a subset of the SD-JWT claim values, a Holder sends only the Disclosures of those selectively released claims to the Verifier as part of the SD-JWT.¶
Key Binding is an optional feature. When Key Binding is required by the use-case, the SD-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.¶
For presenting an SD-JWT to a Verifier that enforces Key Binding, the Holder creates a signed document, the Key Binding JWT as defined in Section 5.3, using its private key. This document contains a nonce to ensure the freshness of the signature, an audience value to indicate the intended audience for the document, and a hash that ensures the integrity of the data sent from the Holder to the Verifier. Details of the format of Key Binding JWTs are described in Section 5.3.¶
At a high level, the Verifier¶
The detailed algorithm is described in Section 8.3.¶
An SD-JWT is composed of the following:¶
The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in Section 5.1, Section 5.2, and Section 5.3 respectively.¶
The serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows:¶
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~<optional KB-JWT>¶
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 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 example shows a few different SD-JWT permutations, both with and without various constituent parts.¶
An SD-JWT without Disclosures and without a KB-JWT: <Issuer-signed JWT>~ An SD-JWT without Disclosures and with a KB-JWT: <Issuer-signed JWT>~<KB-JWT> An SD-JWT with Disclosures and without a KB-JWT: <Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~ An SD-JWT with Disclosures and with a KB-JWT: <Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~<KB-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:¶
_sd_alg key described in Section 5.1.1.¶
iss, iat, etc. as defined or required by the application using SD-JWTs.¶
_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 Section 10.12 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 Section 10.8 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.¶
The claim _sd_alg indicates the hash algorithm used by the Issuer to generate
the digests as described in Section 5.2. 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 [IANA.Hash.Algorithms] 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 Section 10 for requirements regarding entropy of the salt, minimum length of the salt, and choice of a hash algorithm.¶
If the Issuer wants to enable Key Binding, it includes a public key
associated with the Holder, or a reference thereto.
The jwk member of the cnf claim as defined in Section 3.2 of [RFC7800] is
suggested for doing so, however, other means can be used.¶
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 to include
the raw public key by value in SD-JWT.¶
Disclosures are created differently depending on whether a claim is an object property (name-value pair) or an array element.¶
For each claim that is an object property and that is to be made selectively disclosable, the Issuer MUST create a Disclosure as follows:¶
Create an array of three elements in this order:¶
_sd, ..., or a claim name existing in the object as a non-selectively disclosable claim.¶
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:¶
["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]¶
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":¶
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNXHUwMGY2Yml1cyJd¶
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Yml1cyJd¶
WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiTcO2Yml1cyIKXQ¶
See Appendix B for some further considerations on the Disclosure format approach.¶
For each claim that is an array element and that is to be made selectively disclosable, the Issuer MUST create a Disclosure as follows:¶
The array MUST contain two elements in this order:¶
The Disclosure string is created by JSON-encoding this array and base64url-encoding the byte representation of the resulting string as described in Section 5.2.1. 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:¶
{
"nationalities": ["DE", "FR"]
}
¶
could be created by first creating the following array:¶
["lklxF5jMYlGTPUovMNIvCA", "FR"]¶
The resulting Disclosure would be: WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0¶
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 Section 5.1.1. 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 [RFC7515] and JWE [RFC7516]. The bytes of the digest MUST then be base64url-encoded.¶
It is important to note that:¶
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.¶
For selectively disclosable claims, the digests of the Disclosures are embedded into the Issuer-signed JWT instead of the claims themselves. The precise way of embedding depends on whether a claim is an object property (name-value pair) or an array element.¶
Digests of Disclosures for object properties are added to an array under the 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 Section 5.2.5.¶
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 Section 5.2.5. 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:¶
{
"given_name": "Alice",
"_sd": ["uutlBuYeMDyjLLTpf6Jxi7yNkEF35jdyWMn9U7b_RYY"]
}
¶
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 Section 5.2.3. 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:¶
{
"nationalities":
["DE", {"...": "w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}]
}
¶
As described in Section 8.3, 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.¶
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 Section 11.3 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 Appendix A.1.¶
This section defines the contents of the optional Key Binding JWT, which the Holder MAY include in the SD-JWT to prove the Key Binding to the Verifier.¶
The JWT MUST contain the following elements:¶
in the JOSE header,¶
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 [RFC7519].¶
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 digest over the Issuer-signed JWT and the selected Disclosures as defined below.¶
The hash digest in sd_hash ensures the integrity of the Presentation. It MUST
be taken over the US-ASCII bytes preceding the KB-JWT in the Presentation, 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:¶
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~¶
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 Section 5.1.1).¶
To validate the signature on the Key Binding JWT, the Verifier MUST use the key material in the SD-JWT. If it is not clear from the SD-JWT, the Key Binding JWT MUST specify which key material the Verifier needs to use to validate the Key Binding JWT signature using JOSE header parameters such as kid and x5c.¶
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 Section 10.6 for security considerations.¶
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.¶
The Issuer is using the following input claim set:¶
{
"sub": "user_42",
"given_name": "John",
"family_name": "Doe",
"email": "johndoe@example.com",
"phone_number": "+1-202-555-0101",
"phone_number_verified": true,
"address": {
"street_address": "123 Main St",
"locality": "Anytown",
"region": "Anystate",
"country": "US"
},
"birthdate": "1940-01-01",
"updated_at": 1570000000,
"nationalities": [
"US",
"DE"
]
}
¶
The Issuer in this case made the following decisions:¶
nationalities array is always visible, but its contents are selectively disclosable.¶
sub element and essential verification data (iss, iat, cnf, etc.) are always visible.¶
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 Section 7.¶
The following payload is used for the SD-JWT:¶
{
"_sd": [
"CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI",
"JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE",
"PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI",
"TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo",
"XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM",
"XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE",
"gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM",
"jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4"
],
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"sub": "user_42",
"nationalities": [
{
"...": "pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo"
},
{
"...": "7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0"
}
],
"_sd_alg": "sha-256",
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
}
}
¶
The following Disclosures are created by the Issuer:¶
Claim given_name:¶
jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4¶
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd¶
["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]¶
Claim family_name:¶
TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo¶
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJd¶
["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]¶
Claim email:¶
JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE¶
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ¶
["6Ij7tM-a5iVPGboS5tmvVA", "email", "johndoe@example.com"]¶
Claim phone_number:¶
PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI¶
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ¶
["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number","+1-202-555-0101"]¶
Claim phone_number_verified:¶
XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM¶
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmllZCIsIHRydWVd¶
["Qg_O64zqAxe412a108iroA", "phone_number_verified", true]¶
Claim address:¶
XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE¶
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0¶
["AJx-095VPrpTtN4QMOqROA", "address", {"street_address":"123 Main St", "locality": "Anytown", "region": "Anystate","country": "US"}]¶
Claim birthdate:¶
gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM¶
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0¶
["Pc33JM2LchcU_lHggv_ufQ", "birthdate", "1940-01-01"]¶
Claim updated_at:¶
CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI¶
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDAwMDAwXQ¶
["G02NSrQfjFXQ7Io09syajA", "updated_at", 1570000000]¶
Array Entry:¶
pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo¶
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0¶
["lklxF5jMYlGTPUovMNIvCA", "US"]¶
Array Entry:¶
7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0¶
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0¶
["nPuoQnkRFq3BIeAm7AnXFA", "DE"]¶
The payload is then signed by the Issuer to create a JWT like the following:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1 SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2 Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15 VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1 ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG MkhaUSJ9fX0.RIOaMsGF0sU1W7vmSHgN6P_70Ziz0c0p1GKgJt2-T23YRDLVulwWMScb xLoIno6Aae3i7KuCjCP3hIlI2sVpKw¶
The issued SD-JWT might look as follows:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1 SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2 Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15 VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1 ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG MkhaUSJ9fX0.RIOaMsGF0sU1W7vmSHgN6P_70Ziz0c0p1GKgJt2-T23YRDLVulwWMScb xLoIno6Aae3i7KuCjCP3hIlI2sVpKw~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgI mdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZh bWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWl sIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZW5IZGhR IiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ~WyJRZ19PNjR6cUF4Z TQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmllZCIsIHRydWVd~WyJBSngt MDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjog IjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFu eXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZR IiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5 YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDAwMDAwXQ~WyJsa2x4RjVqTVlsR1RQVW92T U5JdkNBIiwgIlVTIl0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0~¶
The following non-normative example shows an associated SD-JWT Presentation as
it would be sent from the Holder to the Verifier. Note that it consists of six
~-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.¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1 SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2 Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15 VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1 ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG MkhaUSJ9fX0.RIOaMsGF0sU1W7vmSHgN6P_70Ziz0c0p1GKgJt2-T23YRDLVulwWMScb xLoIno6Aae3i7KuCjCP3hIlI2sVpKw~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgI mZhbWlseV9uYW1lIiwgIkRvZSJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFk ZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5 IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMi fV0~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~eyJhbGciOiAiRVMyNTYiLCA idHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodH RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3MDk1NzI1NzgsICJzZF 9oYXNoIjogInR3OGFlVndkVEpsY0ZvcGNwZm55UkhqdzcwaFdBal84MERyRUFJNHlTMk kifQ.syLVaDTFhKezoXddzLPL9iasGciHdIM96vc-h5aGxjjwA7r793QPO4RRUsSzRck c8leNQ5fK_ZvI3m3bm0GdPQ¶
The following Key Binding JWT payload was created and signed for this presentation by the Holder:¶
{
"nonce": "1234567890",
"aud": "https://verifier.example.org",
"iat": 1709572578,
"sd_hash": "tw8aeVwdTJlcFopcpfnyRHjw70hWAj_80DrEAI4yS2I"
}
¶
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 Appendix A.1 and Appendix A.2.¶
The following input claim set is used as an example throughout this section:¶
{
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"address": {
"street_address": "Schulstr. 12",
"locality": "Schulpforta",
"region": "Sachsen-Anhalt",
"country": "DE"
}
}
¶
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.¶
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.¶
{
"_sd": [
"fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"
],
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"_sd_alg": "sha-256"
}
¶
The Issuer would create the following Disclosure:¶
Claim address:¶
fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do¶
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1bHBmb3J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRyeSI6ICJERSJ9XQ¶
["2GLC42sKQveCfGfryNRN9w", "address", {"street_address":"Schulstr. 12", "locality": "Schulpforta", "region":"Sachsen-Anhalt", "country": "DE"}]¶
The Issuer may instead decide to make the address claim contents selectively disclosable individually:¶
{
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"address": {
"_sd": [
"6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
"KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88",
"WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"
]
},
"_sd_alg": "sha-256"
}
¶
In this case, the Issuer would use the following data in the Disclosures for the address sub-claims:¶
Claim street_address:¶
9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM¶
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlNjaHVsc3RyLiAxMiJd¶
["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]¶
Claim locality:¶
6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0¶
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZvcnRhIl0¶
["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]¶
Claim region:¶
KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88¶
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFuaGFsdCJd¶
["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]¶
Claim country:¶
WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM¶
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ¶
["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]¶
The Issuer may also make one sub-claim of address non-selectively disclosable and hide only the other sub-claims:¶
{
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"address": {
"_sd": [
"6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
"KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88"
],
"country": "DE"
},
"_sd_alg": "sha-256"
}
¶
In this case there would be no Disclosure for country since it is provided in the clear.¶
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:¶
{
"_sd": [
"HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg"
],
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"_sd_alg": "sha-256"
}
¶
The Issuer creates Disclosures first for the sub-claims and then includes their digests in the Disclosure for the address claim:¶
Claim street_address:¶
9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM¶
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlNjaHVsc3RyLiAxMiJd¶
["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]¶
Claim locality:¶
6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0¶
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZvcnRhIl0¶
["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]¶
Claim region:¶
KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88¶
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFuaGFsdCJd¶
["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]¶
Claim country:¶
WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM¶
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ¶
["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]¶
Claim address:¶
HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg¶
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCIsICI5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgIktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8ycm8yamZYTSJdfV0¶
["Qg_O64zqAxe412a108iroA", "address", {"_sd":["6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0","9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM","KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88","WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]¶
Upon receiving an SD-JWT, a Holder or a Verifier needs to ensure that¶
The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT:¶
Validate the Issuer-signed JWT:¶
none algorithm MUST NOT be accepted.¶
_sd_alg claim value is understood and the hash algorithm is deemed secure (see Section 5.1.1).¶
Process the Disclosures and embedded digests in the Issuer-signed JWT as follows:¶
For each Disclosure provided:¶
(*) Identify all embedded digests in the Issuer-signed JWT as follows:¶
(**) For each embedded digest found in the previous step:¶
If the digest was found in an object's _sd key:¶
_sd or ..., the SD-JWT MUST be rejected.¶
_sd key, the SD-JWT MUST be rejected.¶
_sd key, a new claim using the claim name and claim value from the Disclosure.¶
If the digest was found in an array element:¶
_sd keys and their contents from the Issuer-signed JWT payload.¶
_sd_alg from the SD-JWT payload.¶
nbf, iat, and exp in the processed payload. If a required validity-controlling claim is missing (see Section 10.8), 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.¶
If a Key Binding JWT is received by a Holder, the SD-JWT SHOULD be rejected.¶
For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps:¶
Upon receiving a Presentation, in addition to the checks outlined in Section 8.1, Verifiers need to ensure that¶
To this end, Verifiers MUST follow the following steps (or equivalent):¶
If Key Binding is required:¶
none algorithm MUST NOT be accepted.¶
typ of the Key Binding JWT is kb+jwt (see Section 5.3).¶
iat claim, is within an acceptable window.¶
nonce and aud claims.¶
sd_hash claim in the Key Binding JWT.¶
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.¶
This section describes an optional alternate format for SD-JWT using the JWS JSON Serialization from [RFC7515].¶
For both the General and Flattened JSON Serialization, the SD-JWT is represented as a JSON object according
to Section 7.2 of [RFC7515]. The Disclosures (both for issuance and presentation) SHOULD be included in the
serialized JWS using the member name disclosures at the top-level of the JSON object (the same level as the payload member). The
value of the disclosures member is an array of strings where each element is an individual Disclosure
as described in Section 5.2. The Issuer includes a Disclosure for each selectively
disclosable claim of the SD-JWT payload, whereas the Holder includes only the Disclosures
selected for the given presentation.¶
Alternative methods for conveying the Disclosures MAY be used (such as including them in a disclosures
member of an outer JSON structure also containing the JSON Serialized SD-JWT) as dictated by a specific
application or transport protocol. However, the details of such approaches fall outside the scope of this
specification.¶
Verification of the JWS JSON serialized SD-JWT follows the same rules defined in Section 4.4, except that the SD-JWT does not need to be split into component parts and the Disclosures can be found in the respective member of the JSON object (or elsewhere).¶
Using a payload similar to that from Example 1, the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures.¶
{
"payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
ljVGo5SE5hQzF3WSIsICJTRE43OU5McEFuSFBta3JkZVlkRWE4OVhaZHNrME04RE
tZU1FPVTJaeFFjIiwgIlh6RnJ6d3NjTTZHbjZDSkRjNnZWSzhCa01uZkc4dk9TS2
ZwUElaZEFmZEUiLCAiZ2JPc0k0RWRxMngyS3ctdzV3UEV6YWtvYjloVjFjUkQwQV
ROM29RTDlKTSIsICJqTUNYVnotLTliOHgzN1ljb0RmWFFpbnp3MXdaY2NjZkZSQk
NGR3FkRzJvIiwgIm9LSTFHZDJmd041V3d2amxGa29oaWRHdmltLTMxT3VsUjNxMG
hyRE8wNzgiXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbSIsIC
JpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbGciOi
Aic2hhLTI1NiJ9",
"protected":
"eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
"signature": "NSUqfh9INRyW_bGphuEgkKJaiOuov7qjs68BMJiHLisDeZ99OIKM
ZZVuCjVCxELBmvA6jQW4e5_uxj14ak6bcw",
"disclosures": [
"WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICJqb2huX2RvZV80MiJ
d",
"WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9obiJ
d",
"WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZSJ
d",
"WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgImpvaG5kb2VAZXh
hbXBsZS5jb20iXQ",
"WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIrMS0
yMDItNTU1LTAxMDEiXQ",
"WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9
hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iL
CAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0",
"WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQwLTA
xLTAxIl0"
]
}
¶
Below is a non-normative example of a presentation of the JWS JSON serialized SD-JWT, where the Holder
has selected to disclose given_name, family_name, and address.¶
{
"payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
ljVGo5SE5hQzF3WSIsICJTRE43OU5McEFuSFBta3JkZVlkRWE4OVhaZHNrME04RE
tZU1FPVTJaeFFjIiwgIlh6RnJ6d3NjTTZHbjZDSkRjNnZWSzhCa01uZkc4dk9TS2
ZwUElaZEFmZEUiLCAiZ2JPc0k0RWRxMngyS3ctdzV3UEV6YWtvYjloVjFjUkQwQV
ROM29RTDlKTSIsICJqTUNYVnotLTliOHgzN1ljb0RmWFFpbnp3MXdaY2NjZkZSQk
NGR3FkRzJvIiwgIm9LSTFHZDJmd041V3d2amxGa29oaWRHdmltLTMxT3VsUjNxMG
hyRE8wNzgiXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbSIsIC
JpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbGciOi
Aic2hhLTI1NiJ9",
"protected":
"eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
"signature": "NSUqfh9INRyW_bGphuEgkKJaiOuov7qjs68BMJiHLisDeZ99OIKM
ZZVuCjVCxELBmvA6jQW4e5_uxj14ak6bcw",
"disclosures": [
"WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZSJ
d",
"WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9
hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iL
CAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0",
"WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9obiJ
d"
]
}
¶
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 Section 10.6, the application of Key Binding can ensure that the presenter of an SD-JWT credential is the legitimate Holder of the credential.¶
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 [IANA.JWS.Algorithms] can be used, including post-quantum algorithms, when they are ready.¶
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 Section 8.3 ensure that the Verifier checks the Disclosures correctly.¶
The security model that conceals the plaintext claims relies on the fact that salts not revealed to an attacker cannot be learned or guessed by the attacker, even if other salts have been revealed. It is vitally important to adhere to this principle. As such, each salt MUST be created in such a manner that it is cryptographically random, long enough, and has high entropy that it is not practical for the attacker to guess. A new salt MUST be chosen for each claim independently from other salts. See Randomness Requirements for Security [RFC4086] 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 Example 3 in the Appendix,
where multiple claims with the name type appear, but each of them has
a different salt.¶
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 [IANA.Hash.Algorithms]
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 aims to ensure that the presenter of an SD-JWT credential is actually the legitimate Holder of the credential. An SD-JWT 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 or that can be misinterpreted. For this reason, when deciding whether Key Binding is required or not, Verifiers MUST NOT take into account¶
If a Verifier has decided that Key Binding is required for a particular use case and the Key Binding is not present, does not fulfill the requirements (e.g., on the signing algorithm), or no recognized Key Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in Section 8.3.¶
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.¶
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 Section 8.1.¶
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.¶
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 [RFC7517]. 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.¶
When Key Binding is not enforced, any entity in possession of an SD-JWT Presentation can forward the contents to third parties. 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.¶
In a Presentation, the Issuer-signed JWT is integrity-protected by the Issuer's signature, and the Disclosures are integrity-protected by the digests included in the Issuer-signed JWT. If used, the KB-JWT, besides proving Key Binding, protects the integrity of the set of Disclosures the Holder disclosed.¶
Section 3.11 of [RFC8725] 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 [RFC7515] recommends that the "application/" prefix be omitted, so
"example+sd-jwt" would be the value of the typ header parameter.¶
The privacy principles of [ISO.29100] should be adhered to.¶
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 Section 10.6, 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 Section 10.9, 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.¶
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) [RFC7516] 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.¶
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 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:¶
The following types of unlinkability are considered here:¶
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).¶
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.¶
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, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard 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.¶
This specification requests registration of the following Claims in the IANA "JSON Web Token Claims" registry [IANA.JWT] established by [RFC7519].¶
_sd¶
...¶
_sd_alg¶
sd_hash¶
This section requests registration of the following media types [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838].¶
To indicate that the content is an SD-JWT:¶
Additional information:¶
To indicate that the content is a JWS JSON serialized SD-JWT:¶
Additional information:¶
To indicate that the content is a Key Binding JWT:¶
Additional information:¶
This section requests registration of the "+sd-jwt" structured syntax suffix in the "Structured Syntax Suffix" registry [IANA.StructuredSuffix] in the manner described in [RFC6838], which can be used to indicate that the media type is encoded as an SD-JWT.¶
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.¶
In this example, in contrast to Example 1, 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:¶
{
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"given_name": "太郎",
"family_name": "山田",
"email": "\"unusual email address\"@example.jp",
"phone_number": "+81-80-1234-5678",
"address": {
"street_address": "東京都港区芝公園４丁目２−８",
"locality": "東京都",
"region": "港区",
"country": "JP"
},
"birthdate": "1940-01-01"
}
¶
The Issuer also decided to add decoy digests to prevent the Verifier from deducing the true number of claims.¶
The following payload is used for the SD-JWT:¶
{
"_sd": [
"C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU",
"Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE",
"MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY",
"X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g",
"Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE",
"fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs",
"ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q",
"s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U"
],
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"address": {
"_sd": [
"6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E",
"AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg",
"PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k",
"b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek",
"cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ",
"glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4",
"rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA",
"uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4"
]
},
"_sd_alg": "sha-256"
}
¶
The following Disclosures are created:¶
Claim sub:¶
X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g¶
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1iNTg5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ¶
["2GLC42sKQveCfGfryNRN9w", "sub","6c5c0a49-b589-431d-bae7-219122a9ec2c"]¶
Claim given_name:¶
ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q¶
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1OTJhXHU5MGNlIl0¶
["eluV5Og3gSNII8EYnsxA_A", "given_name", "\u592a\u90ce"]¶
Claim family_name:¶
C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU¶
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1NWM3MVx1NzUzMCJd¶
["6Ij7tM-a5iVPGboS5tmvVA", "family_name", "\u5c71\u7530"]¶
Claim email:¶
Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE¶
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3VhbCBlbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd¶
["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual emailaddress\"@example.jp"]¶
Claim phone_number:¶
s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U¶
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIrODEtODAtMTIzNC01Njc4Il0¶
["Qg_O64zqAxe412a108iroA", "phone_number","+81-80-1234-5678"]¶
Claim street_address:¶
6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E¶
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwgIlx1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1NTcxMlx1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd¶
["AJx-095VPrpTtN4QMOqROA", "street_address", "\u6771\u4eac\u90fd\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u2212\uff18"]¶
Claim locality:¶
rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA¶
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3MVx1NGVhY1x1OTBmZCJd¶
["Pc33JM2LchcU_lHggv_ufQ", "locality", "\u6771\u4eac\u90fd"]¶
Claim region:¶
PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k¶
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZcdTUzM2EiXQ¶
["G02NSrQfjFXQ7Io09syajA", "region", "\u6e2f\u533a"]¶
Claim country:¶
uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4¶
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ¶
["lklxF5jMYlGTPUovMNIvCA", "country", "JP"]¶
Claim birthdate:¶
MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY¶
WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0¶
["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 and without a Key Binding JWT could look like:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb IkM5aW5wNllvUmFFWFI0Mjd6WUpQN1FyazFXSF84YmR3T0FfWVVyVW5HUVUiLCAiS3Vl dDF5QWEwSElRdlluT1ZkNTloY1ZpTzlVZzZKMmtTZnFZUkJlb3d2RSIsICJNTWxkT0ZG ekIyZDB1bWxtcFRJYUdlcmhXZFVfUHBZZkx2S2hoX2ZfOWFZIiwgIlg2WkFZT0lJMnZQ TjQwVjd4RXhad1Z3ejd5Um1MTmNWd3Q1REw4Ukx2NGciLCAiWTM0em1JbzBRTExPdGRN cFhHd2pCZ0x2cjE3eUVoaFlUMEZHb2ZSLWFJRSIsICJmeUdwMFdUd3dQdjJKRFFsbjFs U2lhZW9iWnNNV0ExMGJRNTk4OS05RFRzIiwgIm9tbUZBaWNWVDhMR0hDQjB1eXd4N2ZZ dW8zTUhZS08xNWN6LVJaRVlNNVEiLCAiczBCS1lzTFd4UVFlVTh0VmxsdE03TUtzSVJU ckVJYTFQa0ptcXhCQmY1VSJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAiYWRkcmVz cyI6IHsiX3NkIjogWyI2YVVoelloWjdTSjFrVm1hZ1FBTzN1MkVUTjJDQzFhSGhlWnBL bmFGMF9FIiwgIkF6TGxGb2JrSjJ4aWF1cFJFUHlvSnotOS1OU2xkQjZDZ2pyN2ZVeW9I emciLCAiUHp6Y1Z1MHFiTXVCR1NqdWxmZXd6a2VzRDl6dXRPRXhuNUVXTndrclEtayIs ICJiMkRrdzBqY0lGOXJHZzhfUEY4WmN2bmNXN3p3Wmo1cnlCV3ZYZnJwemVrIiwgImNQ WUpISVo4VnUtZjlDQ3lWdWIyVWZnRWs4anZ2WGV6d0sxcF9KbmVlWFEiLCAiZ2xUM2hy U1U3ZlNXZ3dGNVVEWm1Xd0JUdzMyZ25VbGRJaGk4aEdWQ2FWNCIsICJydkpkNmlxNlQ1 ZWptc0JNb0d3dU5YaDlxQUFGQVRBY2k0MG9pZEVlVnNBIiwgInVOSG9XWWhYc1poVkpD TkUyRHF5LXpxdDd0NjlnSkt5NVFhRnY3R3JNWDQiXX0sICJfc2RfYWxnIjogInNoYS0y NTYifQ.H0uI6M5t7BDfAt_a3Rw5zq4IiYNtkMORENcQFXYkW1LURRp66baOXRcxb164s nsUJneI-XLM2-COCTX1y7Sedw~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2 lvbiIsICJcdTZlMmZcdTUzM2EiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImN vdW50cnkiLCAiSlAiXQ~¶
In this example, an SD-JWT with a complex object is represented. The data structures defined in OIDC4IDA [OIDC.IDA] are used.¶
The Issuer is using the following input claim set:¶
{
"verified_claims": {
"verification": {
"trust_framework": "de_aml",
"time": "2012-04-23T18:25Z",
"verification_process": "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7",
"evidence": [
{
"type": "document",
"method": "pipp",
"time": "2012-04-22T11:30Z",
"document": {
"type": "idcard",
"issuer": {
"name": "Stadt Augsburg",
"country": "DE"
},
"number": "53554554",
"date_of_issuance": "2010-03-23",
"date_of_expiry": "2020-03-22"
}
}
]
},
"claims": {
"given_name": "Max",
"family_name": "Müller",
"nationalities": [
"DE"
],
"birthdate": "1956-01-28",
"place_of_birth": {
"country": "IS",
"locality": "Þykkvabæjarklaustur"
},
"address": {
"locality": "Maxstadt",
"postal_code": "12344",
"country": "DE",
"street_address": "Weidenstraße 22"
}
}
},
"birth_middle_name": "Timotheus",
"salutation": "Dr.",
"msisdn": "49123456789"
}
¶
The following payload is used for the SD-JWT:¶
{
"_sd": [
"-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw",
"IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg",
"otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI"
],
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"verified_claims": {
"verification": {
"_sd": [
"7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc",
"vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw"
],
"trust_framework": "de_aml",
"evidence": [
{
"...": "tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k"
}
]
},
"claims": {
"_sd": [
"RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo",
"S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo",
"WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk",
"Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk",
"_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ",
"hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE"
]
}
},
"_sd_alg": "sha-256"
}
¶
The following Disclosures are created by the Issuer:¶
Claim time:¶
vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw¶
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1QxODoyNVoiXQ¶
["2GLC42sKQveCfGfryNRN9w", "time", "2012-04-23T18:25Z"]¶
Claim verification_process:¶
7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc¶
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9jZXNzIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ¶
["eluV5Og3gSNII8EYnsxA_A", "verification_process","f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"]¶
Claim type:¶
G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk¶
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQiXQ¶
["6Ij7tM-a5iVPGboS5tmvVA", "type", "document"]¶
Claim method:¶
WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ¶
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0¶
["eI8ZWm9QnKPpNPeNenHdhQ", "method", "pipp"]¶
Claim time:¶
9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI¶
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0yMlQxMTozMFoiXQ¶
["Qg_O64zqAxe412a108iroA", "time", "2012-04-22T11:30Z"]¶
Claim document:¶
IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4¶
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBlIjogImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1cmciLCAiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0IiwgImRhdGVfb2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4cGlyeSI6ICIyMDIwLTAzLTIyIn1d¶
["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:¶
tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k¶
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDdQSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdGcldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d¶
["Pc33JM2LchcU_lHggv_ufQ", {"_sd":["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI","G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk","IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4","WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]¶
Claim given_name:¶
S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo¶
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0¶
["G02NSrQfjFXQ7Io09syajA", "given_name", "Max"]¶
Claim family_name:¶
Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk¶
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTAwZmNsbGVyIl0¶
["lklxF5jMYlGTPUovMNIvCA", "family_name", "M\u00fcller"]¶
Claim nationalities:¶
hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE¶
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d¶
["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]¶
Claim birthdate:¶
WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk¶
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2LTAxLTI4Il0¶
["5bPs1IquZNa0hkaFzzzZNw", "birthdate", "1956-01-28"]¶
Claim place_of_birth:¶
RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo¶
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwgeyJjb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1MDBlNmphcmtsYXVzdHVyIn1d¶
["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", {"country":"IS", "locality": "\u00deykkvab\u00e6jarklaustur"}]¶
Claim address:¶
_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ¶
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2FsaXR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0¶
["y1sVU5wdfJahVdgwPgS7RQ", "address", {"locality":"Maxstadt", "postal_code": "12344", "country": "DE","street_address": "Weidenstra\u00dfe 22"}]¶
Claim birth_middle_name:¶
otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI¶
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1lIiwgIlRpbW90aGV1cyJd¶
["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name", "Timotheus"]¶
Claim salutation:¶
-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw¶
WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIuIl0¶
["C9GSoujviJquEgYfojCb1A", "salutation", "Dr."]¶
Claim msisdn:¶
IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg¶
WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1Njc4OSJd¶
["kx5kF17V-x0JmwUx9vgvtw", "msisdn", "49123456789"]¶
The following is how a presentation of the SD-JWT without a Key Binding JWT could look like:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb Ii1hU3puSWQ5bVdNOG9jdVFvbENsbHN4VmdncTEtdkhXNE90bmhVdFZtV3ciLCAiSUti cllObjN2QTdXRUZyeXN2YmRCSmpERFVfRXZRSXIwVzE4dlRScFVTZyIsICJvdGt4dVQx NG5CaXd6TkozTVBhT2l0T2w5cFZuWE9hRUhhbF94a3lOZktJIl0sICJpc3MiOiAiaHR0 cHM6Ly9pc3N1ZXIuZXhhbXBsZS5jb20iLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6 IDE4ODMwMDAwMDAsICJ2ZXJpZmllZF9jbGFpbXMiOiB7InZlcmlmaWNhdGlvbiI6IHsi X3NkIjogWyI3aDRVRTlxU2N2REtvZFhWQ3VvS2ZLQkpwVkJmWE1GX1RtQUdWYVplM1Nj IiwgInZUd2UzcmFISUZZZ0ZBM3hhVUQyYU14Rno1b0RvOGlCdTA1cUtsT2c5THciXSwg InRydXN0X2ZyYW1ld29yayI6ICJkZV9hbWwiLCAiZXZpZGVuY2UiOiBbeyIuLi4iOiAi dFlKMFREdWN5WlpDUk1iUk9HNHFSTzV2a1BTRlJ4RmhVRUxjMThDU2wzayJ9XX0sICJj bGFpbXMiOiB7Il9zZCI6IFsiUmlPaUNuNl93NVpIYWFka1FNcmNRSmYwSnRlNVJ3dXJS czU0MjMxRFRsbyIsICJTXzQ5OGJicEt6QjZFYW5mdHNzMHhjN2NPYW9uZVJyM3BLcjdO ZFJtc01vIiwgIldOQS1VTks3Rl96aHNBYjlzeVdPNklJUTF1SGxUbU9VOHI4Q3ZKMGNJ TWsiLCAiV3hoX3NWM2lSSDliZ3JUQkppLWFZSE5DTHQtdmpoWDFzZC1pZ09mXzlsayIs ICJfTy13SmlIM2VuU0I0Uk9IbnRUb1FUOEptTHR6LW1oTzJmMWM4OVhvZXJRIiwgImh2 RFhod21HY0pRc0JDQTJPdGp1TEFjd0FNcERzYVUwbmtvdmNLT3FXTkUiXX19LCAiX3Nk X2FsZyI6ICJzaGEtMjU2In0.BYUpdUIaUTNj5UlPBk6g0GhDp213yGD_HIMk8P45LwkS AfZgc_ayGnf9VC4gebeE-crDoonxf89Y7qsTA-4qdQ~WyIyR0xDNDJzS1F2ZUNmR2Zye U5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1QxODoyNVoiXQ~WyJQYzMzSk0yTGNoY1 VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDdQSzBuc1FETDhCMDZsbWRnVj NMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRX RtMWJHX3djYUtJayIsICJJaHdGcldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZU JJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMW JFVlEiXX1d~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwI l0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0~W yJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTAwZmNsb GVyIl0~WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2Fsa XR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiO iAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0~¶
After the validation, the Verifier will have the following data for further processing:¶
{
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"verified_claims": {
"verification": {
"trust_framework": "de_aml",
"evidence": [
{
"method": "pipp"
}
],
"time": "2012-04-23T18:25Z"
},
"claims": {
"given_name": "Max",
"family_name": "Müller",
"address": {
"locality": "Maxstadt",
"postal_code": "12344",
"country": "DE",
"street_address": "Weidenstraße 22"
}
}
}
}
¶
This example shows how the artifacts defined in this specification could be used in the context of SD-JWT-based Verifiable Credentials (SD-JWT VC) [I-D.ietf-oauth-sd-jwt-vc] to represent the concept of a Person Identification Data (PID) [EUDIW.ARF] 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:¶
{
"vct": "https://bmi.bund.example/credential/pid/1.0",
"given_name": "Erika",
"family_name": "Mustermann",
"birthdate": "1963-08-12",
"source_document_type": "id_card",
"address": {
"street_address": "Heidestraße 17",
"locality": "Köln",
"postal_code": "51147",
"country": "DE"
},
"nationalities": [
"DE"
],
"gender": "female",
"birth_family_name": "Gabler",
"place_of_birth": {
"locality": "Berlin",
"country": "DE"
},
"also_known_as": "Schwester Agnes",
"age_equal_or_over": {
"12": true,
"14": true,
"16": true,
"18": true,
"21": true,
"65": false
}
}
¶
The following is the issued SD-JWT:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogInZjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1 uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiOVpicGxDN1R kRVc3cWFsNkJCWmxNdHFKZG1lRU9pWGV2ZEpsb1hWSmRSUSIsICJJMDBmY0ZVb0RYQ3V jcDV5eTJ1anFQc3NEVkdhV05pVWxpTnpfYXdEMGdjIiwgIklFQllTSkdOaFhJbHJRbzU 4eWtYbTJaeDN5bGw5WmxUdFRvUG8xN1FRaVkiLCAiTGFpNklVNmQ3R1FhZ1hSN0F2R1R yblhnU2xkM3o4RUlnX2Z2M2ZPWjFXZyIsICJodkRYaHdtR2NKUXNCQ0EyT3RqdUxBY3d BTXBEc2FVMG5rb3ZjS09xV05FIiwgImlrdXVyOFE0azhxM1ZjeUE3ZEMtbU5qWkJrUmV EVFUtQ0c0bmlURTdPVFUiLCAicXZ6TkxqMnZoOW80U0VYT2ZNaVlEdXZUeWtkc1dDTmc wd1RkbHIwQUVJTSIsICJ3elcxNWJoQ2t2a3N4VnZ1SjhSRjN4aThpNjRsbjFqb183NkJ DMm9hMXVnIiwgInpPZUJYaHh2SVM0WnptUWNMbHhLdUVBT0dHQnlqT3FhMXoySW9WeF9 ZRFEiXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbSIsICJpYXQiOiA xNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgInZjdCI6ICJodHRwczovL2JtaS5 idW5kLmV4YW1wbGUvY3JlZGVudGlhbC9waWQvMS4wIiwgImFnZV9lcXVhbF9vcl9vdmV yIjogeyJfc2QiOiBbIkZjOElfMDdMT2NnUHdyREpLUXlJR085N3dWc09wbE1Makh2UkM 0UjQtV2ciLCAiWEx0TGphZFVXYzl6Tl85aE1KUm9xeTQ2VXNDS2IxSXNoWnV1cVVGS1N DQSIsICJhb0NDenNDN3A0cWhaSUFoX2lkUkNTQ2E2NDF1eWNuYzh6UGZOV3o4bngwIiw gImYxLVAwQTJkS1dhdnYxdUZuTVgyQTctRVh4dmhveHY1YUhodUVJTi1XNjQiLCAiazV oeTJyMDE4dnJzSmpvLVZqZDZnNnl0N0Fhb25Lb25uaXVKOXplbDNqbyIsICJxcDdaX0t 5MVlpcDBzWWdETzN6VnVnMk1GdVBOakh4a3NCRG5KWjRhSS1jIl19LCAiX3NkX2FsZyI 6ICJzaGEtMjU2IiwgImNuZiI6IHsiandrIjogeyJrdHkiOiAiRUMiLCAiY3J2IjogIlA tMjU2IiwgIngiOiAiVENBRVIxOVp2dTNPSEY0ajRXNHZmU1ZvSElQMUlMaWxEbHM3dkN lR2VtYyIsICJ5IjogIlp4amlXV2JaTVFHSFZXS1ZRNGhiU0lpcnNWZnVlY0NFNnQ0alQ 5RjJIWlEifX19.jeF9GjGbjCr0NND0SbkV4HeSpsysixALFScJl4bYkIykXhF6cRtqni 64_d7X6Ef8Rx80rfsgXe0H7TdiSoIJOw~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3Iiw gImdpdmVuX25hbWUiLCAiRXJpa2EiXQ~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwg ImZhbWlseV9uYW1lIiwgIk11c3Rlcm1hbm4iXQ~WyI2SWo3dE0tYTVpVlBHYm9TNXRtd lZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA4LTEyIl0~WyJlSThaV205UW5LUHBOUGVOZ W5IZGhRIiwgInNvdXJjZV9kb2N1bWVudF90eXBlIiwgImlkX2NhcmQiXQ~WyJRZ19PNj R6cUF4ZTQxMmExMDhpcm9BIiwgInN0cmVldF9hZGRyZXNzIiwgIkhlaWRlc3RyYVx1MD BkZmUgMTciXQ~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImxvY2FsaXR5IiwgIkt cdTAwZjZsbiJd~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgInBvc3RhbF9jb2RlIi wgIjUxMTQ3Il0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImNvdW50cnkiLCAiRE UiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFs iWEZjN3pYUG03enpWZE15d20yRXVCZmxrYTVISHF2ZjhVcF9zek5HcXZpZyIsICJiZDF FVnpnTm9wVWs0RVczX2VRMm4zX05VNGl1WE9IdjlYYkdITjNnMVRFIiwgImZfRlFZZ3Z RV3Z5VnFObklYc0FSbE55ZTdZR3A4RTc3Z1JBamFxLXd2bnciLCAidjRra2JfcFAxamx 2VWJTanR5YzVicWNXeUEtaThYTHZoVllZN1pUMHRiMCJdfV0~WyJuUHVvUW5rUkZxM0J JZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d~WyI1YlBzMUlxdVpOYT Boa2FGenp6Wk53IiwgImdlbmRlciIsICJmZW1hbGUiXQ~WyI1YTJXMF9OcmxFWnpmcW1 rXzdQcS13IiwgImJpcnRoX2ZhbWlseV9uYW1lIiwgIkdhYmxlciJd~WyJ5MXNWVTV3ZG ZKYWhWZGd3UGdTN1JRIiwgImxvY2FsaXR5IiwgIkJlcmxpbiJd~WyJIYlE0WDhzclZXM 1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwgeyJfc2QiOiBbIldwaEhvSUR5b 1diQXBEQzR6YnV3UjQweGwweExoRENfY3Y0dHNTNzFyRUEiXSwgImNvdW50cnkiOiAiR EUifV0~WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgImFsc29fa25vd25fYXMiLCAiU 2Nod2VzdGVyIEFnbmVzIl0~WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjEyIiwgd HJ1ZV0~WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE0IiwgdHJ1ZV0~WyJPQktsV FZsdkxnLUFkd3FZR2JQOFpBIiwgIjE2IiwgdHJ1ZV0~WyJNMEpiNTd0NDF1YnJrU3V5c kRUM3hBIiwgIjE4IiwgdHJ1ZV0~WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjIxI iwgdHJ1ZV0~WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgIjY1IiwgZmFsc2Vd~¶
The following payload is used for the SD-JWT:¶
{
"_sd": [
"0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg",
"9ZbplC7TdEW7qal6BBZlMtqJdmeEOiXevdJloXVJdRQ",
"I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc",
"IEBYSJGNhXIlrQo58ykXm2Zx3yll9ZlTtToPo17QQiY",
"Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg",
"hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE",
"ikuur8Q4k8q3VcyA7dC-mNjZBkReDTU-CG4niTE7OTU",
"qvzNLj2vh9o4SEXOfMiYDuvTykdsWCNg0wTdlr0AEIM",
"wzW15bhCkvksxVvuJ8RF3xi8i64ln1jo_76BC2oa1ug",
"zOeBXhxvIS4ZzmQcLlxKuEAOGGByjOqa1z2IoVx_YDQ"
],
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"vct": "https://bmi.bund.example/credential/pid/1.0",
"age_equal_or_over": {
"_sd": [
"Fc8I_07LOcgPwrDJKQyIGO97wVsOplMLjHvRC4R4-Wg",
"XLtLjadUWc9zN_9hMJRoqy46UsCKb1IshZuuqUFKSCA",
"aoCCzsC7p4qhZIAh_idRCSCa641uycnc8zPfNWz8nx0",
"f1-P0A2dKWavv1uFnMX2A7-EXxvhoxv5aHhuEIN-W64",
"k5hy2r018vrsJjo-Vjd6g6yt7AaonKonniuJ9zel3jo",
"qp7Z_Ky1Yip0sYgDO3zVug2MFuPNjHxksBDnJZ4aI-c"
]
},
"_sd_alg": "sha-256",
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
}
}
¶
The following Disclosures are created by the Issuer:¶
Claim given_name:¶
0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg¶
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJpa2EiXQ¶
["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]¶
Claim family_name:¶
I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc¶
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11c3Rlcm1hbm4iXQ¶
["eluV5Og3gSNII8EYnsxA_A", "family_name", "Mustermann"]¶
Claim birthdate:¶
Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg¶
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA4LTEyIl0¶
["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1963-08-12"]¶
Claim source_document_type:¶
qvzNLj2vh9o4SEXOfMiYDuvTykdsWCNg0wTdlr0AEIM¶
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInNvdXJjZV9kb2N1bWVudF90eXBlIiwgImlkX2NhcmQiXQ¶
["eI8ZWm9QnKPpNPeNenHdhQ", "source_document_type","id_card"]¶
Claim street_address:¶
bd1EVzgNopUk4EW3_eQ2n3_NU4iuXOHv9XbGHN3g1TE¶
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInN0cmVldF9hZGRyZXNzIiwgIkhlaWRlc3RyYVx1MDBkZmUgMTciXQ¶
["Qg_O64zqAxe412a108iroA", "street_address","Heidestra\u00dfe 17"]¶
Claim locality:¶
f_FQYgvQWvyVqNnIXsARlNye7YGp8E77gRAjaq-wvnw¶
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImxvY2FsaXR5IiwgIktcdTAwZjZsbiJd¶
["AJx-095VPrpTtN4QMOqROA", "locality", "K\u00f6ln"]¶
Claim postal_code:¶
XFc7zXPm7zzVdMywm2EuBflka5HHqvf8Up_szNGqvig¶
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgInBvc3RhbF9jb2RlIiwgIjUxMTQ3Il0¶
["Pc33JM2LchcU_lHggv_ufQ", "postal_code", "51147"]¶
Claim country:¶
v4kkb_pP1jlvUbSjtyc5bqcWyA-i8XLvhVYY7ZT0tb0¶
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImNvdW50cnkiLCAiREUiXQ¶
["G02NSrQfjFXQ7Io09syajA", "country", "DE"]¶
Claim address:¶
zOeBXhxvIS4ZzmQcLlxKuEAOGGByjOqa1z2IoVx_YDQ¶
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiWEZjN3pYUG03enpWZE15d20yRXVCZmxrYTVISHF2ZjhVcF9zek5HcXZpZyIsICJiZDFFVnpnTm9wVWs0RVczX2VRMm4zX05VNGl1WE9IdjlYYkdITjNnMVRFIiwgImZfRlFZZ3ZRV3Z5VnFObklYc0FSbE55ZTdZR3A4RTc3Z1JBamFxLXd2bnciLCAidjRra2JfcFAxamx2VWJTanR5YzVicWNXeUEtaThYTHZoVllZN1pUMHRiMCJdfV0¶
["lklxF5jMYlGTPUovMNIvCA", "address", {"_sd":["XFc7zXPm7zzVdMywm2EuBflka5HHqvf8Up_szNGqvig","bd1EVzgNopUk4EW3_eQ2n3_NU4iuXOHv9XbGHN3g1TE","f_FQYgvQWvyVqNnIXsARlNye7YGp8E77gRAjaq-wvnw","v4kkb_pP1jlvUbSjtyc5bqcWyA-i8XLvhVYY7ZT0tb0"]}]¶
Claim nationalities:¶
hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE¶
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d¶
["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]¶
Claim gender:¶
IEBYSJGNhXIlrQo58ykXm2Zx3yll9ZlTtToPo17QQiY¶
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImdlbmRlciIsICJmZW1hbGUiXQ¶
["5bPs1IquZNa0hkaFzzzZNw", "gender", "female"]¶
Claim birth_family_name:¶
ikuur8Q4k8q3VcyA7dC-mNjZBkReDTU-CG4niTE7OTU¶
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImJpcnRoX2ZhbWlseV9uYW1lIiwgIkdhYmxlciJd¶
["5a2W0_NrlEZzfqmk_7Pq-w", "birth_family_name", "Gabler"]¶
Claim locality:¶
WphHoIDyoWbApDC4zbuwR40xl0xLhDC_cv4tsS71rEA¶
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImxvY2FsaXR5IiwgIkJlcmxpbiJd¶
["y1sVU5wdfJahVdgwPgS7RQ", "locality", "Berlin"]¶
Claim place_of_birth:¶
wzW15bhCkvksxVvuJ8RF3xi8i64ln1jo_76BC2oa1ug¶
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwgeyJfc2QiOiBbIldwaEhvSUR5b1diQXBEQzR6YnV3UjQweGwweExoRENfY3Y0dHNTNzFyRUEiXSwgImNvdW50cnkiOiAiREUifV0¶
["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd":["WphHoIDyoWbApDC4zbuwR40xl0xLhDC_cv4tsS71rEA"], "country":"DE"}]¶
Claim also_known_as:¶
9ZbplC7TdEW7qal6BBZlMtqJdmeEOiXevdJloXVJdRQ¶
WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgImFsc29fa25vd25fYXMiLCAiU2Nod2VzdGVyIEFnbmVzIl0¶
["C9GSoujviJquEgYfojCb1A", "also_known_as", "SchwesterAgnes"]¶
Claim 12:¶
Fc8I_07LOcgPwrDJKQyIGO97wVsOplMLjHvRC4R4-Wg¶
WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjEyIiwgdHJ1ZV0¶
["kx5kF17V-x0JmwUx9vgvtw", "12", true]¶
Claim 14:¶
f1-P0A2dKWavv1uFnMX2A7-EXxvhoxv5aHhuEIN-W64¶
WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE0IiwgdHJ1ZV0¶
["H3o1uswP760Fi2yeGdVCEQ", "14", true]¶
Claim 16:¶
k5hy2r018vrsJjo-Vjd6g6yt7AaonKonniuJ9zel3jo¶
WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE2IiwgdHJ1ZV0¶
["OBKlTVlvLg-AdwqYGbP8ZA", "16", true]¶
Claim 18:¶
qp7Z_Ky1Yip0sYgDO3zVug2MFuPNjHxksBDnJZ4aI-c¶
WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjE4IiwgdHJ1ZV0¶
["M0Jb57t41ubrkSuyrDT3xA", "18", true]¶
Claim 21:¶
aoCCzsC7p4qhZIAh_idRCSCa641uycnc8zPfNWz8nx0¶
WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjIxIiwgdHJ1ZV0¶
["DsmtKNgpV4dAHpjrcaosAw", "21", true]¶
Claim 65:¶
XLtLjadUWc9zN_9hMJRoqy46UsCKb1IshZuuqUFKSCA¶
WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgIjY1IiwgZmFsc2Vd¶
["eK5o5pHfgupPpltj1qhAJw", "65", false]¶
The following is how a presentation of the SD-JWT with a Key Binding JWT that discloses only nationality and the fact that the person is over 18 years old could look like:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogInZjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1 uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiOVpicGxDN1R kRVc3cWFsNkJCWmxNdHFKZG1lRU9pWGV2ZEpsb1hWSmRSUSIsICJJMDBmY0ZVb0RYQ3V jcDV5eTJ1anFQc3NEVkdhV05pVWxpTnpfYXdEMGdjIiwgIklFQllTSkdOaFhJbHJRbzU 4eWtYbTJaeDN5bGw5WmxUdFRvUG8xN1FRaVkiLCAiTGFpNklVNmQ3R1FhZ1hSN0F2R1R yblhnU2xkM3o4RUlnX2Z2M2ZPWjFXZyIsICJodkRYaHdtR2NKUXNCQ0EyT3RqdUxBY3d BTXBEc2FVMG5rb3ZjS09xV05FIiwgImlrdXVyOFE0azhxM1ZjeUE3ZEMtbU5qWkJrUmV EVFUtQ0c0bmlURTdPVFUiLCAicXZ6TkxqMnZoOW80U0VYT2ZNaVlEdXZUeWtkc1dDTmc wd1RkbHIwQUVJTSIsICJ3elcxNWJoQ2t2a3N4VnZ1SjhSRjN4aThpNjRsbjFqb183NkJ DMm9hMXVnIiwgInpPZUJYaHh2SVM0WnptUWNMbHhLdUVBT0dHQnlqT3FhMXoySW9WeF9 ZRFEiXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbSIsICJpYXQiOiA xNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgInZjdCI6ICJodHRwczovL2JtaS5 idW5kLmV4YW1wbGUvY3JlZGVudGlhbC9waWQvMS4wIiwgImFnZV9lcXVhbF9vcl9vdmV yIjogeyJfc2QiOiBbIkZjOElfMDdMT2NnUHdyREpLUXlJR085N3dWc09wbE1Makh2UkM 0UjQtV2ciLCAiWEx0TGphZFVXYzl6Tl85aE1KUm9xeTQ2VXNDS2IxSXNoWnV1cVVGS1N DQSIsICJhb0NDenNDN3A0cWhaSUFoX2lkUkNTQ2E2NDF1eWNuYzh6UGZOV3o4bngwIiw gImYxLVAwQTJkS1dhdnYxdUZuTVgyQTctRVh4dmhveHY1YUhodUVJTi1XNjQiLCAiazV oeTJyMDE4dnJzSmpvLVZqZDZnNnl0N0Fhb25Lb25uaXVKOXplbDNqbyIsICJxcDdaX0t 5MVlpcDBzWWdETzN6VnVnMk1GdVBOakh4a3NCRG5KWjRhSS1jIl19LCAiX3NkX2FsZyI 6ICJzaGEtMjU2IiwgImNuZiI6IHsiandrIjogeyJrdHkiOiAiRUMiLCAiY3J2IjogIlA tMjU2IiwgIngiOiAiVENBRVIxOVp2dTNPSEY0ajRXNHZmU1ZvSElQMUlMaWxEbHM3dkN lR2VtYyIsICJ5IjogIlp4amlXV2JaTVFHSFZXS1ZRNGhiU0lpcnNWZnVlY0NFNnQ0alQ 5RjJIWlEifX19.jeF9GjGbjCr0NND0SbkV4HeSpsysixALFScJl4bYkIykXhF6cRtqni 64_d7X6Ef8Rx80rfsgXe0H7TdiSoIJOw~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiw gIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d~WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIi wgIjE4IiwgdHJ1ZV0~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub 25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW1wb GUub3JnIiwgImlhdCI6IDE3MDk1NzI1NzgsICJzZF9oYXNoIjogIkpCc2FIZzZjbjdLR W5vSjJjVGZvenFpZG1VWE9EMWlpVHpfRGdUWklNNGMifQ.404FK0WQAawQHq446EtkFJ cKJydFs2S4L9f8RR5Fuf8_O7N0RG2FvgLB71gJhHdey_F6Kgqd55xSDpIyzZw4lQ¶
The following is the payload of a corresponding Key Binding JWT:¶
{
"nonce": "1234567890",
"aud": "https://verifier.example.org",
"iat": 1709572578,
"sd_hash": "JBsaHg6cn7KEnoJ2cTfozqidmUXOD1iiTz_DgTZIM4c"
}
¶
After the validation, the Verifier will have the following data for further processing:¶
{
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"vct": "https://bmi.bund.example/credential/pid/1.0",
"age_equal_or_over": {
"18": true
},
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
},
"nationalities": [
"DE"
]
}
¶
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 [VC_DATA_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:¶
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/vaccination/v1"
],
"type": [
"VerifiableCredential",
"VaccinationCertificate"
],
"issuer": "https://example.com/issuer",
"issuanceDate": "2023-02-09T11:01:59Z",
"expirationDate": "2028-02-08T11:01:59Z",
"name": "COVID-19 Vaccination Certificate",
"description": "COVID-19 Vaccination Certificate",
"credentialSubject": {
"vaccine": {
"type": "Vaccine",
"atcCode": "J07BX03",
"medicinalProductName": "COVID-19 Vaccine Moderna",
"marketingAuthorizationHolder": "Moderna Biotech"
},
"nextVaccinationDate": "2021-08-16T13:40:12Z",
"countryOfVaccination": "GE",
"dateOfVaccination": "2021-06-23T13:40:12Z",
"order": "3/3",
"recipient": {
"type": "VaccineRecipient",
"gender": "Female",
"birthDate": "1961-08-17",
"givenName": "Marion",
"familyName": "Mustermann"
},
"type": "VaccinationEvent",
"administeringCentre": "Praxis Sommergarten",
"batchNumber": "1626382736",
"healthProfessional": "883110000015376"
}
}
¶
The following is the issued SD-JWT:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4 dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0 cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJs ZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjog Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIz LTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDEx OjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl IiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl IiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhi Wlk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3 NGdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5 eDFYc3RJaVM2QjFZYmwySlo0IiwgIlRDbXpybDdLMmdldl9kdTdwY01JeXpSTEhwLVll Zy1GbF9jeHRyVXZQeGciLCAiVjdrSkJMSzc4VG1WRE9tcmZKN1p1VVBIdUtfMmNjN3la UmE0cVYxdHh3TSIsICJiMGVVc3ZHUC1PRERkRm9ZNE5semxYYzN0RHNsV0p0Q0pGNzVO dzhPal9nIiwgInpKS19lU01YandNOGRYbU1aTG5JOEZHTTA4ekozX3ViR2VFTUotNVRC eTAiXSwgInZhY2NpbmUiOiB7Il9zZCI6IFsiMWNGNWhMd2toTU5JYXFmV0pyWEk3Tk1X ZWRMLTlmNlkyUEE1MnlQalNaSSIsICJIaXk2V1d1ZUxENWJuMTYyOTh0UHY3R1hobWxk TURPVG5CaS1DWmJwaE5vIiwgIkxiMDI3cTY5MWpYWGwtakM3M3ZpOGViT2o5c214M0Mt X29nN2dBNFRCUUUiXSwgInR5cGUiOiAiVmFjY2luZSJ9LCAicmVjaXBpZW50IjogeyJf c2QiOiBbIjFsU1FCTlkyNHEwVGg2T0d6dGhxLTctNGw2Y0FheHJZWE9HWnBlV19sbkEi LCAiM256THE4MU0yb04wNndkdjFzaEh2T0VKVnhaNUtMbWREa0hFREpBQldFSSIsICJQ bjFzV2kwNkc0TEpybm4tX1JUMFJiTV9IVGR4blBKUXVYMmZ6V3ZfSk9VIiwgImxGOXV6 ZHN3N0hwbEdMYzcxNFRyNFdPN01HSnphN3R0N1FGbGVDWDRJdHciXSwgInR5cGUiOiAi VmFjY2luZVJlY2lwaWVudCJ9LCAidHlwZSI6ICJWYWNjaW5hdGlvbkV2ZW50In0sICJf c2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJj cnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxp bERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVj Q0U2dDRqVDlGMkhaUSJ9fX0.cxCH425HJYyAKyExUyF1UJZoFTICsUKAaVUKXf67zx2h csu40flxynZPZ3ImXEa71G2-U9qihHiYjDHQjE8mLw~WyIyR0xDNDJzS1F2ZUNmR2Zye U5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4 QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9k ZXJuYSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml 6YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0~WyJlSThaV205UW5LUHBOUGV OZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGUiLCAiMjAyMS0wOC0xNlQxMzo0MDo xMloiXQ~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0 aW9uIiwgIkdFIl0~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2Np bmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyJQYzMzSk0yTGNoY1VfbEhn Z3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiw gImdlbmRlciIsICJGZW1hbGUiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJp cnRoRGF0ZSIsICIxOTYxLTA4LTE3Il0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwg ImdpdmVuTmFtZSIsICJNYXJpb24iXQ~WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgI mZhbWlseU5hbWUiLCAiTXVzdGVybWFubiJd~WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13 IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd~WyJ 5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzODI3MzY iXQ~WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCIs ICI4ODMxMTAwMDAwMTUzNzYiXQ~¶
The following payload is used for the SD-JWT:¶
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/vaccination/v1"
],
"type": [
"VerifiableCredential",
"VaccinationCertificate"
],
"issuer": "https://example.com/issuer",
"issuanceDate": "2023-02-09T11:01:59Z",
"expirationDate": "2028-02-08T11:01:59Z",
"name": "COVID-19 Vaccination Certificate",
"description": "COVID-19 Vaccination Certificate",
"credentialSubject": {
"_sd": [
"1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww",
"JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg",
"R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4",
"TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg",
"V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM",
"b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g",
"zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0"
],
"vaccine": {
"_sd": [
"1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI",
"Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo",
"Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE"
],
"type": "Vaccine"
},
"recipient": {
"_sd": [
"1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA",
"3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI",
"Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU",
"lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw"
],
"type": "VaccineRecipient"
},
"type": "VaccinationEvent"
},
"_sd_alg": "sha-256",
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
}
}
¶
The following Disclosures are created by the Issuer:¶
Claim atcCode:¶
1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI¶
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd¶
["2GLC42sKQveCfGfryNRN9w", "atcCode", "J07BX03"]¶
Claim medicinalProductName:¶
Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo¶
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd¶
["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName", "COVID-19Vaccine Moderna"]¶
Claim marketingAuthorizationHolder:¶
Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE¶
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0¶
["6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHolder","Moderna Biotech"]¶
Claim nextVaccinationDate:¶
R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4¶
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGUiLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ¶
["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate","2021-08-16T13:40:12Z"]¶
Claim countryOfVaccination:¶
JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg¶
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0aW9uIiwgIkdFIl0¶
["Qg_O64zqAxe412a108iroA", "countryOfVaccination", "GE"]¶
Claim dateOfVaccination:¶
zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0¶
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0¶
["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination","2021-06-23T13:40:12Z"]¶
Claim order:¶
b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g¶
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd¶
["Pc33JM2LchcU_lHggv_ufQ", "order", "3/3"]¶
Claim gender:¶
3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI¶
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUiXQ¶
["G02NSrQfjFXQ7Io09syajA", "gender", "Female"]¶
Claim birthDate:¶
Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU¶
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYxLTA4LTE3Il0¶
["lklxF5jMYlGTPUovMNIvCA", "birthDate", "1961-08-17"]¶
Claim givenName:¶
lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw¶
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJpb24iXQ¶
["nPuoQnkRFq3BIeAm7AnXFA", "givenName", "Marion"]¶
Claim familyName:¶
1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA¶
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVzdGVybWFubiJd¶
["5bPs1IquZNa0hkaFzzzZNw", "familyName", "Mustermann"]¶
Claim administeringCentre:¶
TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg¶
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd¶
["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre", "PraxisSommergarten"]¶
Claim batchNumber:¶
V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM¶
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzODI3MzYiXQ¶
["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber", "1626382736"]¶
Claim healthProfessional:¶
1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww¶
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCIsICI4ODMxMTAwMDAwMTUzNzYiXQ¶
["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional","883110000015376"]¶
The following is how a presentation of the SD-JWT with Key Binding JWT that discloses only type, medicinalProductName, atcCode of the vaccine, type of the recipient, type, order and dateOfVaccination could look like:¶
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4 dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0 cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJs ZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjog Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIz LTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDEx OjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl IiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl IiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhi Wlk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3 NGdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5 eDFYc3RJaVM2QjFZYmwySlo0IiwgIlRDbXpybDdLMmdldl9kdTdwY01JeXpSTEhwLVll Zy1GbF9jeHRyVXZQeGciLCAiVjdrSkJMSzc4VG1WRE9tcmZKN1p1VVBIdUtfMmNjN3la UmE0cVYxdHh3TSIsICJiMGVVc3ZHUC1PRERkRm9ZNE5semxYYzN0RHNsV0p0Q0pGNzVO dzhPal9nIiwgInpKS19lU01YandNOGRYbU1aTG5JOEZHTTA4ekozX3ViR2VFTUotNVRC eTAiXSwgInZhY2NpbmUiOiB7Il9zZCI6IFsiMWNGNWhMd2toTU5JYXFmV0pyWEk3Tk1X ZWRMLTlmNlkyUEE1MnlQalNaSSIsICJIaXk2V1d1ZUxENWJuMTYyOTh0UHY3R1hobWxk TURPVG5CaS1DWmJwaE5vIiwgIkxiMDI3cTY5MWpYWGwtakM3M3ZpOGViT2o5c214M0Mt X29nN2dBNFRCUUUiXSwgInR5cGUiOiAiVmFjY2luZSJ9LCAicmVjaXBpZW50IjogeyJf c2QiOiBbIjFsU1FCTlkyNHEwVGg2T0d6dGhxLTctNGw2Y0FheHJZWE9HWnBlV19sbkEi LCAiM256THE4MU0yb04wNndkdjFzaEh2T0VKVnhaNUtMbWREa0hFREpBQldFSSIsICJQ bjFzV2kwNkc0TEpybm4tX1JUMFJiTV9IVGR4blBKUXVYMmZ6V3ZfSk9VIiwgImxGOXV6 ZHN3N0hwbEdMYzcxNFRyNFdPN01HSnphN3R0N1FGbGVDWDRJdHciXSwgInR5cGUiOiAi VmFjY2luZVJlY2lwaWVudCJ9LCAidHlwZSI6ICJWYWNjaW5hdGlvbkV2ZW50In0sICJf c2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJj cnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxp bERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVj Q0U2dDRqVDlGMkhaUSJ9fX0.cxCH425HJYyAKyExUyF1UJZoFTICsUKAaVUKXf67zx2h csu40flxynZPZ3ImXEa71G2-U9qihHiYjDHQjE8mLw~WyJQYzMzSk0yTGNoY1VfbEhnZ 3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwg ImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyIyR0xD NDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9 nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE 5IFZhY2NpbmUgTW9kZXJuYSJd~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dC J9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyL mV4YW1wbGUub3JnIiwgImlhdCI6IDE3MDk1NzI1NzgsICJzZF9oYXNoIjogIklzd3dPe kh6OVF5RFdxQXVzeUZHcDZ2RGt3YlN3X25tQk9FSmlIRkFaSlUifQ.7YtKL_1dLXm2VO bTJc98m6dgdUvXwTcfyYZ007KOaidfgVuKpQ87ROPjGtpH4mNAQKzfdoDYm5pAAMOUJ- xtHg¶
After the validation, the Verifier will have the following data for further processing:¶
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/vaccination/v1"
],
"type": [
"VerifiableCredential",
"VaccinationCertificate"
],
"issuer": "https://example.com/issuer",
"issuanceDate": "2023-02-09T11:01:59Z",
"expirationDate": "2028-02-08T11:01:59Z",
"name": "COVID-19 Vaccination Certificate",
"description": "COVID-19 Vaccination Certificate",
"credentialSubject": {
"vaccine": {
"type": "Vaccine",
"atcCode": "J07BX03",
"medicinalProductName": "COVID-19 Vaccine Moderna"
},
"recipient": {
"type": "VaccineRecipient"
},
"type": "VaccinationEvent",
"order": "3/3",
"dateOfVaccination": "2021-06-23T13:40:12Z"
},
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
}
}
¶
The following Elliptic Curve public key, represented in JWK format, can be used to validate the Issuer signatures in the above examples:¶
{
"kty": "EC",
"crv": "P-256",
"x": "b28d4MwZMjw8-00CG4xfnn9SLMVMM19SlqZpVb_uNtQ",
"y": "Xv5zWwuoaTgdS6hV43yI6gBwTnjukmFQQnJ_kCxzqk8"
}
¶
The public key used to validate a Key Binding JWT can be found in the examples as the content of the cnf claim.¶
As described in Section 5.2, 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:¶
...
"family_name": "Möbius",
"address": {
"street_address": "Schulstr. 12",
"locality": "Schulpforta"
}
...
¶
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¶
...
"family_name": "M\u00f6bius",
"address": {
"street_address": "Schulstr. 12",
"locality": "Schulpforta"
}
...
¶
or as¶
...
"family_name": "Möbius",
"address": {"locality":"Schulpforta", "street_address":"Schulstr. 12"}
...
¶
The two representations of the value 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 [RFC8785]. 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:¶
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 Section 8.3 for details.¶
[[ To be removed from the final specification ]]¶
-08¶
-07¶
_sd_hash to sd_hash¶
-06¶
_sd or ... must not be used in a disclosure.¶
-05¶
_sd_alg can only be at the top level of the SD-JWT payload¶
-04¶
-03¶
none)¶
-02¶
_sd claim per level.¶
_sd_alg)¶
-01¶
_sd_hash_alg renamed to sd_digest_derivation_alg¶
sd_disclosure in II-Disclosures renamed to sd_ii_disclosures¶
sd_disclosure in HS-Disclosures renamed to sd_hs_disclosures¶
sd_hs_disclosure and SD-JWT¶
cnf structure in examples¶
-00¶
[[ pre Working Group Adoption: ]]¶
-02¶
hash_alg renamed to _sd_hash_alg¶
-01¶
hash_alg claim¶
_sd to sd_digests and sd_release¶
-00¶