<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-oauth-selective-disclosure-jwt-22" number="9901" updates="" obsoletes="" consensus="true" symRefs="true" sortRefs="true" submissionType="IETF" category="std" xml:lang="en"indexInclude="true">tocInclude="true"> <front> <title abbrev="SD-JWT">Selective Disclosure for JSON Web Tokens (SD-JWTs)</title> <!-- [rfced] Document title: We expanded "JWT" in the document title. Please let us know if you have any concerns. Original: Selective Disclosure for JWTs(SD-JWT)</title><seriesInfo value="draft-ietf-oauth-selective-disclosure-jwt-22" stream="IETF" status="standard" name="Internet-Draft"/>(SD-JWT) Currently: Selective Disclosure for JSON Web Tokens (SD-JWTs) --> <seriesInfo name="RFC" value="9901"/> <author initials="D." surname="Fett" fullname="DanielFett"><organization>Authlete</organization><address><postal><street/> </postal><email>mail@danielfett.de</email>Fett"> <organization>Authlete</organization> <address> <email>mail@danielfett.de</email> <uri>https://danielfett.de/</uri></address></author><author</address> </author> <author initials="K." surname="Yasuda" fullname="KristinaYasuda"><organization>Keio University</organization><address><postal><street/> </postal><email>kristina@sfc.keio.ac.jp</email> </address></author><authorYasuda"> <organization>Keio University</organization> <address> <email>kristina@sfc.keio.ac.jp</email> </address> </author> <author initials="B." surname="Campbell" fullname="BrianCampbell"><organization>Ping Identity</organization><address><postal><street/> </postal><email>bcampbell@pingidentity.com</email> </address></author><date/> <area>Security</area> <workgroup>Web Authorization Protocol</workgroup>Campbell"> <organization>Ping Identity</organization> <address> <email>bcampbell@pingidentity.com</email> </address> </author> <date month="November" year="2025"/> <area>SEC</area> <workgroup>oauth</workgroup> <keyword>security</keyword> <keyword>oauth2</keyword> <abstract> <t>This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims.</t> </abstract><note title="Discussion Venues" removeInRFC="true"> <t>Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/oauth/"/>.</t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/oauth-wg/oauth-selective-disclosure-jwt"/>.</t> </note></front> <middle> <section anchor="Introduction"><name>Introduction</name><t>JSON data for<t>The exchange of JSON data between systems is often secured against modification using JSON Web Signatures(JWS)(JWSs) <xref target="RFC7515"/>. A popular application of JWS is the JSON Web Token (JWT) <xref target="RFC7519"/>, a format that is often used to represent a user's identity. An ID Token as defined in OpenID Connect <xref target="OpenID.Core"/>, for example, is a JWT containing the user's claims created by the server for consumption by a relying party. In cases where the JWT is sent immediately from the server to the relying party, as in OpenID Connect, the server can select at the time of issuance which user claims to include in the JWT, minimizing the information shared with the relying party who validates the JWT.</t> <t>Another model is emerging that fully decouples the issuance of a JWT from its presentation. In this model, a JWT containing many claims is issued to an intermediate party, who holds the JWT (the Holder). The Holder can then present the JWT to different verifying parties(Verifiers),(Verifiers) that each may only require a subset of the claims in the JWT. For example, the JWT may contain claims representing both an address and a birthdate. The Holder may elect to disclose only the address to one Verifier, and only the birthdate to a different Verifier.</t> <t>Privacy principles of minimal disclosure in conjunction with this model demand a mechanism enabling selective disclosure of data elements while ensuring that Verifiers can still check the authenticity of the data provided. Thisspecification, Selective Disclosure for JSON Web Tokens (SD-JWT),specification defines such a mechanism for JSON payloads ofJSON Web Signatures (JWS),JWSs, with JWTs as the primary use case.</t> <t>SD-JWT is based on an approach called "salted hashes": For any data element that should be selectively disclosable, the Issuer of the SD-JWT does not include the cleartext of the data in the JSON payload of the JWS structure; instead, a digest of the data takes its place. For presentation to a Verifier, the Holder sends the signed payload along with the cleartext of those claims it wants to disclose. The Verifier can then compute the digest of the cleartext data and confirm it is included in the signed payload. To ensure that Verifiers cannot guess cleartext values of non-disclosed data elements, an additional salt value is used when creating the digest and sent along with the cleartext when disclosing it.</t> <t>To prevent attacks in which an SD-JWT is presented to a Verifier without the Holder's consent, this specification additionally defines a mechanism for binding the SD-JWT to a key under the control of the Holder (Key Binding). When Key Binding is enforced, a Holder has to prove possession of a private key belonging to a public key contained in the SD-JWT itself. It usually does so by signing over a data structure containing transaction-specific data, herein defined as the Key Binding JWT. An SD-JWT with a Key Binding JWT is calledSD-JWT+KB"SD-JWT+KB" in this specification.</t> <section anchor="feature-summary"><name>Feature Summary</name> <t>This specification defines two primary data formats:</t><ol><ol spacing="normal"> <li><t>SD-JWT is a composite structure, consisting of a JWS plus optional disclosures, enabling selective disclosure of portions of the JWS payload. It comprises the following:</t> <ulspacing="compact">spacing="normal"> <li>A format for enabling selective disclosure in nested JSON data structures, supporting selectively disclosable object properties (name/value pairs) and arrayelements</li>elements.</li> <li>A format for encoding the selectively disclosable dataitems</li>items.</li> <li>A format extending the JWS Compact Serialization, allowing for the combined transport of the Issuer-signed JSON data structure and the disclosable dataitems</li>items.</li> <li>An alternate format extending the JWS JSON Serialization, also allowing for transport of the Issuer-signed JSON data structure and disclosuredata</li>data.</li> </ul></li> <li><t>SD-JWT+KB is a composite structure of an SD-JWT and a cryptographic key binding that can be presented to and verified by the Verifier. It comprises the following:</t> <ulspacing="compact">spacing="normal"> <li>A mechanism for associating an SD-JWT with a keypair</li>pair.</li> <li>A format for a Key Binding JWT (KB-JWT) that allows proof of possession of the private key of the associated keypair</li>pair.</li> <li>A format extending the SD-JWT format for the combined transport of the SD-JWT and theKB-JWT</li>KB-JWT.</li> </ul></li> </ol> </section> <section anchor="conventions-and-terminology"><name>Conventions and Terminology</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t><strong>Base64url</strong> denotes the URL-safe base64 encoding without padding defined inSection 2 of<xreftarget="RFC7515"/>.</t>target="RFC7515" section="2"/>.</t> <t>Throughoutthe documentthis document, the term "claims" refers generally tobothobject properties (name/value pairs) as well as array elements.</t> <dlspacing="compact">spacing="normal" newline="true"> <dt>Selective Disclosure:</dt> <dd>Process of a Holder disclosing to a Verifier a subset of claims contained in a JWT issued by an Issuer.</dd> <dt>Selectively Disclosable JWT (SD-JWT):</dt> <dd>A composite structure, consisting of an Issuer-signed JWT(JWS,(JWS; see <xref target="RFC7515"/>) and zero or more Disclosures, which supports selective disclosure as defined in this document. It can contain both regular claims and digests ofselectively-disclosableselectively disclosable claims.</dd> <dt>Disclosure:</dt> <dd>A base64url-encoded string of a JSON array that contains a salt, a claim name (present when the claim is a name/value pair and absent when the claim is an array element), and a claim value. The Disclosure is used to calculate a digest for the respective claim. The term Disclosure refers to the whole base64url-encoded string.</dd> <dt>Key Binding:</dt> <dd>Ability of the Holder to prove possession of an SD-JWT by proving control over a private key during the presentation. When utilizing Key Binding, an SD-JWT contains the public key corresponding to the private key controlled by the Holder (or a reference to this public key).</dd> <dt>Key Binding JWT (KB-JWT):</dt> <dd>A Key Binding JWT is said to "be tied to" a particular SD-JWT when its payload is signed using the key included in the SD-JWT payload, and the KB-JWT contains a hash of the SD-JWT in its <tt>sd_hash</tt> claim. Its format is defined in <xref target="kb-jwt"/>.</dd> <dt>Selectively Disclosable JWT with Key Binding (SD-JWT+KB):</dt> <dd>A composite structure, comprising an SD-JWT and a Key Binding JWT tied to that SD-JWT.</dd> <dt>Processed SD-JWTPayload</dt>Payload:</dt> <dd>The JSON object resulting from verification and processing of the Issuer-signed SD-JWT, with digest placeholders replaced by the corresponding values from the Disclosures.</dd> <dt>Issuer:</dt> <dd>An entity that creates SD-JWTs.</dd> <dt>Holder:</dt> <dd>An entity that received SD-JWTs from the Issuer and has control over them. In the context of this document, the term may refer to the actual user, the supporting hardware and software in their possession, or both.</dd> <dt>Verifier:</dt> <dd>An entity that requests, checks, and extracts the claims from an SD-JWT with its respective Disclosures.</dd> </dl> </section> </section> <section anchor="flow-diagram"><name>Flow Diagram</name> <figure><name>SD-JWT Issuance and PresentationFlow </name> <sourcecode type="ascii-art"><![CDATA[Flow</name> <artwork><![CDATA[ +------------+ | | | Issuer | | | +------------+ | Issues SD-JWT including all Disclosures | v +------------+ | | | Holder | | | +------------+ | Presents SD-JWT or SD-JWT+KB including selected Disclosures | v +-------------+ | |+ | Verifiers ||+ | ||| +-------------+|| +-------------+| +-------------+ ]]></sourcecode></artwork> </figure> <!-- [rfced] Regarding <artwork> and <sourcecode> settings in this document: a) Section 4.2.6: We see that the first entry with '"family_name": "Möbius"' is labeled as '<sourcecode type="json">' but the next two entries in this section are labeled as '<sourcecode>' (no type included). May we change '<sourcecode>' to '<sourcecode type="json">' for these other two entries? b) We see several entries with '<sourcecode type="txt">'. Please note that "txt" is not listed as an approved type on <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. Would "test-vectors" be more appropriate? RFC 9879 provides an example of using the "test-vectors" type; please see <https://www.rfc-editor.org/info/rfc9879> for access to its XML file. If not, do you suggest that "txt" be added as an additional sourcecode type? c) Please review the items labeled as <artwork> in Appendices A.5 and B, and let us know if we may label them as <sourcecode> with type="json" instead. For example, should the JSON object shown under the text "a JSON object such as this" be set to <sourcecode> with type="json"? --> </section> <section anchor="concepts"><name>Concepts</name> <t>This section describes SD-JWTs with their respective Disclosures and Key Binding at a conceptual level, abstracting from the data formats described in <xref target="data_formats"/>.</t> <section anchor="sd-jwt-and-disclosures"><name>SD-JWT and Disclosures</name> <t>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, andmodifyingmodifications to them can be detected. Selectively disclosable claims can be individual object properties (name/value pairs) or array elements.</t> <t>Each digest value ensures the integrity of, and maps to, the respective Disclosure. Digest values are calculated using a hash function over the Disclosures, each of which contains a cryptographically secure random salt, the claim name (only when the claim is an object property), and the claim value. The Disclosures are sent to the Holder with the SD-JWT in the format defined in <xref target="data_formats"/>. 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.</t> <t>An SD-JWTMAY<bcp14>MAY</bcp14> also contain cleartext claims that are always disclosed to the Verifier.</t> </section> <section anchor="disclosing-to-a-verifier"><name>Disclosing to a Verifier</name> <t>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.</t> </section> <section anchor="optional-key-binding"><name>Optional Key Binding</name> <t>Key Binding is an optional feature. When Key Binding is required by the use case, the SD-JWTMUST<bcp14>MUST</bcp14> contain information about the key material controlled by the Holder.</t><blockquote><t>Note:<aside><t>Note: How the public key is included in SD-JWT is described in <xref target="key_binding"/>.</t></blockquote><t>When</aside> <t>When a Verifier requires Key Binding, the Holder presents an SD-JWT+KB, consisting of an SD-JWT as well as a Key Binding JWT tied to that SD-JWT. The Key Binding JWT encodes a signature by the Holder's private key over</t> <ulspacing="compact">spacing="normal"> <li>a hash of the SD-JWT,</li> <li>a nonce to ensure the freshness of the signature, and</li> <li>an audience value to indicate the intended Verifier for the document.</li> </ul> <t>Details of the format of Key Binding JWTs are described in <xref target="kb-jwt"/>.</t> </section> <section anchor="verification"><name>Verification</name> <t>At a high level, the Verifier</t> <ulspacing="compact">spacing="normal"> <li>receives either an SD-JWT or an SD-JWT+KB from the Holder,</li> <li>verifies the signature on the SD-JWT (or the SD-JWT inside the SD-JWT+KB) using the Issuer's public key,</li> <li>verifies the signature on the KB-JWT using the public key included (or referenced) in the SD-JWT, if the Verifier's policy requires Key Binding, and</li> <li>calculates the digests over the Holder-Selected Disclosures and verifies that each digest is contained in the SD-JWT.</li> </ul> <t>The detailed algorithm is described in <xref target="verifier_verification"/>.</t> </section> </section> <section anchor="data_formats"><name>SD-JWT and SD-JWT+KB Data Formats</name> <t>An SD-JWT is composed of</t> <ulspacing="compact">spacing="normal"> <li>an Issuer-signed JWT, and</li> <li>zero or more Disclosures.</li> </ul> <t>An SD-JWT+KB is composed of</t> <ulspacing="compact">spacing="normal"> <li>an SD-JWT (i.e., an Issuer-signed JWT and zero or more Disclosures), and</li> <li>a Key Binding JWT.</li> </ul> <t>The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in Sections <xreftarget="iss-signed-jwt"/>,target="iss-signed-jwt" format="counter"/>, <xreftarget="creating_disclosures"/>,target="creating_disclosures" format="counter"/>, and <xreftarget="kb-jwt"/>target="kb-jwt" format="counter"/>, respectively.</t> <t>The compact serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows:</t><artwork><![CDATA[<Issuer-signed<artwork><![CDATA[ <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~ ]]> </artwork> <t>The order of the concatenated partsMUST<bcp14>MUST</bcp14> be the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, and lastly the optional Key Binding JWT. In the case that there is no Key Binding JWT, the last elementMUST<bcp14>MUST</bcp14> be an empty string and the last separating tilde characterMUST NOT<bcp14>MUST NOT</bcp14> be omitted.</t> <t>The serialized format for an SD-JWT+KB extends the SD-JWT format by concatenating a Key Binding JWT.</t><artwork><![CDATA[<Issuer-signed<artwork><![CDATA[ <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~<KB-JWT> ]]> </artwork> <!-- [rfced] Sections 4 and 4.2.4.2: The following lines are too long for the text output. We get the following warnings from xml2rfc: (252): Warning: Too long line found (L423), 5 characters longer than 72 characters: <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~<KB-JWT> (512): Warning: Too long line found (L786), 2 characters longer than 72 characters: ["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}, "US"] Would the suggested line breaks be acceptable? If not, please let us know where these lines should be broken. Perhaps: <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~... ~<Disclosure N>~<KB-JWT> ... ["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}, "US"] --> <t>The two formats can be distinguished by the final <tt>~</tt> character that is present on an SD-JWT. A Verifier that expects an SD-JWTMUST<bcp14>MUST</bcp14> verify that the final tilde-separated component is empty. A Verifier that expects an SD-JWT+KBMUST<bcp14>MUST</bcp14> verify that its final tilde-separated component is a valid KB-JWT.</t> <t>The Disclosures are linked to the Issuer-signed JWT through the digest values included therein.</t> <t>When issuing to a Holder, the Issuer includes all the relevant Disclosures in the SD-JWT.</t> <t>When presenting to a Verifier, the Holder sends only the selected set of the Disclosures in the SD-JWT.</t> <t>The HolderMAY<bcp14>MAY</bcp14> 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 HolderMUST NOT<bcp14>MUST NOT</bcp14> send Disclosures or reveal the salt values in any other way. A HolderMUST NOT<bcp14>MUST NOT</bcp14> send a Disclosure that was not included in the issued SD-JWT or send a Disclosure more than once.</t> <t>To further illustrate the SD-JWT format, the following examples show a few different SD-JWT permutations, both with and without various constituent parts.</t> <t>An SD-JWT without Disclosures:</t><artwork><![CDATA[<Issuer-signed<artwork><![CDATA[ <Issuer-signed JWT>~ ]]> </artwork> <t>An SD-JWT with Disclosures:</t><artwork><![CDATA[<Issuer-signed<artwork><![CDATA[ <Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~ ]]> </artwork> <t>An SD-JWT+KB without Disclosures:</t><artwork><![CDATA[<Issuer-signed<artwork><![CDATA[ <Issuer-signed JWT>~<KB-JWT> ]]> </artwork> <t>An SD-JWT+KB with Disclosures:</t><artwork><![CDATA[<Issuer-signed<artwork><![CDATA[ <Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~<KB-JWT> ]]> </artwork> <t>As an alternative illustration of the SD-JWT format, ABNF <xref target="RFC5234"/> for the SD-JWT, SD-JWT+KB, and various constituent parts is provided here (for those who celebrate):</t> <sourcecodetype="abnf"><![CDATA[ALPHAtype="abnf"><![CDATA[ ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 BASE64URL = 1*(ALPHA / DIGIT / "-" / "_") JWT = BASE64URL "." BASE64URL "." BASE64URL DISCLOSURE = BASE64URL SD-JWT = JWT "~" *(DISCLOSURE "~") KB-JWT = JWT SD-JWT-KB = SD-JWT KB-JWT ]]> </sourcecode> <sectionanchor="iss-signed-jwt"><name>Issuer-signedanchor="iss-signed-jwt"><name>Issuer-Signed JWT</name> <!-- [rfced] Regarding the use of font styling (i.e., <tt> and <strong>), please review the questions below. Note: For <tt>-related items, view the list here: https://www.rfc-editor.org/authors/rfc9901tt.txt a) May we update instances of <tt>none</tt> to "none" for increased clarity in the text file, and for consistency with RFCs 8725 and 9781? It MUST NOT use the none algorithm. - alg: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST NOT be none. The none algorithm MUST NOT be accepted. (2x) b) In general, please review the use of <tt> and note that there are no visual marks in the text file. Is the goal of <tt> to indicate fixed-width font or to call attention to the various items? Some similar text seems to be marked as both <sourcecode> and <tt>. Please review and consider updating the XML file for consistency as needed. For example, we see the following, which seem similar. Was <tt> used in running text? <sourcecode type=“json”><![CDATA[ [“_26bc4LT-ac6q2KI6cBW5es”, “family_name”, “Möbius”] ]]> </sourcecode> <tt>["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]</tt> c) May we reformat the bulleted items that use <strong> as shown below? Note that we reformatted the entry for "Claim given_name:" in Section 5.1 so you can see the update in context. We believe this will make the groupings more clear and allow us to avoid the use of bold, which displays as asterisks in the text (which looks awkward because the *claim name* (with asterisks) is followed by a list with asterisks as bullets). Original: *Claim given_name*: * SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4 * Disclosure: WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o biJd * Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"] *Claim family_name*: Perhaps: * Claim given_name: - SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4 - Disclosure: WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJ d - Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"] *Claim family_name*: --> <t>An SD-JWT has a JWT component thatMUST<bcp14>MUST</bcp14> be signed using the Issuer's private key. ItMUST NOT<bcp14>MUST NOT</bcp14> use the <tt>none</tt> algorithm.</t> <t>The payload of an SD-JWT is a JSON object according to the following rules:</t> <olspacing="compact">spacing="normal"> <li>The payloadMAY<bcp14>MAY</bcp14> contain the <tt>_sd_alg</tt> key described in <xref target="hash_function_claim"/>.</li> <li>The payloadMAY<bcp14>MAY</bcp14> contain one or more digests of Disclosures to enable selective disclosure of the respective claims, created and formatted as described in <xref target="creating_disclosures"/>.</li> <li>The payloadMAY<bcp14>MAY</bcp14> contain one or more decoy digests to obscure the actual number of claims in the SD-JWT, created and formatted as described in <xref target="decoy_digests"/>.</li> <li>The payloadMAY<bcp14>MAY</bcp14> contain one or more permanently disclosed claims.</li> <li>The payloadMAY<bcp14>MAY</bcp14> contain the Holder's public key(s) or reference(s) thereto, as explained in <xref target="key_binding"/>.</li> <li>The payloadMAY<bcp14>MAY</bcp14> contain further claims such as <tt>iss</tt>, <tt>iat</tt>, etc. as defined or required by the application using SD-JWTs.</li> <li>The payloadMUST NOT<bcp14>MUST NOT</bcp14> contain the claims <tt>_sd</tt> or <tt>...</tt> except for the purpose of conveying digests as described in Sections <xreftarget="embedding_object_properties"/>target="embedding_object_properties" format="counter"/> and <xreftarget="embedding_array_elements"/> respectively below.</li>target="embedding_array_elements" format="counter"/>, respectively.</li> </ol> <t>The same digest valueMUST NOT<bcp14>MUST NOT</bcp14> appear more than once in the SD-JWT.</t> <t>Application and profiles of SD-JWTSHOULD<bcp14>SHOULD</bcp14> be explicitly typed. See <xref target="explicit_typing"/> for more details.</t> <t>It is the Issuer who decides which claims are selectively disclosable by the Holder and which are not. ClaimsMAY<bcp14>MAY</bcp14> 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 <xref target="sd-validity-claims"/> for considerations on making validity-controlling claims such as <tt>exp</tt> selectively disclosable.</t> <t>Claims that are not selectively disclosable are included in the SD-JWT in plaintext just as they would be in any other JSON structure.</t> <section anchor="hash_function_claim"><name>Hash Function Claim</name> <t>The claim <tt>_sd_alg</tt> indicates the hash algorithm used by the Issuer to generate the digests as described in <xref target="creating_disclosures"/>. When used, this claimMUST<bcp14>MUST</bcp14> appear at the top level of the SD-JWT payload. ItMUST NOT<bcp14>MUST NOT</bcp14> be used in any object nested within the payload. If the <tt>_sd_alg</tt> claim is not present at the top level, a default value of <tt>sha-256</tt>MUST<bcp14>MUST</bcp14> be used.</t> <t>This claim value is a case-sensitive string with the hash algorithm identifier. The hash algorithm identifierMUST<bcp14>MUST</bcp14> be a hash algorithm value from the "Hash Name String" column in theIANA"Named Information HashAlgorithm" registryAlgorithm Registry" <xreftarget="IANA.Hash.Algorithms"/>target="Hash.Algs"/> or a value defined in another specification and/or profile of this specification.</t> <t>To promote interoperability, implementationsMUST<bcp14>MUST</bcp14> support the <tt>sha-256</tt> hash algorithm.</t> <t>See <xref target="security_considerations"/> for requirements regarding entropy of the salt, minimum length of the salt, and choice of a hash algorithm.</t> </section> <section anchor="key_binding"><name>Key Binding</name> <t>If the Issuer wants to enable Key Binding, it includes a public key associated with the Holder, or a reference thereto, using the <tt>cnf</tt> claim as defined in <xref target="RFC7800"/>. The <tt>jwk</tt> confirmation method, as defined inSection 3.2 of<xreftarget="RFC7800"/>,target="RFC7800" section="3.2"/>, is suggested for doing so, however, other confirmation methods can be used.</t><blockquote><t>Note<aside><t>Note that, as was stated in <xref target="RFC7800"/>, if an application needs to represent multiple proof-of-possession keys in the same SD-JWT, one way to achieve this is to use other claim names, in addition to <tt>cnf</tt>, to hold the additional proof-of-possession keyinformation.</t> </blockquote><t>It is outinformation.</t></aside> <!-- [rfced] Sections 4.1.2 and subsequent: We have changed instances of <blockquote> to <aside> throughout. Please review and let us know if any updates are needed. Per <https://authors.ietf.org/en/rfcxml-vocabulary#aside>, the <aside> element is defined as "a container for content that is semantically less important or tangential to the content that surrounds it". --> <t>It is outside the scope of this document to describe how the Holder key pair is established. For example, the HolderMAY<bcp14>MAY</bcp14> create a key pair and provide a public key to the Issuer, the IssuerMAY<bcp14>MAY</bcp14> create the key pair for the Holder, or Holder and IssuerMAY<bcp14>MAY</bcp14> use pre-established key material.</t><blockquote><t>Note:<aside><t>Note: The examples throughout this document use the <tt>cnf</tt> claim with the <tt>jwk</tt> member to include the raw public key by value in SD-JWT.</t></blockquote></section></aside></section> </section> <section anchor="creating_disclosures"><name>Disclosures</name> <t>Disclosures are created differently depending on whether a claim is an object property (name/value pair) or an array element.</t> <ulspacing="compact">spacing="normal"> <li>For a claim that is an object property, the Issuer creates a Disclosure as described in <xref target="disclosures_for_object_properties"/>.</li> <li>For a claim that is an array element, the Issuer creates a Disclosure as described in <xref target="disclosures_for_array_elements"/>.</li> </ul> <section anchor="disclosures_for_object_properties"><name>Disclosures for Object Properties</name> <t>For each claim that is an object property and that is to be made selectively disclosable, the IssuerMUST<bcp14>MUST</bcp14> create a Disclosure as follows:</t> <ulspacing="compact">spacing="normal"> <li><t>Create a JSON array of three elements inthisthe following order:</t> <olspacing="compact">spacing="normal"> <li>A salt value.MUST<bcp14>MUST</bcp14> be a string. See <xref target="salt-entropy"/> for security considerations. To achieve the recommended entropy of the salt, the Issuer can base64url-encode 128 bits of cryptographically secure random data, producing a string. The salt valueMUST<bcp14>MUST</bcp14> be unique for each claim that is to be selectively disclosed. The IssuerMUST NOT<bcp14>MUST NOT</bcp14> reveal the salt value to any party other than the Holder.</li> <li>The claim name, or key, as it would be used in a regular JWT payload. ItMUST<bcp14>MUST</bcp14> be a string andMUST NOT<bcp14>MUST NOT</bcp14> be <tt>_sd</tt>, <tt>...</tt>, or a claim name existing in the object as a permanently disclosed claim.</li> <li>The claim value, as it would be used in a regular JWT payload. The value can be of any type that is allowed in JSON, including numbers, strings, booleans, arrays, null, and objects.</li> </ol></li> <li>base64url-encode the UTF-8 byte sequence of the JSON array. This string is the Disclosure.</li> </ul><blockquote><t>Note:<aside><t>Note: The order was decided based on readability considerations:saltsSalts 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.</t></blockquote><t>The</aside> <t>The following example illustrates the steps described above.</t> <t>The array is created as follows:</t> <sourcecodetype="json"><![CDATA[["_26bc4LT-ac6q2KI6cBW5es",type="json"><![CDATA[ ["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"] ]]> </sourcecode> <t>Theresultingresultant Disclosureis: <tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0</tt></t>is:</t> <t><tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0</tt></t> <t>Note that variations in whitespace, encoding of Unicode characters, ordering of object properties, etc., are allowed in the JSON representation and no canonicalization needs to be performed beforebase64url-encodingbase64url encoding because the digest is calculated over the base64url-encoded value itself. For example, the following strings are all valid and encode the same claim value "Möbius":</t> <ulspacing="compact"> <li>Aspacing="normal"> <li><t>A different way to encode the unicodeumlaut:<br/> <tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNX</tt><br/> <tt>HUwMGY2Yml1cyJd</tt></li> <li>Noumlaut:</t> <t><tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNXHUwMGY2Yml1cyJd</tt></t></li> <li><t>No whitespace:<br/> <tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Y</tt><br/> <tt>ml1cyJd</tt></li> <li>Newlinespace:</t> <t><tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Yml1cyJd</tt></t></li> <li><t>Newline characters betweenelements:<br/> <tt>WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiT</tt><br/> <tt>cO2Yml1cyIKXQ</tt></li>elements:</t> <t><tt>WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiTcO2Yml1cyIKXQ</tt></t></li> </ul> <t>However, the digest is calculated over the respective base64url-encoded value itself, which effectively signs the variation chosen by the Issuer and makes it immutable in the context of the particular SD-JWT.</t> <t>See <xref target="disclosure_format_considerations"/> for some further considerations on the Disclosure format approach.</t> </section> <section anchor="disclosures_for_array_elements"><name>Disclosures for Array Elements</name> <t>For each claim that is an array element and that is to be made selectively disclosable, the IssuerMUST<bcp14>MUST</bcp14> create a Disclosure as follows:</t> <ulspacing="compact">spacing="normal"> <li><t>The arrayMUST<bcp14>MUST</bcp14> contain two elements in this order:</t> <olspacing="compact">spacing="normal"> <li>The salt value as described in <xref target="disclosures_for_object_properties"/>.</li> <li>The array element that is to be hidden. This value can be of any type that is allowed in JSON, including numbers, strings, booleans, arrays, and objects.</li> </ol></li> </ul> <t>The Disclosure string is created by base64url-encoding the UTF-8 byte sequence of theresultingresultant JSON array as described in <xref target="disclosures_for_object_properties"/>. The same considerations regarding variations in the result of the JSON encoding apply.</t> <t>For example, a Disclosure for the second element of the <tt>nationalities</tt> array in the following JWT Claims Set:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "nationalities": ["DE", "FR", "US"] } ]]> </sourcecode> <t>could be created by first creating the following array:</t> <sourcecodetype="json"><![CDATA[["lklxF5jMYlGTPUovMNIvCA",type="json"><![CDATA[ ["lklxF5jMYlGTPUovMNIvCA", "FR"] ]]> </sourcecode> <t>Theresultingresultant Disclosure wouldbe: <tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0</tt></t> <blockquote><t>Notebe:</t> <t><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0</tt></t> <aside><t>Note that the size of an array alone can potentially reveal unintended information. The use of decoys, as described in <xref target="decoy_digests"/>, to consistently pad the size of an array can help obscure the actual number of elements present in any particularinstance.</t> </blockquote></section>instance.</t></aside> </section> <section anchor="hashing_disclosures"><name>Hashing Disclosures</name> <t>For embedding references to the Disclosures in the SD-JWT, each Disclosure is hashed using the hash algorithm specified in the <tt>_sd_alg</tt> claim described in <xref target="hash_function_claim"/>, or SHA-256 if no algorithm is specified. Theresultingresultant digest is then included in the SD-JWT payload instead of the original claim value, as described next.</t><t>The<!-- [rfced] May we change "taken" to "chosen" or "preferred" for clarity? Section 4.2.3: In an SD-JWT+KB, kb_jwt MUST be present when using the JWS JSON Serialization, and the digest in the sd_hash claim MUST be taken over the SD-JWT as described in Section 4.3.1. Section 4.3.1: The sd_hash value MUST be taken over the US-ASCII bytes of the encoded SD-JWT, i.e., the Issuer-signed JWT, a tilde character, and zero or more Disclosures selected for presentation to the Verifier, each followed by a tilde character: Section 8.1: In an SD-JWT+KB, kb_jwt MUST be present when using the JWS JSON Serialization, and the digest in the sd_hash claim MUST be taken over the SD-JWT as described in Section 4.3.1. --> <t>The digest <bcp14>MUST</bcp14> be taken over the US-ASCII bytes of the base64url-encoded value that is the Disclosure. This follows the convention in JWS <xref target="RFC7515"/> and JWE <xref target="RFC7516"/>. The bytes of the digestMUST<bcp14>MUST</bcp14> then bebase64url-encoded.</t>base64url encoded.</t> <t>It is important to note that:</t> <ulspacing="compact">spacing="normal"> <li>The input to the hash functionMUST<bcp14>MUST</bcp14> be the base64url-encoded Disclosure, not the bytes encoded by the base64url string.</li> <li>The bytes of the output of the hash functionMUST<bcp14>MUST</bcp14> bebase64url-encoded,base64url encoded, and are not the bytes making up the (sometimes used) hex representation of the bytes of the digest.</li> </ul> <t>For example, the base64url-encoded SHA-256 digest of the Disclosure <tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0</tt> for the <tt>family_name</tt> claim from <xref target="disclosures_for_object_properties"/> above is <tt>X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0</tt>.</t> </section> <section anchor="embedding_disclosure_digests"><name>Embedding Disclosure Digests in SD-JWTs</name> <t>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.</t> <ulspacing="compact">spacing="normal"> <li>For a claim that is an object property, the Issuer embeds a Disclosure digest as described in <xref target="embedding_object_properties"/>.</li> <li>For a claim that is an array element, the Issuer creates a Disclosure digest as described in <xref target="embedding_array_elements"/>.</li> </ul> <section anchor="embedding_object_properties"><name>Object Properties</name> <!-- [rfced] We are having trouble parsing this sentence. Please consider whether the suggested text below is a correct interpretation. Original: An _sd key can be present at any level of the JSON object hierarchy, including the top- level, nested deeper as described in Section 6, or in recursive disclosures as described in Section 4.2.6. Perhaps A (the "or" is connecting two things): An _sd key can be present at any level of the JSON object hierarchy (including at the top level or nested deeper as described in Section 6) or in recursive disclosures as described in Section 4.2.6. Perhaps B (the "or" is connecting three things: at the top level, nested deeper, and recursive disclosures): An _sd key can be present at any level of the JSON object hierarchy, including at the top level, nested deeper as described in Section 6, or in recursive disclosures as described in Section 4.2.6. --> <t>Digests of Disclosures for object properties are added to an array under the new key <tt>_sd</tt> in the object. The <tt>_sd</tt> keyMUST<bcp14>MUST</bcp14> refer to an array of strings, each string being a digest of a Disclosure or a decoy digest as described in <xref target="decoy_digests"/>. An <tt>_sd</tt> key can be present at any level of the JSON object hierarchy, including the top-level, nested deeper as described in <xref target="nested_data"/>, or in recursive disclosures as described in <xref target="recursive_disclosures"/>.</t> <t>The arrayMAY<bcp14>MAY</bcp14> be empty in case the Issuer decided not to selectively disclose any of the claims at that level. However, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to omit the <tt>_sd</tt> key in this case to save space.</t> <t>The IssuerMUST<bcp14>MUST</bcp14> hide the original order of the claims in the array. To ensure this, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to shuffle the array of hashes, e.g., by sorting it alphanumerically or randomly, after potentially adding decoy digests as described in <xref target="decoy_digests"/>. The precise method does not matter as long as it does not depend on the original order of elements.</t> <t>For example, using the digest of the Disclosure from <xref target="hashing_disclosures"/>, the Issuer could create the following SD-JWT payload to make <tt>family_name</tt> selectively disclosable:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "given_name": "Alice", "_sd": ["X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0"] } ]]> </sourcecode> </section> <section anchor="embedding_array_elements"><name>Array Elements</name> <t>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 <tt>{"...": "<digest>"}</tt> is added to the array. The keyMUST<bcp14>MUST</bcp14> always be the string <tt>...</tt> (three dots). The valueMUST<bcp14>MUST</bcp14> be the digest of the Disclosure created as described in <xref target="hashing_disclosures"/>. ThereMUST NOT<bcp14>MUST NOT</bcp14> be any other keys in the object. Note that the string <tt>...</tt> was chosen because the ellipsis character, typically entered as three period characters, is commonly used in places where content is omitted from the present context.</t> <t>For example, using the digest of the array element Disclosure createdabovein <xref target="disclosures_for_array_elements"/>, the Issuer could create the following SD-JWT payload to make the second element of the <tt>nationalities</tt> array selectively disclosable:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "nationalities": ["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}, "US"] } ]]> </sourcecode> <t>As described in <xref target="verifier_verification"/>, 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 two elements, <tt>["DE", "US"]</tt>, unless the matching Disclosure for the second element is received, in which case the output would be athree elementthree-element array, <tt>["DE", "FR", "US"]</tt>.</t> </section> </section> <section anchor="decoy_digests"><name>Decoy Digests</name> <t>An IssuerMAY<bcp14>MAY</bcp14> 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 adversarial Verifier to see the original number of claims or array elements contained in the SD-JWT. Decoy digestsMAY<bcp14>MAY</bcp14> be added both to the <tt>_sd</tt> array for objects as well as in arrays.</t> <t>It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to create the decoy digests by hashing over a cryptographically secure random number. The bytes of the digestMUST<bcp14>MUST</bcp14> then bebase64url-encodedbase64url encoded as above. The same digest function as for the DisclosuresMUST<bcp14>MUST</bcp14> be used.</t> <t>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 <xref target="decoy_digests_privacy"/> for additional privacy considerations.</t> <t>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 <xref target="example-simple_structured"/>.</t> </section> <section anchor="recursive_disclosures"><name>Recursive Disclosures</name> <t>The algorithms above are compatible with "recursive disclosures", in which one selectively disclosed field reveals the existence of more selectively disclosable fields. For example, consider the following JSON structure:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "family_name": "Möbius", "nationalities": ["DE", "FR", "UK"] } ]]> </sourcecode> <t>When the Holder has multiple nationalities, theissuerIssuer may wish to conceal the presence of any statement regarding nationalities while also allowing the holder to reveal each of those nationalities individually. This can be accomplished by first making the entries within the "nationalities" array selectively disclosable, and then making the whole "nationalities" field selectively disclosable.</t> <t>The following shows each of the entries within the "nationalities" array being made selectively disclosable:</t> <!-- [rfced] Would it be appropriate to treat "Content of Disclosures:" as regular text, and include a separate <sourcecode> block for the text that follows? Note that we have set type="" (empty) as "ascii-art" seems to indicate <artwork>. Please let us know if this should be considered <artwork> rather than <sourcecode>. For example, currently, the xml includes the following: <sourcecode type="ascii-art"><![CDATA[{ "family_name": "Möbius", "nationalities": [ { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" } { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" } { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" } ] } Content of Disclosures: PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"] r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"] nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"] ]]> </sourcecode> Perhaps: <sourcecode type=""><![CDATA[{ "family_name": "Möbius", "nationalities": [ { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" } { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" } { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" } ] } ]]> </sourcecode> <t>Content of Disclosures:</t> <sourcecode type=""><![CDATA[{ PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"] r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"] nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"] ]]> </sourcecode> --> <sourcecode><![CDATA[ { "family_name": "Möbius", "nationalities": [ { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" } { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" }, { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" } ] } Content of Disclosures: PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"] r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"] nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"] ]]> </sourcecode> <t>Followed by making the whole "nationalities" array selectively disclosable:</t><sourcecode type="ascii-art"><![CDATA[{<sourcecode><![CDATA[ { "family_name": "Möbius", "_sd": [ "5G1srw3RG5W4pVTwSsYxeOWosRBbzd18ZoWKkC-hBL4" ] } Content of Disclosures: PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"] r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"] nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"] 5G1srw3... = ["4drfeTtSUK3aY_-PF12gcX","nationalities", [ { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" }, { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" }, { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" } ] ] ]]> </sourcecode> <t>With this set of disclosures, the holder could include the disclosure with hash <tt>PmnlrRj...</tt> to disclose only the "DE" nationality, or include both <tt>PmnlrRj...</tt> and <tt>r823HFN...</tt> to disclose both the "DE" and "FR" nationalities, but hide the "UK" nationality. In either case, the holder would also need to include the disclosure with hash <tt>5G1srw3...</tt> to disclose the <tt>nationalities</tt> field that contains the respective elements.</t> <t>Note that making recursive redactions introduces dependencies between the disclosure objects in an SD-JWT. The <tt>r823HFN...</tt> disclosure cannot be used without the <tt>5G1srw3...</tt> disclosure; since a Verifier would not have a matching hash that would tell it where the content of the <tt>r823HFN...</tt> disclosure should be inserted. If a disclosure object is included in an SD-JWT, then the SD-JWTMUST<bcp14>MUST</bcp14> include any other disclosure objects necessary to process the first disclosure object. In other words, any disclosure object in an SD-JWT must "connect" to the claims in the issuer-signed JWT, possibly via an intermediate disclosure object. In the above example, it would be illegal to include any one of the <tt>PmnlrRj...</tt>, <tt>r823HFN...</tt>, <tt>nP5GYjw..</tt> disclosure objects without also including the <tt>5G1srw3...</tt> disclosure object.</t> </section> </section> <section anchor="kb-jwt"><name>Key Binding JWT</name> <t>This section defines the Key Binding JWT, which encodes a signature over an SD-JWT by the Holder's private key.</t> <t>The Key Binding JWTMUST<bcp14>MUST</bcp14> be a JWT according to <xref target="RFC7519"/>, and itMUST<bcp14>MUST</bcp14> contain the following elements:</t> <ulspacing="compact">spacing="normal"> <li><t>in the JOSE header,</t> <ulspacing="compact">spacing="normal"> <li><tt>typ</tt>:REQUIRED. MUST<bcp14>REQUIRED</bcp14>. <bcp14>MUST</bcp14> be <tt>kb+jwt</tt>, which explicitly types the Key Binding JWT as recommended inSection 3.11 of<xreftarget="RFC8725"/>.</li>target="RFC8725" section="3.11"/>.</li> <li><tt>alg</tt>:REQUIRED.<bcp14>REQUIRED</bcp14>. A digital signature algorithm identifier such as per the IANA "JSON Web Signature and Encryption Algorithms" registry. ItMUST NOT<bcp14>MUST NOT</bcp14> be <tt>none</tt>.</li> </ul></li> <li><t>in the JWT payload,</t> <ulspacing="compact">spacing="normal"> <li><tt>iat</tt>:REQUIRED.<bcp14>REQUIRED</bcp14>. The value of this claimMUST<bcp14>MUST</bcp14> be the time at which the Key Binding JWT was issued using the syntax defined in <xref target="RFC7519"/>.</li> <li><tt>aud</tt>:REQUIRED.<bcp14>REQUIRED</bcp14>. The valueMUST<bcp14>MUST</bcp14> be a single string that identifies the intended receiver of the Key Binding JWT. How the value is represented is up to the protocol used and is out of scopeoffor this specification.</li> <li><tt>nonce</tt>:REQUIRED.<bcp14>REQUIRED</bcp14>. Ensures the freshness of the signature or its binding to the given transaction. The value type of this claimMUST<bcp14>MUST</bcp14> be a string. How this value is obtained is up to the protocol used and is out of scopeoffor this specification.</li> <li><tt>sd_hash</tt>:REQUIRED.<bcp14>REQUIRED</bcp14>. The base64url-encoded hash value over the Issuer-signed JWT and the selected Disclosures as defined below.</li> </ul></li> </ul> <t>The general extensibility model of JWT means that additional claims and header parameters can be added to the Key Binding JWT. However, unless there is a compelling reason, thisSHOULD<bcp14>SHOULD</bcp14> be avoided, as it may harm interoperability and burden conceptual integrity.</t> <section anchor="integrity-protection-of-the-presentation"><name>Binding to an SD-JWT</name> <t>The hash value in the <tt>sd_hash</tt> claim binds the KB-JWT to the specific SD-JWT. The <tt>sd_hash</tt> valueMUST<bcp14>MUST</bcp14> be taken over the US-ASCII bytes of the encoded SD-JWT, i.e., the Issuer-signed JWT, a tilde character, and zero or more Disclosures selected for presentation to the Verifier, each followed by a tilde character:</t><artwork><![CDATA[<Issuer-signed<artwork><![CDATA[ <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~ ]]> </artwork> <t>The bytes of the digestMUST<bcp14>MUST</bcp14> then bebase64url-encoded.</t>base64url encoded.</t> <t>The same hash algorithm as for the DisclosuresMUST<bcp14>MUST</bcp14> be used (defined by the <tt>_sd_alg</tt> element in the Issuer-signed JWT or the default value, as defined in <xref target="hash_function_claim"/>).</t> </section> <section anchor="validating-the-key-binding-jwt"><name>Validating the Key Binding JWT</name> <t>Whether to require Key Binding is up to the Verifier's policy, based on the set of trust requirementssuch(such as trustframeworksframeworks) it belongs to. See <xref target="key_binding_security"/> for security considerations.</t> <t>If the Verifier requires Key Binding, the VerifierMUST<bcp14>MUST</bcp14> ensure that the key with which it validates the signature on the Key Binding JWT is the key specified in the SD-JWT as the Holder's public key. For example, if the SD-JWT contains a <tt>cnf</tt> value with a <tt>jwk</tt> member, the Verifier would parse the provided JWK and use it to verify the Key Binding JWT.</t> <t>Details of theValidationvalidation process are defined in <xref target="verifier_verification"/>.</t> </section> </section> </section> <section anchor="main-example"><name>Example SD-JWT</name> <t>In this example, a simple SD-JWT is demonstrated. This example is split into issuance and presentation.</t><blockquote><t>Note:<!-- [rfced] Note that we have adjusted this text to remove a specific character count that is allowed per line. The number of characters is different depending on whether the text is running text (69 chars), sourcecode (69 chars), or artwork (72 chars). Original: | 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. Current: | Note: Throughout the examples in this document, line breaks | were added to JSON strings and base64-encoded strings to adhere | to the line-length limit in RFCs and for readability. JSON | does not allow line breaks within strings. --> <aside><t>Note: Throughout the examples in this document, line breaks were added to JSON strings and base64-encoded strings to adhere to the line-length limit in RFCs and for readability. JSON does not allow line breaks within strings.</t></blockquote></aside> <section anchor="issuance"><name>Issuance</name> <t>The following data about the user comprises the input JWT Claims Set used by the Issuer:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "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" ] } ]]> </sourcecode> <t>In this example, the following decisions were made by the Issuer in constructing the SD-JWT:</t> <ulspacing="compact">spacing="normal"> <li>The <tt>nationalities</tt> array is always visible, but its contents are selectively disclosable.</li> <li>The <tt>sub</tt> element as well as essential verification data (<tt>iss</tt>, <tt>exp</tt>, <tt>cnf</tt>, etc.) are always visible.</li> <li>All other claims are selectively disclosable.</li> <li>For <tt>address</tt>, the Issuer is using a flat structure, i.e., all the claims in the <tt>address</tt> claim can only be disclosed in full. Other options are discussed in <xref target="nested_data"/>.</li> </ul> <t>The following payload is used for the SD-JWT:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "_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" } } } ]]> </sourcecode> <t>The respective Disclosures, created by the Issuer, are listed below. In the text below and in other locations in this specification, the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encoded SHA-256 Hash:".</t><t><strong>Claim <tt>given_name</tt></strong>:</t> <ul spacing="compact"> <li>SHA-256 Hash: <tt>jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4</tt></li> <li>Disclosure:<br/> <tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o</tt><br/> <tt>biJd</tt></li> <li>Contents: <tt>["2GLC42sKQveCfGfryNRN9w",<ul> <li><t>Claim <tt>given_name</tt>:</t> <ul spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4</tt></t></li> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd</tt></t></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "given_name","John"]</tt></li> </ul>"John"]</tt></t></li> </ul></li></ul> <t><strong>Claim <tt>family_name</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo</tt></li> <li>Disclosure:<br/> <tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRv</tt><br/> <tt>ZSJd</tt></li> <li>Contents: <tt>["eluV5Og3gSNII8EYnsxA_A",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJd</tt></t></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "family_name","Doe"]</tt></li>"Doe"]</tt></t></li> </ul> <t><strong>Claim <tt>email</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE</tt></li> <li>Disclosure:<br/> <tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VA</tt><br/> <tt>ZXhhbXBsZS5jb20iXQ</tt></li> <li>Contents: <tt>["6Ij7tM-a5iVPGboS5tmvVA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ</tt></t></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "email","johndoe@example.com"]</tt></li>"johndoe@example.com"]</tt></t></li> </ul> <t><strong>Claim <tt>phone_number</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI</tt></li> <li>Disclosure:<br/> <tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIr</tt><br/> <tt>MS0yMDItNTU1LTAxMDEiXQ</tt></li> <li>Contents: <tt>["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number",</tt><br/> <tt>"+1-202-555-0101"]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number", "+1-202-555-0101"]</tt></t></li> </ul> <t><strong>Claim <tt>phone_number_verified</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM</tt></li> <li>Disclosure:<br/> <tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJp</tt><br/> <tt>ZmllZCIsIHRydWVd</tt></li> <li>Contents: <tt>["Qg_O64zqAxe412a108iroA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmllZCIsIHRydWVd</tt></t></li> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "phone_number_verified",true]</tt></li>true]</tt></t></li> </ul> <t><strong>Claim <tt>address</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE</tt></li> <li>Disclosure:<br/> <tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVl</tt><br/> <tt>dF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRv</tt><br/> <tt>d24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0</tt></li> <li>Contents: <tt>["AJx-095VPrpTtN4QMOqROA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0</tt></t></li> <li><t>Contents:</t><t><tt>["AJx-095VPrpTtN4QMOqROA", "address",{"street_address":</tt><br/> <tt>"123{"street_address": "123 Main St", "locality": "Anytown", "region":"Anystate",</tt><br/> <tt>"country": "US"}]</tt></li>"Anystate", "country": "US"}]</tt></t></li> </ul> <t><strong>Claim <tt>birthdate</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM</tt></li> <li>Disclosure:<br/> <tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQw</tt><br/> <tt>LTAxLTAxIl0</tt></li> <li>Contents: <tt>["Pc33JM2LchcU_lHggv_ufQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0</tt></t></li> <li><t>Contents:</t><t><tt>["Pc33JM2LchcU_lHggv_ufQ", "birthdate","1940-01-01"]</tt></li>"1940-01-01"]</tt></t></li> </ul> <t><strong>Claim <tt>updated_at</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI</tt></li> <li>Disclosure:<br/> <tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcw</tt><br/> <tt>MDAwMDAwXQ</tt></li> <li>Contents: <tt>["G02NSrQfjFXQ7Io09syajA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDAwMDAwXQ</tt></t></li> <li><t>Contents:</t><t><tt>["G02NSrQfjFXQ7Io09syajA", "updated_at",1570000000]</tt></li>1570000000]</tt></t></li> </ul> <t><strong>Array Entry</strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo</tt></li> <li>Disclosure:<br/> <tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0</tt></li> <li>Contents: <tt>["lklxF5jMYlGTPUovMNIvCA", "US"]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0</tt></t></li> <li><t>Contents:</t><t><tt>["lklxF5jMYlGTPUovMNIvCA", "US"]</tt></t></li> </ul> <t><strong>Array Entry</strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0</tt></li> <li>Disclosure:<br/> <tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0</tt></li> <li>Contents: <tt>["nPuoQnkRFq3BIeAm7AnXFA", "DE"]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0</tt></t></li> <li><t>Contents:</t><t><tt>["nPuoQnkRFq3BIeAm7AnXFA", "DE"]</tt></t></li> </ul> <t>The payload is then signed by the Issuer to create the following Issuer-signed JWT:</t> <sourcecodetype="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBbtype="txt"><![CDATA[ eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1 SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2 Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15 VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1 ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz -CXo6R04b7jYrpj9mNRAvVssXou1iw ]]> </sourcecode> <t>Adding the Disclosures produces the SD-JWT:</t> <sourcecodetype="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBbtype="txt"><![CDATA[ eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1 SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2 Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15 VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1 ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz -CXo6R04b7jYrpj9mNRAvVssXou1iw~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgI mdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZh bWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWl sIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZW5IZGhR IiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ~WyJRZ19PNjR6cUF4Z TQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmllZCIsIHRydWVd~WyJBSngt MDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjog IjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFu eXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZR IiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5 YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDAwMDAwXQ~WyJsa2x4RjVqTVlsR1RQVW92T U5JdkNBIiwgIlVTIl0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0~ ]]> </sourcecode> </section> <section anchor="presentation"><name>Presentation</name> <t>The following non-normative example shows an SD-JWT+KB as it would be sent from the Holder to the Verifier. Note that it consists of six tilde-separated parts, with the Issuer-signed JWT as shown above in the beginning, four Disclosures (for the claims <tt>given_name</tt>, <tt>family_name</tt>, <tt>address</tt>, and one of the <tt>nationalities</tt>) in the middle, and the Key Binding JWT as the last element.</t> <sourcecodetype="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBbtype="txt"><![CDATA[ eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1 SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2 Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15 VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1 ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz -CXo6R04b7jYrpj9mNRAvVssXou1iw~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgI mZhbWlseV9uYW1lIiwgIkRvZSJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFk ZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5 IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMi fV0~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~eyJhbGciOiAiRVMyNTYiLCA idHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodH RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF 9oYXNoIjogIjBfQWYtMkItRWhMV1g1eWRoX3cyeHp3bU82aU02NkJfMlFDRWFuSTRmVV kifQ.T3SIus2OidNl41nmVkTZVCKKhOAX97aOldMyHFiYjHm261eLiJ1YiuONFiMN8Ql CmYzDlBLAdPvrXh52KaLgUQ ]]> </sourcecode> <t>The following Key Binding JWT payload was created and signed for this presentation by the Holder:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "nonce": "1234567890", "aud": "https://verifier.example.org", "iat": 1748537244, "sd_hash": "0_Af-2B-EhLWX5ydh_w2xzwmO6iM66B_2QCEanI4fUY" } ]]> </sourcecode> <t>If the Verifier did not require Key Binding, then the Holder could have presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in an SD-JWT+KB.</t> <t>After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "sub": "user_42", "nationalities": [ "US" ], "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" } }, "family_name": "Doe", "address": { "street_address": "123 Main St", "locality": "Anytown", "region": "Anystate", "country": "US" }, "given_name": "John" } ]]> </sourcecode> </section> </section> <section anchor="nested_data"><name>Considerations on Nested Data in SD-JWTs</name> <t>Being JSON, an object in an SD-JWT payloadMAY<bcp14>MAY</bcp14> contain name/value pairs where the value is another object or objectsMAY<bcp14>MAY</bcp14> be elements in arrays. In SD-JWT, the Issuer decides for each claim individually, on each level of the JSON, whether or not the claim should be selectivelydisclosable or not.disclosable. This choice can be made on each level independent of whether keys higher in the hierarchy are selectively disclosable.</t> <t>From this it follows that the <tt>_sd</tt> key containing digestsMAY<bcp14>MAY</bcp14> appear multiple times in an SD-JWT, and likewise, thereMAY<bcp14>MAY</bcp14> be multiple arrays within the hierarchy with each having selectively disclosable elements. Digests of selectively disclosable claimsMAY<bcp14>MAY</bcp14> even appear within other Disclosures.</t> <t>The following examples illustrate some of the options an Issuer has. It is up to the Issuer to decide which structure to use, depending on, for example, the expected use cases for the SD-JWT, requirements for privacy, size considerations, or operating environment requirements. For more examples with nested structures, see Appendices <xreftarget="example-simple_structured"/>target="example-simple_structured" format="counter"/> and <xreftarget="example-complex-structured-sd-jwt"/>.</t>target="example-complex-structured-sd-jwt" format="counter"/>.</t> <t>The following input JWT Claims Set is used as an example throughout this section:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "address": { "street_address": "Schulstr. 12", "locality": "Schulpforta", "region": "Sachsen-Anhalt", "country": "DE" } } ]]> </sourcecode><blockquote><t>Note:<!-- [rfced] For clarity in the text output, may we add "claim" after address here? While "claim" is enclosed in <tt>, which makes it visually distinct from surrounding text in the html and pdf, there is no such visual distinction in the text. Original: | Note: 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. Perhaps: | Note: 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 an address claim can be | represented in an SD-JWT. --> <aside><t>Note: 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 <tt>address</tt> can be represented in an SD-JWT.</t></blockquote></aside> <section anchor="example-flat-sd-jwt"><name>Example: Flat SD-JWT</name> <t>The Issuer can decide to treat the <tt>address</tt> claim as a block that can either be disclosed completely or not at all. The following example shows that in this case, the entire <tt>address</tt> claim is treated as an object in the Disclosure.</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "_sd": [ "fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do" ], "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "_sd_alg": "sha-256" } ]]> </sourcecode> <t>The Issuer would create the following Disclosure referenced by the one hash in the SD-JWT:</t> <t><strong>Claim <tt>address</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do</tt></li> <li>Disclosure:<br/> <tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVl</tt><br/> <tt>dF9hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1</tt><br/> <tt>bHBmb3J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRy</tt><br/> <tt>eSI6ICJERSJ9XQ</tt></li> <li>Contents: <tt>["2GLC42sKQveCfGfryNRN9w",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do</tt></t></li> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1bHBmb3J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRyeSI6ICJERSJ9XQ</tt></t></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "address",{"street_address":</tt><br/> <tt>"Schulstr.{"street_address": "Schulstr. 12", "locality": "Schulpforta","region":</tt><br/> <tt>"Sachsen-Anhalt","region": "Sachsen-Anhalt", "country":"DE"}]</tt></li>"DE"}]</tt></t></li> </ul> </section> <section anchor="example-structured-sd-jwt"><name>Example: Structured SD-JWT</name> <t>The Issuer may instead decide to make the <tt>address</tt> claim contents selectively disclosable individually:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "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" } ]]> </sourcecode> <t>In this case, the Issuer would use the following data in the Disclosures for the <tt>address</tt> sub-claims:</t> <t><strong>Claim <tt>street_address</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM</tt></li> <li>Disclosure:<br/> <tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwg</tt><br/> <tt>IlNjaHVsc3RyLiAxMiJd</tt></li> <li>Contents: <tt>["2GLC42sKQveCfGfryNRN9w",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM</tt></t></li> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlNjaHVsc3RyLiAxMiJd</tt></t></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr.12"]</tt></li>12"]</tt></t></li> </ul> <t><strong>Claim <tt>locality</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0</tt></li> <li>Disclosure:<br/> <tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVs</tt><br/> <tt>cGZvcnRhIl0</tt></li> <li>Contents: <tt>["eluV5Og3gSNII8EYnsxA_A",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZvcnRhIl0</tt></t></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "locality","Schulpforta"]</tt></li>"Schulpforta"]</tt></t></li> </ul> <t><strong>Claim <tt>region</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88</tt></li> <li>Disclosure:<br/> <tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2Vu</tt><br/> <tt>LUFuaGFsdCJd</tt></li> <li>Contents: <tt>["6Ij7tM-a5iVPGboS5tmvVA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFuaGFsdCJd</tt></t></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "region","Sachsen-Anhalt"]</tt></li>"Sachsen-Anhalt"]</tt></t></li> </ul> <t><strong>Claim <tt>country</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM</tt></li> <li>Disclosure:<br/> <tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ</tt></li> <li>Contents: <tt>["eI8ZWm9QnKPpNPeNenHdhQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "country","DE"]</tt></li>"DE"]</tt></t></li> </ul> <t>The Issuer may also make one sub-claim of <tt>address</tt> permanently disclosed and hide only the other sub-claims:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "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" } ]]> </sourcecode> <t>In this case, there would be no Disclosure for <tt>country</tt>, since it is provided in the clear.</t> </section> <section anchor="example-sd-jwt-with-recursive-disclosures"><name>Example: SD-JWT with Recursive Disclosures</name> <t>The Issuer may also decide to make the <tt>address</tt> claim contents selectively disclosable recursively, i.e., the <tt>address</tt> claim is made selectively disclosable as well as its sub-claims:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "_sd": [ "HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg" ], "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "_sd_alg": "sha-256" } ]]> </sourcecode> <t>The Issuer first creates Disclosuresfirstfor the sub-claims and then includes their digests in the Disclosure for the <tt>address</tt> claim:</t> <t><strong>Claim <tt>street_address</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM</tt></li> <li>Disclosure:<br/> <tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwg</tt><br/> <tt>IlNjaHVsc3RyLiAxMiJd</tt></li> <li>Contents: <tt>["2GLC42sKQveCfGfryNRN9w",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM</tt></t></li> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlNjaHVsc3RyLiAxMiJd</tt></t></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr.12"]</tt></li>12"]</tt></t></li> </ul> <t><strong>Claim <tt>locality</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0</tt></li> <li>Disclosure:<br/> <tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVs</tt><br/> <tt>cGZvcnRhIl0</tt></li> <li>Contents: <tt>["eluV5Og3gSNII8EYnsxA_A",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZvcnRhIl0</tt></t></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "locality","Schulpforta"]</tt></li>"Schulpforta"]</tt></t></li> </ul> <t><strong>Claim <tt>region</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88</tt></li> <li>Disclosure:<br/> <tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2Vu</tt><br/> <tt>LUFuaGFsdCJd</tt></li> <li>Contents: <tt>["6Ij7tM-a5iVPGboS5tmvVA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFuaGFsdCJd</tt></t></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "region","Sachsen-Anhalt"]</tt></li>"Sachsen-Anhalt"]</tt></t></li> </ul> <t><strong>Claim <tt>country</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM</tt></li> <li>Disclosure:<br/> <tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ</tt></li> <li>Contents: <tt>["eI8ZWm9QnKPpNPeNenHdhQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "country","DE"]</tt></li>"DE"]</tt></t></li> </ul> <t><strong>Claim <tt>address</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg</tt></li> <li>Disclosure:<br/> <tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6</tt><br/> <tt>IFsiNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVk</tt><br/> <tt>MCIsICI5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3Nmtt</tt><br/> <tt>WXlNIiwgIktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEy</tt><br/> <tt>TjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8y</tt><br/> <tt>cm8yamZYTSJdfV0</tt></li> <li>Contents: <tt>["Qg_O64zqAxe412a108iroA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCIsICI5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgIktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8ycm8yamZYTSJdfV0</tt></t></li> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "address",{"_sd":</tt><br/> <tt>["6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",</tt><br/> <tt>"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",</tt><br/> <tt>"KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88",</tt><br/> <tt>"WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]</tt></li>{"_sd": ["6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88", "WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]</tt></t></li> </ul> </section> </section> <section anchor="verification-1"><name>Verification and Processing</name> <section anchor="sd_jwt_verification"><name>Verification of the SD-JWT</name> <t>Upon receiving an SD-JWT, either directly or as a component of an SD-JWT+KB, a Holder oraVerifier needs to ensure that:</t> <ulspacing="compact">spacing="normal"> <li>the Issuer-signed JWT is valid, and</li> <li>all Disclosures are valid and correspond to a respective digest value in the Issuer-signed JWT (directly in the payload or recursively included in the contents of other Disclosures).</li> </ul> <t>The Holder or the VerifierMUST<bcp14>MUST</bcp14> perform the following checks when receiving an SD-JWT to validate the SD-JWT and extract the payload:</t> <olspacing="compact">type="1" spacing="normal"> <li>Separate the SD-JWT into the Issuer-signed JWT and the Disclosures (if any).</li> <li><t>Validate the Issuer-signed JWT:</t> <olspacing="compact">type="a" spacing="normal"> <li>Ensure thatathe used signing algorithm wasused that wasdeemed secure for the application. Refer to <xref target="RFC8725"/>, Sections3.1<xref target="RFC8725" section="3.1" sectionFormat="bare"/> and3.2<xref target="RFC8725" section="3.2" sectionFormat="bare"/> for details. The <tt>none</tt> algorithmMUST NOT<bcp14>MUST NOT</bcp14> be accepted.</li> <li>Validate the signature over the Issuer-signed JWT perSection 5.2 of<xreftarget="RFC7515"/>.</li>target="RFC7515" section="5.2"/>.</li> <li>Validate the Issuer and that the signing key belongs to this Issuer.</li> <li>Check that the <tt>_sd_alg</tt> claim value is understood and the hash algorithm is deemed secure according to the Holder or Verifier's policy (see <xref target="hash_function_claim"/>).</li> </ol></li> <li><t>Process the Disclosures and embedded digests in the Issuer-signed JWT as follows:</t> <olspacing="compact">type="a" spacing="normal"> <li><t>For each Disclosure provided:</t> <olspacing="compact">type="i" spacing="normal"> <li>Calculate the digest over the base64url-encoded string as described in <xref target="hashing_disclosures"/>.</li> </ol></li> <li><t>(*) Identify all embedded digests in the Issuer-signed JWT as follows:</t> <olspacing="compact">type="i" spacing="normal"> <li>Find all objects having an <tt>_sd</tt> key that refers to an array of strings.</li> <li>Find all array elements that are objects with one key, that key being <tt>...</tt> and referring to a string.</li> </ol></li> <li><t>(**) For each embedded digest found in the previous step:</t> <olspacing="compact">type="i" spacing="normal"> <li>Compare the value with the digests calculated previously and find the matching Disclosure. If no such Disclosure can be found, the digestMUST<bcp14>MUST</bcp14> be ignored.</li> <li><t>If the digest was found in an object's <tt>_sd</tt> key:</t> <olspacing="compact">type="1" spacing="normal"> <li>If the contents of the respective Disclosure is not a JSON array of three elements (salt, claim name, claim value), the SD-JWTMUST<bcp14>MUST</bcp14> be rejected.</li> <li>If the claim name is <tt>_sd</tt> or <tt>...</tt>, the SD-JWTMUST<bcp14>MUST</bcp14> be rejected.</li> <li>If the claim name already exists at the level of the <tt>_sd</tt> key, the SD-JWTMUST<bcp14>MUST</bcp14> be rejected.</li> <li>Insert, at the level of the <tt>_sd</tt> key, a new claim using the claim name and claim value from the Disclosure.</li> <li>Recursively process the value using the steps described in (*) and (**).</li> </ol></li> <li><t>If the digest was found in an array element:</t> <olspacing="compact">type="1" spacing="normal"> <li>If the contents of the respective Disclosure is not a JSON array of two elements (salt, value), the SD-JWTMUST<bcp14>MUST</bcp14> be rejected.</li> <li>Replace the array element with the value from the Disclosure.</li> <li>Recursively process the value using the steps described in (*) and (**).</li> </ol></li> </ol></li> <li>Remove all array elements for which the digest was not found in the previous step.</li> <li>Remove all <tt>_sd</tt> keys and their contents from the Issuer-signed JWT payload. If this results in an object with no properties, it should be represented as an empty object <tt>{}</tt>.</li> <li>Remove the claim <tt>_sd_alg</tt> from the SD-JWT payload.</li> </ol></li> <li>If any digest value is encountered more than once in the Issuer-signed JWT payload (directly or recursively via other Disclosures), the SD-JWTMUST<bcp14>MUST</bcp14> be rejected.</li> <li>If any Disclosure was not referenced by digest value in the Issuer-signed JWT (directly or recursively via other Disclosures), the SD-JWTMUST<bcp14>MUST</bcp14> be rejected.</li> <li>Check that the SD-JWT is valid using claims such as <tt>nbf</tt>, <tt>exp</tt>, and <tt>aud</tt> in the processed payload, if present. If a required validity-controlling claim is missing (see <xref target="sd-validity-claims"/>), the SD-JWTMUST<bcp14>MUST</bcp14> be rejected.</li> </ol> <t>If any step fails, the SD-JWT is not valid, and processingMUST<bcp14>MUST</bcp14> be aborted. Otherwise, the JSON document resulting from the preceding processing and verification steps, herein referred to as theProcessed"Processed SD-JWTPayload,Payload", can be made available to the application to be used for its intended purpose.</t><blockquote><t>Note<aside><t>Note that these processing steps do not yield any guarantees to the Holder about having received a complete set of Disclosures. That is, for some digest values in the Issuer-signed JWT (which are not decoydigests)digests), there may be no corresponding Disclosures, for example, if the message from the Issuer was truncated. It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the user whenneeded.</t> </blockquote></section>needed.</t></aside> </section> <section anchor="holder_verification"><name>Processing by the Holder</name> <t>The Issuer provides the Holder with an SD-JWT, not an SD-JWT+KB. If the Holder receives an SD-JWT+KB, itMUST<bcp14>MUST</bcp14> be rejected.</t> <t>When receiving an SD-JWT, the HolderMUST<bcp14>MUST</bcp14> do the following:</t> <olspacing="compact">type="1" spacing="normal"> <li>Process the SD-JWT as defined in <xref target="sd_jwt_verification"/> to validate it and extract the payload.</li> <li>Ensure that the contents of claims in the payload are acceptable (depending on the application; for example, check that any values the Holder can check are correct).</li> </ol> <t>For presentation to a Verifier, the HolderMUST<bcp14>MUST</bcp14> perform the following (or equivalent) steps (in addition to the checks described in <xref target="sd_jwt_verification"/> performed after receiving the SD-JWT):</t> <olspacing="compact">type="1" spacing="normal"> <li>Decide which Disclosures to release to the Verifier, obtaining consent if necessary (note that if and how consent is attained is out of scope for this document).</li> <li><t>Verify that each selected Disclosure satisfies one of the two following conditions:</t> <olspacing="compact">type="a" spacing="normal"> <li>The hash of the Disclosure is contained in the Issuer-signed JWTclaims</li>claims.</li> <li>The hash of the Disclosure is contained in the claim value of another selectedDisclosure</li>Disclosure.</li> </ol></li> <li>Assemble the SD-JWT, including the Issuer-signed JWT and the selected Disclosures (see <xref target="data_formats"/> for the format).</li> <li><t>If Key Binding is not required:</t> <olspacing="compact">type="a" spacing="normal"> <li>Send the SD-JWT to the Verifier.</li> </ol></li> <li><t>If Key Binding is required:</t> <olspacing="compact">type="a" spacing="normal"> <li>Create a Key Binding JWT tied to the SD-JWT.</li> <li>Assemble the SD-JWT+KB by concatenating the SD-JWT and the Key Binding JWT.</li> <li>Send the SD-JWT+KB to the Verifier.</li> </ol></li> </ol> </section> <section anchor="verifier_verification"><name>Verification by the Verifier</name> <t>Upon receiving a presentation from a Holder, in the form of either an SD-JWT or an SD-JWT+KB, in addition to the checks described in <xref target="sd_jwt_verification"/>, Verifiers need to ensure that</t> <ulspacing="compact">spacing="normal"> <li>if Key Binding is required, then the Holder has provided an SD-JWT+KB, and</li> <li>the Key Binding JWT is signed by the Holder and valid.</li> </ul> <t>To this end, VerifiersMUST<bcp14>MUST</bcp14> follow the following steps (or equivalent):</t> <olspacing="compact">type="1" spacing="normal"> <li>Determine if Key Binding is to be checked according to the Verifier's policy for the use case at hand. This decisionMUST NOT<bcp14>MUST NOT</bcp14> be based on whether or not a Key Binding JWT is provided by theHolder or not.Holder. Refer to <xref target="key_binding_security"/> for details.</li> <li>If Key Binding is required and the Holder has provided an SD-JWT (without Key Binding), the VerifierMUST<bcp14>MUST</bcp14> reject the presentation.</li> <li>If the Holder has provided an SD-JWT+KB, parse it into an SD-JWT and a Key Binding JWT.</li> <li>Process the SD-JWT as defined in <xref target="sd_jwt_verification"/> to validate the presentation and extract the payload.</li> <li><t>If Key Binding is required:</t> <olspacing="compact">type="a" spacing="normal"> <li>Determine the public key for the Holder from the SD-JWT (see <xref target="key_binding"/>).</li> <li>Ensure that a signing algorithm was used that was deemed secure for the application. Refer to <xref target="RFC8725"/>, Sections3.1<xref target="RFC8725" section="3.1" sectionFormat="bare"/> and3.2<xref target="RFC8725" section="3.2" sectionFormat="bare"/> for details. The <tt>none</tt> algorithmMUST NOT<bcp14>MUST NOT</bcp14> be accepted.</li> <li>Validate the signature over the Key Binding JWT perSection 5.2 of<xreftarget="RFC7515"/>.</li>target="RFC7515" section="5.2"/>.</li> <li>Check that the <tt>typ</tt> of the Key Binding JWT is <tt>kb+jwt</tt> (see <xref target="kb-jwt"/>).</li> <li>Check that the creation time of the Key Binding JWT, as determined by the <tt>iat</tt> claim, is within an acceptable window.</li> <li>Determine that the Key Binding JWT is bound to the current transaction and was created for this Verifier (replay detection) by validating <tt>nonce</tt> and <tt>aud</tt> claims.</li> <li>Calculate the digest over the Issuer-signed JWT and Disclosures as defined in <xref target="integrity-protection-of-the-presentation"/> and verify that it matches the value of the <tt>sd_hash</tt> claim in the Key Binding JWT.</li> <li>Check that the Key Binding JWT is a valid JWT in all other respects, per <xref target="RFC7519"/> and <xref target="RFC8725"/>.</li> </ol></li> </ol> <t>If any step fails, the presentation is not valid and processingMUST<bcp14>MUST</bcp14> be aborted.</t> <t>Otherwise, the Processed SD-JWT Payload can be passed to the application to be used for the intended purpose.</t> </section> </section> <section anchor="json_serialization"><name>JWS JSON Serialization</name> <t>This section describes an alternative format for SD-JWTs and SD-JWT+KBs using the JWS JSON Serialization from <xref target="RFC7515"/>. Supporting this format isOPTIONAL.</t><bcp14>OPTIONAL</bcp14>.</t> <section anchor="json_serialization_unprotected_headers"><name>New Unprotected Header Parameters</name> <t>For both the General and Flattened JSON Serialization, the SD-JWT or SD-JWT+KB is represented as a JSON object according toSection 7.2 of<xreftarget="RFC7515"/>.target="RFC7515" section="7.2"/>. The following new unprotected header parameters are defined:</t><ul spacing="compact"> <li><tt>disclosures</tt>: An<dl spacing="normal"> <dt><tt>disclosures</tt>:</dt><dd>An array of strings where each element is an individual Disclosure as described in <xreftarget="creating_disclosures"/>.</li> <li><tt>kb_jwt</tt>: Presenttarget="creating_disclosures"/>.</dd> <dt><tt>kb_jwt</tt>:</dt><dd>Present only in an SD-JWT+KB, the Key Binding JWT as described in <xreftarget="kb-jwt"/>.</li> </ul>target="kb-jwt"/>.</dd> </dl> <t>In an SD-JWT+KB, <tt>kb_jwt</tt>MUST<bcp14>MUST</bcp14> be present when using the JWS JSON Serialization, and the digest in the <tt>sd_hash</tt> claimMUST<bcp14>MUST</bcp14> be taken over the SD-JWT as described in <xref target="integrity-protection-of-the-presentation"/>. This means that even when using the JWS JSON Serialization, the representation as a regular SD-JWT Compact SerializationMUST<bcp14>MUST</bcp14> be created temporarily to calculate the digest. In detail, the SD-JWT Compact Serialization part is built by concatenating the protected header, the payload, and the signature of the JWS JSON serialized SD-JWT using a <tt>.</tt> character as a separator, and using the Disclosures from the <tt>disclosures</tt> member of the unprotected header.</t> <t>Unprotected headers other than <tt>disclosures</tt> are not covered by the digest, and therefore, as usual, are not protected against tampering.</t> </section> <section anchor="flattened-json-serialization"><name>Flattened JSON Serialization</name> <t>In the case oftheFlattened JSON Serialization, there is only one unprotected header.</t> <t>The following is a non-normative example of a JWS JSON serialized SD-JWT as issued using the Flattened JSON Serialization:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "header": { "disclosures": [ "WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICJqb2huX2RvZV80M iJd", "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob iJd", "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ SJd", "WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImJpcnRoZGF0ZSIsICIxOTQwL TAxLTAxIl0" ] }, "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", "signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ" } ]]> </sourcecode> <t>The following is an SD-JWT+KB with two Disclosures:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "header": { "disclosures": [ "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ SJd", "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob iJd" ], "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25j ZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW 1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlZqdFBz Z1pwUVRSeEtKdkRwU0otblhsWktFOVo5TGdENEZ5Q3d3b05NUncifQ.GrDvJ2j hYNmUvqdwVEIrxeTFEuI5qKSM7I6P95JmA6Wko-FBB5vPGQn0wvmdgjLCE2iDR h1r82zchjmABQ3V8w" }, "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", "signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ" } ]]> </sourcecode> </section> <section anchor="general-json-serialization"><name>General JSON Serialization</name> <t>In the case oftheGeneral JSON Serialization, there are multiple unprotected headers (one per signature). If present, <tt>disclosures</tt> and<tt>kb_jwt</tt>, MUST<tt>kb_jwt</tt> <bcp14>MUST</bcp14> be included in the first unprotected header andMUST NOT<bcp14>MUST NOT</bcp14> be present in any following unprotected headers.</t> <t>The following is a non-normative example of a presentation of a JWS JSON serializedSD-JWTSD-JWT, including a Key Binding JWT using the General JSON Serialization:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", "signatures": [ { "header": { "disclosures": [ "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgI kRvZSJd", "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiS m9obiJd" ], "kid": "issuer-key-1", "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJu b25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaW VyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNo IjogInFieUlXUDNwaFZneEVzRFJpd2R3OVc2QkozZHhpUEx1bWNZcFBidT RFYjgifQ.VyZqxaVHh1XE6M-kuax_7Laq42uFDrx17lLG2jluyKgy_PqC8 5z4DVpISdMZDdSANGs-0zN2N7xnM-E1Pg0sOw" }, "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", "signature": "dz1N3uvhVHJjldyXwppmBLieTj0vuBMbzL06rnrLIuxEQb9B HoIOwGrWh-UadW4orRpEiEtjf7xyHDONMJ6tBw" }, { "header": { "kid": "issuer-key-2" }, "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", "signature": "kuXio_U88RH_-fihAPET4AFUjj0BpxsT6yddMFIr6pfHKtAe 0FOJNWQxU42rfnORuNQNTgGsf2A8LjEba5inNg" } ] } ]]> </sourcecode> </section> <section anchor="verification-of-the-jws-json-serialized-sd-jwt"><name>Verification of the JWS JSON Serialized SD-JWT</name> <t>Verification of the JWS JSON serialized SD-JWT follows the rules defined in <xref target="verification"/>, except for the following aspects:</t> <ulspacing="compact">spacing="normal"> <li>The SD-JWT or SD-JWT+KB does not need to be split into component parts and the Disclosures can be found in the <tt>disclosures</tt> member of the unprotected header.</li> <li>To verify the digest in <tt>sd_hash</tt> in the Key Binding JWT of an SD-JWT+KB, the VerifierMUST<bcp14>MUST</bcp14> assemble the string to be hashed as described in <xref target="json_serialization_unprotected_headers"/>.</li> </ul> </section> </section> <section anchor="security_considerations"><name>Security Considerations</name><t>Security<t>The security considerationsin this sectionhelp achieve the following properties:</t><t><strong>Selective Disclosure:</strong> An<dl spacing="normal" newline="true"> <dt><strong>Selective Disclosure:</strong></dt><dd>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 presentedSD-JWT.</t> <t><strong>Integrity:</strong>SD-JWT.</dd> <!-- [rfced] In the Security Considerations, please note the following: a) We have nested the second paragraph under Integrity. Please verify that this is correct. b) May we remove the bold here since the headings are more clear? Original: *Integrity:* A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier. Additionally, as described in Section 9.5, the application of Key Binding can ensure that the presenter of an SD-JWT credential is the Holder of the credential. Current: *Integrity:* A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier. Additionally, as described in Section 9.5, the application of Key Binding can ensure that the presenter of an SD-JWT credential is the Holder of the credential. --> <dt><strong>Integrity:</strong></dt><dd><t>A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier.</t> <t>Additionally, as described in <xref target="key_binding_security"/>, the application of Key Binding can ensure that the presenter of an SD-JWT credential is the Holder of thecredential.</t>credential.</t></dd></dl> <section anchor="sec-is-jwt"><name>Mandatory Signing of theIssuer-signedIssuer-Signed JWT</name> <t>The JWTMUST<bcp14>MUST</bcp14> be signed by the Issuer to protect the 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).</t> <t>The VerifierMUST<bcp14>MUST</bcp14> always check the signature of the Issuer-signed JWT to ensure that it has not been tampered with sincetheits issuance. The Issuer-signed JWTMUST<bcp14>MUST</bcp14> be rejected if the signature cannot be verified.</t> <t>The security of the Issuer-signed JWT depends on the security of the signature algorithm. Per the last paragraph ofSection 5.2 of<xreftarget="RFC7515"/>,target="RFC7515" section="5.2"/>, it is an application-specific decision to choose the appropriate JWS algorithm from <xreftarget="IANA.JWS.Algorithms"/>,target="JWS.Algs"/>, including post-quantum algorithms, when they are ready.</t> </section> <section anchor="sec-disclosures"><name>Manipulation of Disclosures</name> <t>Holders can manipulate the Disclosures by changing the values of the claims before sending them to the Verifier. The VerifierMUST<bcp14>MUST</bcp14> 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.</t> <t>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.</t> <t>The steps described in <xref target="verifier_verification"/> ensure that the Verifier checks the Disclosures correctly.</t> </section> <section anchor="salt-entropy"><name>Entropy of the Salt</name> <t>The security model that conceals the plaintext claims relies on the high entropy random data of the salt as additional input to the hash function. The randomness ensures that the same plaintext claim value does not produce the same digest value. It also makes it infeasible to guess the preimage of the digest (thereby learning the plaintext claim value) by enumerating the potential value space for a claim into the hash function to search for a matching digest value. It is therefore vitally important that unrevealed salts cannot be learned or guessed, even if other salts have been revealed. As such, each saltMUST<bcp14>MUST</bcp14> be created in such a manner that it is cryptographically random, sufficiently long, and has high enough entropy that it is infeasible to guess. A new saltMUST<bcp14>MUST</bcp14> be chosen for each claim independently of other salts. SeeRandomness"Randomness Requirements forSecuritySecurity" <xref target="RFC4086"/> for considerations on generating random values.</t> <t>TheRECOMMENDED<bcp14>RECOMMENDED</bcp14> minimum length of therandomly-generatedrandomly generated portion of the salt is 128 bits.</t> <t>The IssuerMUST<bcp14>MUST</bcp14> ensure that a new salt value is chosen for each claim, including when the same claim name occurs at different places in the structure of the SD-JWT. This can be seen in the example in <xref target="example-complex-structured-sd-jwt"/>, where multiple claims with the name <tt>type</tt> appear, but each of them has a different salt.</t> </section> <section anchor="choice-of-a-hash-algorithm"><name>Choice of a Hash Algorithm</name> <!-- [rfced] We are wondering whether "but" should be "and" here? That is, it must be preimage resistant and not allow an observer to infer any partial information? Original: 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. --> <t>To ensure privacy of claims that are selectivelydisclosable,disclosable but are not being disclosed in a given presentation, the hash functionMUST<bcp14>MUST</bcp14> 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 functionMUST<bcp14>MUST</bcp14> 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 needs to be computationally hiding.</t> <t>To ensure the integrity of selectively disclosable claims, the hash functionMUST<bcp14>MUST</bcp14> be second-preimage resistant. That is, for any combination of salt, claimnamename, and claim value, it is infeasible to find a different combination of salt, claimnamename, and claim value thatresultresults in the same digest.</t> <t>The hash functionSHOULD<bcp14>SHOULD</bcp14> 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 digestsSHOULD<bcp14>SHOULD</bcp14> 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.</t> <t>Inclusion in the "Named Information HashAlgorithm" registryAlgorithm Registry" <xreftarget="IANA.Hash.Algorithms"/>target="Hash.Algs"/> alone does not indicate a hash algorithm's suitability for use in SD-JWT (it contains several heavily truncated digests, such as <tt>sha-256-32</tt> and <tt>sha-256-64</tt>, which are unfit for security applications).</t> </section> <section anchor="key_binding_security"><name>Key Binding</name> <t>Key Binding aims to ensure that the presenter of an SD-JWT credential is actually the Holder of the credential. An SD-JWT compatible with Key Binding contains a public key, or a reference to a public key, that corresponds to a private key possessed by the Holder. The Verifier requires that the Holder prove possession of that private key when presenting the SD-JWT credential.</t> <t>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, afterathe credential was leaked to an attacker, the attacker can present the credential to anyverifierVerifier that does not require a binding.But alsoAlso, 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.</t> <t>VerifiersMUST<bcp14>MUST</bcp14> decide whether Key Binding is required for a particular use case before verifying a credential. This decision can be informed by various factorsincluding,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.</t> <t>It is important that a Verifierdoesnot make its security policy decisions based on data that can be influenced by an attacker. For this reason, when deciding whether or not Key Binding isrequired or not,required, VerifiersMUST NOT<bcp14>MUST NOT</bcp14> take into account whether the Holder has provided an SD-JWT+KB or a bareSD-JWT, since otherwiseSD-JWT; otherwise, an attacker could strip the KB-JWT from an SD-JWT+KB and present theresultingresultant SD-JWT.</t> <t>Furthermore, Verifiers should be aware that Key Binding information may have been added to an SD-JWT in a format that they do not recognize and therefore may not be able to tell whether or not the SD-JWT supports KeyBinding or not.</t>Binding.</t> <t>If a Verifier determines that Key Binding is required for a particular use case and the Holder presents either a bare SD-JWT or an SD-JWT+KB with an invalid Key Binding JWT, then the Verifier will reject the presentation when following the verification steps described in <xref target="verifier_verification"/>.</t> </section> <section anchor="concealing-claim-names"><name>Concealing Claim Names</name> <t>SD-JWT ensures that names of claims that are selectively disclosable are always concealed unless the claim's value is disclosed. This prevents an attacker from learning the names of such claims. However, the names of the claims that are permanently disclosed are not hidden. This includes the keys of objects that themselves are not concealed, but contain concealed claims. This limitation needs to be taken into account by Issuers when creating the structure of the SD-JWT.</t> </section> <sectionanchor="sd-validity-claims"><name>Selectively-Disclosableanchor="sd-validity-claims"><name>Selectively Disclosable Validity Claims</name> <t>An IssuerMUST NOT<bcp14>MUST NOT</bcp14> 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 andSHOULD<bcp14>SHOULD</bcp14> be listed by any application-specific profiles of SD-JWT. The following is a list of registered JWT claim names thatSHOULD<bcp14>SHOULD</bcp14> be considered assecurity-critical:</t>security critical:</t> <ulspacing="compact">spacing="normal"> <li><tt>iss</tt> (Issuer)</li> <li><tt>aud</tt> (Audience), although issuersMAY<bcp14>MAY</bcp14> allow individual entries in the array to be selectively disclosable</li> <li><tt>exp</tt> (Expiration Time)</li> <li><tt>nbf</tt> (Not Before)</li> <li><tt>cnf</tt> (Confirmation Key)</li> </ul> <t>Issuers will typically include claims controlling the validity of the SD-JWT in plaintext in the SD-JWT payload, but there is no guarantee theywouldwill do so. Therefore, Verifiers cannot reliably depend on that and need to operate as though security-critical claims might be selectively disclosable.</t> <t>Verifiers thereforeMUST<bcp14>MUST</bcp14> 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 <xref target="sd_jwt_verification"/>.</t> <t>The precise set of required validity claims will typically be defined by operating environment rules, an application-specific profile, or the credentialformatformat, andMAY<bcp14>MAY</bcp14> include claims other than those listed herein.</t> </section> <section anchor="issuer_signature_key_distribution"><name>Distribution and Rotation of Issuer Signature Verification Key</name> <t>This specification does not define how signature verification keys of Issuers are distributed to Verifiers. However, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> 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 <xref target="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.</t> </section> <section anchor="forwarding-credentials"><name>Forwarding Credentials</name> <t>Any entity in possession of an SD-JWT (including an SD-JWT extracted from an SD-JWT+KB) can forward it to any third party that does not enforce Key Binding. When doing so, that entity may remove Disclosures such that the receiver learns only a subset of the claims contained in the original SD-JWT.</t> <t>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.</t> <t>In somescenariosscenarios, this behavior could bedesirable, butdesirable; if it is not, Issuers need to support and Verifiers need to enforce Key Binding.</t> </section> <section anchor="integrity-of-sd-jwts-and-sd-jwt-kbs"><name>Integrity of SD-JWTs and SD-JWT+KBs</name> <t>With an SD-JWT, the Issuer-signed JWT isintegrity-protectedintegrity protected by the Issuer's signature, and the values of the Disclosures areintegrity-protectedintegrity protected by the digests included therein. The specific set of Disclosures, however, is notintegrity-protected;integrity protected; the SD-JWT can be modified by adding or removing Disclosures and still be valid.</t> <t>With an SD-JWT+KB, the set of selected Disclosures isintegrity-protected.integrity protected. The signature in the Key Binding JWT covers a specific SD-JWT, with a specific Issuer-signed JWT and a specific set of Disclosures. Thus, the signature on the Key Binding JWT, in addition to proving Key Binding, also assures the authenticity and integrity of the set of Disclosures the Holder disclosed. The set of Disclosures in an SD-JWT+KB is the set that the Holder intended to send; no intermediate party has added, removed, or modified the list of Disclosures.</t> </section> <section anchor="explicit_typing"><name>Explicit Typing</name> <t><xref target="RFC8725" sectionFormat="of" section="3.11"/> describes the use of explicit typing as one mechanism to prevent confusion attacks (described in <xref target="RFC8725" sectionFormat="of" section="2.8"/>) in which one kind of JWT is mistaken for another. SD-JWTs are also potentially subject to such confusion attacks, so in the absence of other techniques, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that application profiles of SD-JWT specify an explicit type by including the <tt>typ</tt> header parameter when the SD-JWT is issued, andforthat Verifierstocheck this value.</t> <t>When explicit typing using the <tt>typ</tt> header is employed for an SD-JWT, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> 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 <tt>typ</tt> inSection 4.1.9 of<xreftarget="RFC7515"/>target="RFC7515" section="4.1.9"/> recommends that the "application/" prefix be omitted, so "example+sd-jwt" would be the value of the <tt>typ</tt> header parameter.</t> <t>Use of the <tt>cty</tt> content type header parameter to indicate the content type of the SD-JWT payload can also be used to distinguish different types of JSONobjects,objects or different kinds of JWT Claim Sets.</t> </section> <section anchor="key-pair-generation-and-lifecycle-management"><name>Key Pair Generation and Lifecycle Management</name> <t>Implementations of SD-JWT rely on asymmetric cryptographic keys and must therefore ensure that key pair generation, handling, storage, and lifecycle management are performed securely.</t> <t>While the specific mechanisms for secure key management are out of scope for this document, implementers should follow established best practices, such as those outlined in NIST SP 800-57 Part 1 <xref target="NIST.SP.800-57pt1r5"/>. This includes:</t><ul spacing="compact"><ul> <li>Secure Generation: Using cryptographically secure methods and random number generators.</li> <li>Secure Storage: Protecting private keys from unauthorized access.</li> <li>Lifecycle Management: Ensuring secure key rotation, revocation, and disposal as needed.</li> </ul> <t>Appropriate key management is essential, as any compromise can lead to unauthorized disclosure or forgery of SD-JWTs.</t> </section> </section> <section anchor="privacy_considerations"><name>Privacy Considerations</name> <section anchor="unlinkability"><name>Unlinkability</name> <t>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:</t> <ulspacing="compact">spacing="normal"> <li>Cooperating Verifiers might want to track users across services to build advertising profiles.</li> <li>Issuers might want to track where users present their credentials to enable surveillance.</li> <li>After a data breach at multiple Verifiers, publicly available information might allow linking identifiable information presented to Verifier A with originally anonymous information presented to Verifier B, therefore revealing the identities of users of Verifier B.</li> </ul> <t>The following types of unlinkability are discussed below:</t> <ulspacing="compact">spacing="normal"> <li>Presentation Unlinkability: A Verifier should not be able to link two presentations of the same credential.</li> <li>Verifier/Verifier Unlinkability: The presentations made to two different Verifiers should not reveal that the same credential was presented (e.g., if the two Verifiers collude, or if they are forced by a third party to reveal the presentations made to them, or data leaks from one Verifier to the other).</li> <li>Issuer/Verifier Unlinkability (Honest Verifier): An Issuer of a credential should not be able to know that a user presented this credential unless the Verifier is sharing presentation data with the Issuer accidentally, deliberately, or because it is forced to do so.</li> <li>Issuer/Verifier Unlinkability (Careless/Colluding/Compromised/Coerced Verifier):An>An Issuer of a credential should under no circumstances be able to tell that a user presented this credential to a certain Verifier. Inparticularparticular, this includes cases when the Verifier accidentally or deliberately shares presentation data with the Issuer or is forced to do so.</li> </ul> <t>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.</t> <t>Issuer/Verifier unlinkability with a careless, colluding, compromised, or coerced Verifier cannot be achieved insalted-hash basedsalted 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. To reduce the risk of revealing the data later on, <xref target="data_storage"/> defines requirements to reduce the amount of data stored.</t> <t>In considering Issuer/Verifier unlinkability, it is important to note the potential for an asymmetric power dynamic between Issuers and Verifiers. This dynamic can compel an otherwisehonestHonest Verifier into collusion. For example, a governmental Issuer might have the authority to mandate that a Verifier report back information about the credentials presented to it. Legal requirements could further enforce this, explicitly undermining Issuer/Verifier unlinkability. Similarly, a large service provider issuing credentials might implicitly pressure Verifiers into collusion by incentivizing participation in their larger operating environment. Deployers of SD-JWT must be aware of these potential power dynamics, mitigate them as much as possible, and/or make the risks transparent to the user.</t> <t>Contrary to that, Issuer/Verifier unlinkability with anhonestHonest 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 need to be executed in a manner that preserves privacy and does not disclose details about the credential to the Issuer (the mechanism described in <xref target="I-D.ietf-oauth-status-list"/> is an example of an approachwiththat discloses minimal informationdisclosuretowards the Issuer). It is important to note that the timing of such requests could potentially serve as aside-channel.</t>side channel.</t> <t>Verifier/Verifier unlinkability and presentation unlinkability 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 saltsMUST<bcp14>MUST</bcp14> 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 <tt>iat</tt>, <tt>exp</tt>, and <tt>nbf</tt>,MUST<bcp14>MUST</bcp14> either be randomized within a time period considered appropriate (e.g., randomize <tt>iat</tt> within the last 24 hours and calculate <tt>exp</tt> accordingly) or rounded (e.g., rounded down to the beginning of the day).</t> <t>SD-JWT only conceals the value of claims that are not revealed. It does not meet the security properties for anonymous credentials <xref target="CL01"/>. In particular, colluding Verifiers and Issuers can know when they have seen the same credential no matter what fields have been disclosed, even when none have been disclosed. This behavior may not align with what users naturally anticipate or are guided to expect fromuser interfaceuser-interface interactions, potentially causing them to make decisions they might not otherwise make. Workarounds such as batch issuance, as described above, help with keeping Verifiers from linking different presentations, but cannot work for Issuer/Verifier unlinkability. This issue applies to all salted hash-based approaches, including mDL/mDoc <xref target="ISO.18013-5"/> and SD-CWT <xref target="I-D.ietf-spice-sd-cwt"/>.</t> </section> <section anchor="data_storage"><name>Storage of User Data</name> <t>Wherever 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 <xref target="OpenID.Core"/>, 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.</t> <t>Not surprisingly, a leak of such data risks revealing private data of users to third parties. Signed user data, the authenticity of which can be easily verified by third parties, further exacerbates the risk. As discussed in <xref target="key_binding_security"/>, 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.</t> <t>Due to these risks, and the risks described in <xref target="unlinkability"/>, systems implementing SD-JWTSHOULD<bcp14>SHOULD</bcp14> be designed to minimize the amount of data that is stored. All involved partiesSHOULD NOT<bcp14>SHOULD NOT</bcp14> store SD-JWTs longer than strictlyneeded,necessary, including in log files.</t> <t>After Issuance, IssuersSHOULD NOT<bcp14>SHOULD NOT</bcp14> store the Issuer-signed JWT or the respective Disclosures.</t> <t>HoldersSHOULD<bcp14>SHOULD</bcp14> 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 user devices,SHOULD<bcp14>SHOULD</bcp14> be preferred for user credentials over centralized storage. Expired SD-JWTsSHOULD<bcp14>SHOULD</bcp14> be deleted as soon as possible.</t> <t>After Verification, VerifiersSHOULD NOT<bcp14>SHOULD NOT</bcp14> store the Issuer-signed JWT or the respective Disclosures. It may be sufficient to store the result of the verification and any user data that is needed for the application.</t> <t>Exceptions from the rules above can be made if there are strong requirements to do so (e.g., functional requirements or legal audit requirements), secure storage can be ensured, and the privacy impact has been assessed.</t> </section> <section anchor="confidentiality-during-transport"><name>ConfidentialityduringDuring Transport</name> <t>If an SD-JWT or SD-JWT+KB is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the user's personal data or correlate the information with previous uses.</t> <t>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.</t> <t>This specification therefore considers the confidentiality of the data to be provided by the transport protocol and does not specify any encryption mechanism.</t> <t>ImplementersMUST<bcp14>MUST</bcp14> ensure that the transport protocol provides confidentiality if the privacy of user data or correlation attacks by passive observers are a concern.</t> <t>To encrypt an SD-JWT or SD-JWT+KB during transit over potentially insecure or leakage-prone channels, implementersMAY<bcp14>MAY</bcp14> use JSON Web Encryption (JWE) <xref target="RFC7516"/>, encapsulating the SD-JWT or SD-JWT+KB as the plaintext payload of the JWE. Especially, when an SD-JWT is transmitted via a URL and information may be stored/cached in the browser or end up in web server logs, the SD-JWTSHOULD<bcp14>SHOULD</bcp14> be encrypted using JWE.</t> </section> <section anchor="decoy_digests_privacy"><name>Decoy Digests</name> <t>The use of decoy digests isRECOMMENDED<bcp14>RECOMMENDED</bcp14> when the number of claims (or the existence of particular claims) can be aside-channelside channel disclosing information about otherwise undisclosed claims. In particular, if a claim in an SD-JWT is present only if a certain condition is met (e.g., a membership number is only contained if the user is a member of a group), the IssuerSHOULD<bcp14>SHOULD</bcp14> add decoy digests when the condition is not met.</t> <t>Decoy digests increase the size of the SD-JWT. The number of decoy digests (or whether to use them at all) is a trade-off between the size of the SD-JWT and the privacy of the user's data.</t> </section> <section anchor="issuer-identifier"><name>Issuer Identifier</name> <t>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.</t> <t>For example, if a cancer research institute only issued SD-JWTs with cancer registry information, it is possible to deduce that the Holder owning its SD-JWT is a cancer patient.</t> <t>Moreover, theissuerIssuer identifier alone may reveal information about the user.</t> <t>For example, when a military organization or a drug rehabilitation center issues a vaccine credential,verifiersVerifiers can deduce that the holder is a military member or may have a substance use disorder.</t> <t>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.</t> </section> </section> <sectionanchor="Acknowledgements"><name>Acknowledgements</name> <t>We would like to thank Alen Horvat, Alex Hodder, Anders Rundgren, Arjan Geluk, Chad Parry, Christian Bormann, Christian Paquin, Dale Bowie, Dan Moore, David Bakker, David Waite, Deb Cooley, Dick Hardt, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Martin Thomson, Matthew Miller, Michael Fraser, Michael B. Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Rohan Mahy, Roman Danyliw, Ryosuke Abe, Sami Rosendahl, Shawn Emery, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, Watson Ladd, and Yaron Sheffer for their contributions (some of which were substantial) to this draft and to the initial set of implementations.</t> <t>The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.</t> </section> <sectionanchor="iana_considerations"><name>IANA Considerations</name> <section anchor="json-web-token-claims-registration"><name>JSON Web Token Claims Registration</name><t>This specification requests registration of<t>IANA has registered the following Claims in theIANA"JSON Web Token Claims" registry <xreftarget="IANA.JWT"/>target="JWT.Claims"/> established by <xref target="RFC7519"/>.</t><ul spacing="compact"> <li>Claim Name: <tt>_sd</tt></li> <li>Claim Description: Digests<dl spacing="compact" newline="false"> <dt>Claim Name:</dt><dd><tt>_sd</tt></dd> <dt>Claim Description:</dt><dd>Digests of Disclosures for objectproperties</li> <li>Change Controller: IETF</li> <li>Specification Document(s): [[properties</dd> <dt>Change Controller:</dt><dd>IETF</dd> <dt>Specification Document(s):</dt><dd> <xref target="embedding_object_properties"/> ofthis specification ]]</li> </ul> <t><br/> </t> <ul spacing="compact"> <li>Claim Name: <tt>...</tt></li> <li>Claim Description: DigestRFC 9901</dd> </dl> <dl spacing="compact" newline="false"> <dt>Claim Name:</dt><dd><tt>...</tt></dd> <dt>Claim Description:</dt><dd>Digest of the Disclosure for an arrayelement</li> <li>Change Controller: IETF</li> <li>Specification Document(s): [[ <xrefelement</dd> <dt>Change Controller:</dt><dd>IETF</dd> <dt>Specification Document(s):</dt><dd><xref target="embedding_array_elements"/> ofthis specification ]]</li> </ul> <t><br/> </t> <ul spacing="compact"> <li>Claim Name: <tt>_sd_alg</tt></li> <li>Claim Description: HashRFC 9901</dd> </dl> <dl spacing="compact" newline="false"> <dt>Claim Name:</dt><dd><tt>_sd_alg</tt></dd> <dt>Claim Description:</dt><dd>Hash algorithm used to generate Disclosure digests and digest overpresentation</li> <li>Change Controller: IETF</li> <li>Specification Document(s): [[ <xrefpresentation</dd> <dt>Change Controller:</dt><dd>IETF</dd> <dt>Specification Document(s):</dt><dd><xref target="hash_function_claim"/> ofthis specification ]]</li> </ul> <t><br/> </t> <ul spacing="compact"> <li>Claim Name: <tt>sd_hash</tt></li> <li>Claim Description: DigestRFC 9901</dd> </dl> <dl spacing="compact" newline="false"> <dt>Claim Name:</dt><dd><tt>sd_hash</tt></dd> <dt>Claim Description:</dt><dd>Digest of the SD-JWT to which the KB-JWT istied</li> <li>Change Controller: IETF</li> <li>Specification Document(s): [[ <xreftied</dd> <dt>Change Controller:</dt><dd>IETF</dd> <dt>Specification Document(s):</dt><dd><xref target="kb-jwt"/> ofthis specification ]]</li> </ul>RFC 9901</dd> </dl> </section> <section anchor="media-type-registration"><name>Media TypeRegistration</name> <t>This section requests registrationRegistrations</name> <!-- [rfced] We updated the format of the media type registrations to better align with the format used by IANA. We also created subsections for each of the registrations. Please review Section 11.2 carefully and let us know if a) any changes are desired for the section titles or b) if you object to the updated format. --> <t>IANA has registered the following media types <xref target="RFC2046"/> in the "Media Types" registry <xreftarget="IANA.MediaTypes"/>target="MediaTypes"/> in the manner described in <xref target="RFC6838"/>.</t><blockquote><t>Note:<aside><t>Note: For the media type value used in the <tt>typ</tt> header in the Issuer-signed JWT itself, see <xref target="explicit_typing"/>.</t></blockquote><t>To</aside> <section anchor="sj-jwt-content"><name>SD-JWT Content</name> <t>To indicate that the content is an SD-JWT:</t><ul spacing="compact"> <li>Type name: application</li> <li>Subtype name: sd-jwt</li> <li>Required parameters: n/a</li> <li>Optional parameters: n/a</li> <li>Encoding considerations: binary;<dl spacing="normal"> <dt>Type name:</dt><dd>application</dd> <dt>Subtype name:</dt><dd>sd-jwt</dd> <dt>Required parameters:</dt><dd>n/a</dd> <dt>Optional parameters:</dt><dd>n/a</dd> <dt>Encoding considerations:</dt><dd>binary; application/sd-jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') and tilde ('~')characters.</li> <li>Security considerations: Seecharacters.</dd> <dt>Security considerations:</dt><dd>See the Security Considerationssectionsections of[[ this specification ]],RFC 9901, <xref target="RFC7519"/>, and <xreftarget="RFC8725"/>.</li> <li>Interoperability considerations: n/a</li> <li>Published specification: [[ this specification ]]</li> <li>Applicationstarget="RFC8725"/>.</dd> <dt>Interoperability considerations:</dt><dd>n/a</dd> <dt>Published specification:</dt><dd>RFC 9901</dd> <dt>Applications that use this mediatype: Applicationstype:</dt><dd>Applications requiring selective disclosure ofintegrity protected content.</li> <li>Fragmentintegrity-protected content.</dd> <dt>Fragment identifierconsiderations: n/a</li> <li><t>Additional information:</t> <ulconsiderations:</dt><dd>n/a</dd> <dt>Additional information:</dt><dd> <t><br/></t> <dl spacing="compact"><li>Magic number(s): n/a</li> <li>File extension(s): n/a</li> <li>Macintosh<dt>Magic number(s):</dt><dd>n/a</dd> <dt>File extension(s):</dt><dd>n/a</dd> <dt>Macintosh file typecode(s): n/a</li> </ul></li> <li>Personcode(s):</dt><dd>n/a</dd> </dl> </dd> <dt>Person & email address to contact for furtherinformation: Danielinformation:</dt><dd>Daniel Fett,mail@danielfett.de</li> <li>Intended usage: COMMON</li> <li>Restrictionsmail@danielfett.de</dd> <dt>Intended usage:</dt><dd>COMMON</dd> <dt>Restrictions onusage: none</li> <li>Author: Danielusage:</dt><dd>none</dd> <dt>Author:</dt><dd>Daniel Fett,mail@danielfett.de</li> <li>Change Controller: IETF</li> <li>Provisional registration? No</li> </ul> <t><br/> Tomail@danielfett.de</dd> <dt>Change Controller:</dt><dd>IETF</dd> </dl> </section> <section anchor="jws-json-content"><name>JWS JSON Serialized SD-JWT Content</name> <t>To indicate that the content is a JWS JSON serialized SD-JWT:</t><ul spacing="compact"> <li>Type name: application</li> <li>Subtype name: sd-jwt+json</li> <li>Required parameters: n/a</li> <li>Optional parameters: n/a</li> <li>Encoding considerations: binary;<dl spacing="normal"> <dt>Type name:</dt><dd>application</dd> <dt>Subtype name:</dt><dd>sd-jwt+json</dd> <dt>Required parameters:</dt><dd>n/a</dd> <dt>Optional parameters:</dt><dd>n/a</dd> <dt>Encoding considerations:</dt><dd>binary; application/sd-jwt+json values are represented as a JSONObject.</li> <li>Security considerations: SeeObject.</dd> <dt>Security considerations:</dt><dd>See the Security Considerationssectionsections of[[ this specification ]],RFC 9901 and <xreftarget="RFC7515"/>.</li> <li>Interoperability considerations: n/a</li> <li>Published specification: [[ this specification ]]</li> <li>Applicationstarget="RFC7515"/>.</dd> <dt>Interoperability considerations:</dt><dd>n/a</dd> <dt>Published specification:</dt><dd>RFC 9901</dd> <dt>Applications that use this mediatype: Applicationstype:</dt><dd>Applications requiring selective disclosure of content protected by ETSI JAdES compliantsignatures.</li> <li>Fragmentsignatures.</dd> <dt>Fragment identifierconsiderations: n/a</li> <li><t>Additional information:</t> <ulconsiderations:</dt><dd>n/a</dd> <dt>Additional information:</dt><dd> <t><br/></t> <dl spacing="compact"><li>Magic number(s): n/a</li> <li>File extension(s): n/a</li> <li>Macintosh<dt>Magic number(s):</dt><dd>n/a</dd> <dt>File extension(s):</dt><dd>n/a</dd> <dt>Macintosh file typecode(s): n/a</li> </ul></li> <li>Personcode(s):</dt><dd>n/a</dd> </dl></dd> <dt>Person & email address to contact for furtherinformation: Danielinformation:</dt><dd>Daniel Fett,mail@danielfett.de</li> <li>Intended usage: COMMON</li> <li>Restrictionsmail@danielfett.de</dd> <dt>Intended usage:</dt><dd>COMMON</dd> <dt>Restrictions onusage: none</li> <li>Author: Danielusage:</dt><dd>none</dd> <dt>Author:</dt><dd>Daniel Fett,mail@danielfett.de</li> <li>Change Controller: IETF</li> <li>Provisional registration? No</li> </ul> <t><br/> Tomail@danielfett.de</dd> <dt>Change Controller:</dt><dd>IETF</dd> </dl> </section> <section anchor="kb-jwt-content"><name>Key Binding JWT Content</name> <t>To indicate that the content is a Key Binding JWT:</t><ul spacing="compact"> <li>Type name: application</li> <li>Subtype name: kb+jwt</li> <li>Required parameters: n/a</li> <li>Optional parameters: n/a</li> <li>Encoding considerations: binary;<dl spacing="normal"> <dt>Type name:</dt><dd>application</dd> <dt>Subtype name:</dt><dd>kb+jwt</dd> <dt>Required parameters:</dt><dd>n/a</dd> <dt>Optional parameters:</dt><dd>n/a</dd> <dt>Encoding considerations:</dt><dd>binary; A Key Binding JWT is a JWT; JWT values are encoded as a series of base64url-encoded values separated by period ('.')characters.</li> <li>Security considerations: Seecharacters.</dd> <dt>Security considerations:</dt><dd>See the Security Considerationssectionsections of[[ this specification ]],RFC 9901, <xref target="RFC7519"/>, and <xreftarget="RFC8725"/>.</li> <li>Interoperability considerations: n/a</li> <li>Published specification: [[ this specification ]]</li> <li>Applicationstarget="RFC8725"/>.</dd> <dt>Interoperability considerations:</dt><dd>n/a</dd> <dt>Published specification:</dt><dd>RFC 9901</dd> <dt>Applications that use this mediatype: Applicationstype:</dt><dd>Applications utilizing aJWT based proof of possession mechanism.</li> <li>FragmentJWT-based proof-of-possession mechanism.</dd> <dt>Fragment identifierconsiderations: n/a</li> <li><t>Additional information:</t> <ulconsiderations:</dt><dd>n/a</dd> <dt>Additional information:</dt><dd> <t><br/></t> <dl spacing="compact"><li>Magic number(s): n/a</li> <li>File extension(s): n/a</li> <li>Macintosh<dt>Magic number(s):</dt><dd>n/a</dd> <dt>File extension(s):</dt><dd>n/a</dd> <dt>Macintosh file typecode(s): n/a</li> </ul></li> <li>Personcode(s):</dt><dd>n/a</dd> </dl></dd> <dt>Person & email address to contact for furtherinformation: Danielinformation:</dt><dd>Daniel Fett,mail@danielfett.de</li> <li>Intended usage: COMMON</li> <li>Restrictionsmail@danielfett.de</dd> <dt>Intended usage:</dt><dd>COMMON</dd> <dt>Restrictions onusage: none</li> <li>Author: Danielusage:</dt><dd>none</dd> <dt>Author:</dt><dd>Daniel Fett,mail@danielfett.de</li> <li>Change Controller: IETF</li> <li>Provisional registration? No</li> </ul>mail@danielfett.de</dd> <dt>Change Controller:</dt><dd>IETF</dd> </dl> </section> </section> <section anchor="structured-syntax-suffix-registration"><name>Structured SyntaxSuffixSuffixes Registration</name><t>This section requests registration of the<t>IANA has registered "+sd-jwt"structured syntax suffixin the "Structured SyntaxSuffix"Suffixes" registry <xreftarget="IANA.StructuredSuffix"/>target="StructuredSuffix"/> in the manner described in <xref target="RFC6838"/>, which can be used to indicate that the media type is encoded as an SD-JWT.</t><ul<dl spacing="compact"><li>Name: SD-JWT</li> <li>+suffix: +sd-jwt</li> <li>References: [[ this specification ]]</li> <li>Encoding considerations: binary;<dt>Name:</dt><dd>SD-JWT</dd> <dt>+suffix:</dt><dd>+sd-jwt</dd> <dt>References:</dt><dd>RFC 9901</dd> <dt>Encoding considerations:</dt><dd>binary; SD-JWT values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') or tilde ('~')characters.</li> <li>Interoperability considerations: n/a</li> <li>Fragmentcharacters.</dd> <dt>Interoperability considerations:</dt><dd>n/a</dd> <dt>Fragment identifierconsiderations: n/a</li> <li>Security considerations: Seeconsiderations:</dt><dd>n/a</dd> <dt>Security considerations:</dt><dd>See the Security Considerationssectionsections of[[ this specification ]],RFC 9901, <xref target="RFC7519"/>, and <xreftarget="RFC8725"/>.</li> <li>Contact: Danieltarget="RFC8725"/>.</dd> <dt>Contact:</dt><dd>Daniel Fett,mail@danielfett.de</li> <li>Author/Change controller: IETF</li> </ul>mail@danielfett.de</dd> <dt>Author/Change controller:</dt><dd>IETF</dd> </dl> </section> </section> </middle> <back> <displayreference target="I-D.ietf-oauth-sd-jwt-vc" to="SD-JWT-VC"/> <displayreference target="I-D.ietf-oauth-status-list" to="TSL"/> <displayreference target="I-D.ietf-spice-sd-cwt" to="SD-CWT"/> <references><name>References</name> <references><name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <!-- [rfced] References: Please note that we moved the listing for RFC 5234 to the Normative References section, per the first bullet under "Formal languages" on <https://datatracker.ietf.org/doc/statement-iesg-guidelines-for-the-use-of-formal-languages-in-ietf-specifications-20011001/>. Please let us know any concerns. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7516.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7800.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml"/> </references> <references><name>Informative References</name> <reference anchor="CL01" target="https://eprint.iacr.org/2001/019.pdf"> <front> <title>An Efficient System for Non-Transferable Anonymous Credentials with Optional Anonymity Revocation</title> <author fullname="Jan Camenisch" initials="J." surname="Camenisch"> <organization>IBM Research</organization> </author> <author fullname="Anna Lysyanskaya" initials="A." surname="Lysyanskaya"> <organization>MIT</organization> </author> <date year="2001"/> </front><seriesInfo name="Proceedings of the International Conference on the Theory and Application of Cryptographic Techniques (EUROCRYPT)" value="2001"/><refcontent>Cryptology ePrint Archive, Paper 2001/019</refcontent> </reference> <reference anchor="EUDIW.ARF" target="https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework"> <front> <title>The European Digital Identity Wallet Architecture and Reference Framework</title><author fullname="European Commission"/><author> <organization>European Commission</organization> </author> </front> </reference> <!-- draft-ietf-oauth-sd-jwt-vc (I-D Exists) --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-sd-jwt-vc.xml"/> <!-- draft-ietf-oauth-status-list (AD Evaluation::Revised I-D Needed) --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-status-list.xml"/> <!-- draft-ietf-spice-sd-cwt (I-D Exists) --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spice-sd-cwt.xml"/> <referenceanchor="IANA.Hash.Algorithms" target="https://www.iana.org/assignments/named-information/named-information.xhtml">anchor="Hash.Algs" target="https://www.iana.org/assignments/named-information"> <front> <title>Named Information HashAlgorithm</title> <author fullname="IANA"/>Algorithm Registry</title> <author> <organization>IANA</organization> </author> </front> </reference> <referenceanchor="IANA.JWS.Algorithms" target="https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms">anchor="JWS.Algs" target="https://www.iana.org/assignments/jose"> <front> <title>JSON Web Signature and Encryption Algorithms</title><author fullname="IANA"/><author> <organization>IANA</organization> </author> </front> </reference> <referenceanchor="IANA.JWT"anchor="JWT.Claims" target="https://www.iana.org/assignments/jwt"> <front> <title>JSON Web Token Claims</title> <author> <organization>IANA</organization> </author> </front> </reference> <referenceanchor="IANA.MediaTypes" target="https://www.iana.org/assignments/media-types/media-types.xhtml">anchor="MediaTypes" target="https://www.iana.org/assignments/media-types"> <front> <title>Media Types</title><author fullname="IANA"/><author> <organization>IANA</organization> </author> </front> </reference> <referenceanchor="IANA.StructuredSuffix" target="https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml">anchor="StructuredSuffix" target="https://www.iana.org/assignments/media-type-structured-suffix"> <front> <title>Structured SyntaxSuffixs</title> <author fullname="IANA"/>Suffixes</title> <author> <organization>IANA</organization> </author> </front> </reference> <reference anchor="ISO.18013-5" target="https://www.iso.org/standard/69084.html"> <front><title>ISO/IEC 18013-5:2021 Personal<title>Personal identification—- ISO-compliant driving license — Part 5: Mobile driving license (mDL) application</title> <author><organization> ISO/IEC JTC 1/SC 17 Cards and security devices for personal identification</organization><organization>ISO/IEC</organization> </author> <date month="September" year="2021"/> </front> <seriesInfo name="ISO/IEC" value="18013-5:2021"/> </reference> <reference anchor="NIST.SP.800-57pt1r5" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf"> <front> <title>Recommendation forkey management:partKey Management: Part 1 -general</title>General</title> <author fullname="Elaine Barker" surname="Barker"> <organization>Information Technology Laboratory</organization> </author><author> <organization abbrev="NIST">National Institute of Standards and Technology</organization> <address> <postal> <city>Gaithersburg</city> <country>US</country> </postal> </address> </author><date year="2020" month="May"/> </front> <seriesInfo name="NISTSpecial Publications (General)"SP" value="800-57pt1r5"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/> </reference> <reference anchor="OIDC.IDA" target="https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html"> <front> <title>OpenID Connect for Identity Assurance 1.0</title> <author fullname="Torsten Lodderstedt" initials="T." surname="Lodderstedt"> <organization>yes.com</organization> </author> <author fullname="Daniel Fett" initials="D." surname="Fett"> <organization>yes.com</organization> </author> <author fullname="Mark Haine" initials="M." surname="Haine"> <organization>Considrd.Consulting Ltd</organization> </author> <author fullname="Alberto Pulido" initials="A." surname="Pulido"> <organization>Santander</organization> </author> <author fullname="Kai Lehmann" initials="K." surname="Lehmann"> <organization>1&1 Mail & Media Development & Technology GmbH</organization> </author> <author fullname="Kosuke Koiwai" initials="K." surname="Koiwai"> <organization>KDDI Corporation</organization> </author> <date year="2024"month="Jul" day="24"/>month="Oct" day="1"/> </front> </reference> <reference anchor="OpenID.Core" target="https://openid.net/specs/openid-connect-core-1_0.html"> <front> <title>OpenID Connect Core 1.0 incorporating errata set 2</title> <author fullname="Nat Sakimura" initials="N." surname="Sakimura"> <organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization> </author> <author fullname="John Bradley" initials="J." surname="Bradley"> <organization abbrev="Yubico (was at Ping Identity)">Yubico</organization> </author> <author fullname="Mike Jones" initials="M." surname="Jones"> <organization abbrev="Self-Issued Consulting (was at Microsoft)">Self-Issued Consulting</organization> </author> <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros"> <organization>Google</organization> </author> <author fullname="Chuck Mortimore" initials="C." surname="Mortimore"> <organization abbrev="Disney (was at Salesforce)">Disney</organization> </author> <date year="2023" month="Dec" day="15"/> </front> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> <xi:includehref="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:includehref="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7517.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8785.xml"/> <reference anchor="VC_DATA_v2.0" target="https://www.w3.org/TR/vc-data-model-2.0/"> <front> <title>Verifiable Credentials Data Model 2.0</title> <author fullname="ManuSporny">Sporny" role="editor"> <organization>Digital Bazaar</organization> </author> <author fullname="TedThiboeau Jr">Thiboeau" role="editor"> <organization>OpenLink Software</organization> </author> <author fullname="Michael B.Jones">Jones" role="editor"> <organization>Invited Expert</organization> </author> <author fullname="GabeCohen">Cohen" role="editor"> <organization>Block</organization> </author> <author fullname="IvanHerman">Herman" role="editor"> <organization>W3C</organization> </author> <date year="2025" month="May"/> </front> <refcontent>W3C Recommendation</refcontent> </reference> </references> </references> <section anchor="additional-examples"><name>Additional Examples</name> <t>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.</t> <t>Line breaks have been added for readability.</t> <section anchor="example-simple_structured"><name>Simple Structured SD-JWT</name> <!-- [rfced] We updated this text for clarity. Please review and let us know if any updates are needed. Original: In this example, in contrast to Section 5, the Issuer decided to create a structured object for the address claim, allowing to separately disclose individual members of the claim. Current: In this example, in contrast to Section 5, the Issuer decided to create a structured object for the address claim, allowing individual members of the claim to be disclosed separately. --> <t>In this example, in contrast to <xref target="main-example"/>, the Issuer decided to create a structured object for the <tt>address</tt> claim, allowingto separately discloseindividual members of theclaim.</t>claim to be disclosed separately. </t> <t>The following data about the user comprises the input JWT Claims Set used by the Issuer:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "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" } ]]> </sourcecode> <t>The Issuer also decided to add decoy digests to prevent the Verifier from deducing the true number of claims.</t> <t>The following payload is used for the SD-JWT:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "_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" } ]]> </sourcecode> <t>The digests in the SD-JWT payload reference the following Disclosures:</t> <t><strong>Claim <tt>sub</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g</tt></li> <li>Disclosure:<br/> <tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1i</tt><br/> <tt>NTg5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ</tt></li> <li>Contents: <tt>["2GLC42sKQveCfGfryNRN9w", "sub",</tt><br/> <tt>"6c5c0a49-b589-431d-bae7-219122a9ec2c"]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g</tt></t></li> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1iNTg5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "sub", "6c5c0a49-b589-431d-bae7-219122a9ec2c"]</tt></t></li> </ul> <t><strong>Claim <tt>given_name</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q</tt></li> <li>Disclosure:<br/> <tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1</tt><br/> <tt>OTJhXHU5MGNlIl0</tt></li> <li>Contents: <tt>["eluV5Og3gSNII8EYnsxA_A",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1OTJhXHU5MGNlIl0</tt></t></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "given_name","\u592a\u90ce"]</tt></li>"\u592a\u90ce"]</tt></t></li> </ul> <t><strong>Claim <tt>family_name</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU</tt></li> <li>Disclosure:<br/> <tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1</tt><br/> <tt>NWM3MVx1NzUzMCJd</tt></li> <li>Contents: <tt>["6Ij7tM-a5iVPGboS5tmvVA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1NWM3MVx1NzUzMCJd</tt></t></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "family_name","\u5c71\u7530"]</tt></li>"\u5c71\u7530"]</tt></t></li> </ul> <t><strong>Claim <tt>email</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE</tt></li> <li>Disclosure:<br/> <tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3Vh</tt><br/> <tt>bCBlbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd</tt></li> <li>Contents: <tt>["eI8ZWm9QnKPpNPeNenHdhQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3VhbCBlbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd</tt></t></li> <li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusualemail</tt><br/> <tt>address\"@example.jp"]</tt></li>email address\"@example.jp"]</tt></t></li> </ul> <t><strong>Claim <tt>phone_number</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U</tt></li> <li>Disclosure:<br/> <tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIr</tt><br/> <tt>ODEtODAtMTIzNC01Njc4Il0</tt></li> <li>Contents: <tt>["Qg_O64zqAxe412a108iroA", "phone_number",</tt><br/> <tt>"+81-80-1234-5678"]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIrODEtODAtMTIzNC01Njc4Il0</tt></t></li> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "phone_number", "+81-80-1234-5678"]</tt></t></li> </ul> <t><strong>Claim <tt>street_address</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E</tt></li> <li>Disclosure:<br/> <tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwg</tt><br/> <tt>Ilx1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1</tt><br/> <tt>NTcxMlx1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd</tt></li> <li>Contents: <tt>["AJx-095VPrpTtN4QMOqROA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwgIlx1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1NTcxMlx1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd</tt></t></li> <li><t>Contents:</t><t><tt>["AJx-095VPrpTtN4QMOqROA", "street_address","\u6771\u4eac\u</tt><br/> <tt>90fd\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u</tt><br/> <tt>2212\uff18"]</tt></li>"\u6771\u4eac\u90fd\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u2212\uff18"]</tt></t></li> </ul> <t><strong>Claim <tt>locality</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA</tt></li> <li>Disclosure:<br/> <tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3</tt><br/> <tt>MVx1NGVhY1x1OTBmZCJd</tt></li> <li>Contents: <tt>["Pc33JM2LchcU_lHggv_ufQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3MVx1NGVhY1x1OTBmZCJd</tt></t></li> <li><t>Contents:</t><t><tt>["Pc33JM2LchcU_lHggv_ufQ", "locality","\u6771\u4eac\u90fd"]</tt></li>"\u6771\u4eac\u90fd"]</tt></t></li> </ul> <t><strong>Claim <tt>region</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k</tt></li> <li>Disclosure:<br/> <tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZc</tt><br/> <tt>dTUzM2EiXQ</tt></li> <li>Contents: <tt>["G02NSrQfjFXQ7Io09syajA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZcdTUzM2EiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["G02NSrQfjFXQ7Io09syajA", "region","\u6e2f\u533a"]</tt></li>"\u6e2f\u533a"]</tt></t></li> </ul> <t><strong>Claim <tt>country</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4</tt></li> <li>Disclosure:<br/> <tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ</tt></li> <li>Contents: <tt>["lklxF5jMYlGTPUovMNIvCA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["lklxF5jMYlGTPUovMNIvCA", "country","JP"]</tt></li>"JP"]</tt></t></li> </ul> <t><strong>Claim <tt>birthdate</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY</tt></li> <li>Disclosure:<br/> <tt>WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQw</tt><br/> <tt>LTAxLTAxIl0</tt></li> <li>Contents: <tt>["yytVbdAPGcgl2rI4C9GSog",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0</tt></t></li> <li><t>Contents:</t><t><tt>["yytVbdAPGcgl2rI4C9GSog", "birthdate","1940-01-01"]</tt></li>"1940-01-01"]</tt></t></li> </ul> <t>The following decoy digests are added:</t> <ulspacing="compact">spacing="normal"> <li><tt>AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg</tt></li> <li><tt>cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ</tt></li> <li><tt>glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4</tt></li> <li><tt>b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek</tt></li> <li><tt>fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs</tt></li> <li><tt>Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE</tt></li> </ul> <t>The following is a presentation of the SD-JWT that discloses only <tt>region</tt> and <tt>country</tt> of the <tt>address</tt> property:</t> <sourcecodetype="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBbtype="txt"><![CDATA[ eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb IkM5aW5wNllvUmFFWFI0Mjd6WUpQN1FyazFXSF84YmR3T0FfWVVyVW5HUVUiLCAiS3Vl dDF5QWEwSElRdlluT1ZkNTloY1ZpTzlVZzZKMmtTZnFZUkJlb3d2RSIsICJNTWxkT0ZG ekIyZDB1bWxtcFRJYUdlcmhXZFVfUHBZZkx2S2hoX2ZfOWFZIiwgIlg2WkFZT0lJMnZQ TjQwVjd4RXhad1Z3ejd5Um1MTmNWd3Q1REw4Ukx2NGciLCAiWTM0em1JbzBRTExPdGRN cFhHd2pCZ0x2cjE3eUVoaFlUMEZHb2ZSLWFJRSIsICJmeUdwMFdUd3dQdjJKRFFsbjFs U2lhZW9iWnNNV0ExMGJRNTk4OS05RFRzIiwgIm9tbUZBaWNWVDhMR0hDQjB1eXd4N2ZZ dW8zTUhZS08xNWN6LVJaRVlNNVEiLCAiczBCS1lzTFd4UVFlVTh0VmxsdE03TUtzSVJU ckVJYTFQa0ptcXhCQmY1VSJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAiYWRkcmVz cyI6IHsiX3NkIjogWyI2YVVoelloWjdTSjFrVm1hZ1FBTzN1MkVUTjJDQzFhSGhlWnBL bmFGMF9FIiwgIkF6TGxGb2JrSjJ4aWF1cFJFUHlvSnotOS1OU2xkQjZDZ2pyN2ZVeW9I emciLCAiUHp6Y1Z1MHFiTXVCR1NqdWxmZXd6a2VzRDl6dXRPRXhuNUVXTndrclEtayIs ICJiMkRrdzBqY0lGOXJHZzhfUEY4WmN2bmNXN3p3Wmo1cnlCV3ZYZnJwemVrIiwgImNQ WUpISVo4VnUtZjlDQ3lWdWIyVWZnRWs4anZ2WGV6d0sxcF9KbmVlWFEiLCAiZ2xUM2hy U1U3ZlNXZ3dGNVVEWm1Xd0JUdzMyZ25VbGRJaGk4aEdWQ2FWNCIsICJydkpkNmlxNlQ1 ZWptc0JNb0d3dU5YaDlxQUFGQVRBY2k0MG9pZEVlVnNBIiwgInVOSG9XWWhYc1poVkpD TkUyRHF5LXpxdDd0NjlnSkt5NVFhRnY3R3JNWDQiXX0sICJfc2RfYWxnIjogInNoYS0y NTYifQ.EOZa2YqK8j4i7cqBDkfPcTMaFsgPwcx3aYJkFoMfvV46LxL-PPqrWsIyNukB4 x8Y2LT31eIHDc4Wg4XNzaqu4w~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2 lvbiIsICJcdTZlMmZcdTUzM2EiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImN vdW50cnkiLCAiSlAiXQ~ ]]> </sourcecode> <t>After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "iss": "https://issuer.example.com", "iat": 1683000000, "exp": 1883000000, "address": { "region": "港区", "country": "JP" } } ]]> </sourcecode> </section> <section anchor="example-complex-structured-sd-jwt"><name>Complex Structured SD-JWT</name> <t>In this example, an SD-JWT with a complex object is represented. The data structures defined in OpenID Connect for Identity Assurance <xref target="OIDC.IDA"/> are used.</t> <t>The Issuer is using the following user data as the input JWT Claims Set:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "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" } ]]> </sourcecode> <t>The following payload is used for the SD-JWT:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "_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" } ]]> </sourcecode> <t>The digests in the SD-JWT payload reference the following Disclosures:</t> <t><strong>Claim <tt>time</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw</tt></li> <li>Disclosure:<br/> <tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0y</tt><br/> <tt>M1QxODoyNVoiXQ</tt></li> <li>Contents: <tt>["2GLC42sKQveCfGfryNRN9w",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw</tt></t></li> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1QxODoyNVoiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "time","2012-04-23T18:25Z"]</tt></li>"2012-04-23T18:25Z"]</tt></t></li> </ul> <t><strong>Claim <tt>verification_process</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc</tt></li> <li>Disclosure:<br/> <tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9j</tt><br/> <tt>ZXNzIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ</tt></li> <li>Contents: <tt>["eluV5Og3gSNII8EYnsxA_A", "verification_process",</tt><br/> <tt>"f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9jZXNzIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ</tt></t></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "verification_process", "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"]</tt></t></li> </ul> <t><strong>Claim <tt>type</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk</tt></li> <li>Disclosure:<br/> <tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQi</tt><br/> <tt>XQ</tt></li> <li>Contents: <tt>["6Ij7tM-a5iVPGboS5tmvVA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "type","document"]</tt></li>"document"]</tt></t></li> </ul> <t><strong>Claim <tt>method</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ</tt></li> <li>Disclosure:<br/> <tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0</tt></li> <li>Contents: <tt>["eI8ZWm9QnKPpNPeNenHdhQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0</tt></t></li> <li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "method","pipp"]</tt></li>"pipp"]</tt></t></li> </ul> <t><strong>Claim <tt>time</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI</tt></li> <li>Disclosure:<br/> <tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0y</tt><br/> <tt>MlQxMTozMFoiXQ</tt></li> <li>Contents: <tt>["Qg_O64zqAxe412a108iroA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0yMlQxMTozMFoiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "time","2012-04-22T11:30Z"]</tt></li>"2012-04-22T11:30Z"]</tt></t></li> </ul> <t><strong>Claim <tt>document</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4</tt></li> <li>Disclosure:<br/> <tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBl</tt><br/> <tt>IjogImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1</tt><br/> <tt>cmciLCAiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0Iiwg</tt><br/> <tt>ImRhdGVfb2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4</tt><br/> <tt>cGlyeSI6ICIyMDIwLTAzLTIyIn1d</tt></li> <li>Contents: <tt>["AJx-095VPrpTtN4QMOqROA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBlIjogImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1cmciLCAiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0IiwgImRhdGVfb2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4cGlyeSI6ICIyMDIwLTAzLTIyIn1d</tt></t></li> <li><t>Contents:</t><t><tt>["AJx-095VPrpTtN4QMOqROA", "document", {"type":"idcard",</tt><br/> <tt>"issuer":"idcard", "issuer": {"name": "Stadt Augsburg", "country":"DE"},</tt><br/> <tt>"number":"DE"}, "number": "53554554", "date_of_issuance":"2010-03-23",</tt><br/> <tt>"date_of_expiry": "2020-03-22"}]</tt></li>"2010-03-23", "date_of_expiry": "2020-03-22"}]</tt></t></li> </ul> <t><strong>Array Entry</strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k</tt></li> <li>Disclosure:<br/> <tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1</tt><br/> <tt>RDdQSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhP</tt><br/> <tt>QU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdG</tt><br/> <tt>cldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldw</tt><br/> <tt>eFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d</tt></li> <li>Contents: <tt>["Pc33JM2LchcU_lHggv_ufQ", {"_sd":</tt><br/> <tt>["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI",</tt><br/> <tt>"G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk",</tt><br/> <tt>"IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4",</tt><br/> <tt>"WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDdQSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdGcldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d</tt></t></li> <li><t>Contents:</t><t><tt>["Pc33JM2LchcU_lHggv_ufQ", {"_sd": ["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI", "G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk", "IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4", "WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]</tt></t></li> </ul> <t><strong>Claim <tt>given_name</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo</tt></li> <li>Disclosure:<br/> <tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4</tt><br/> <tt>Il0</tt></li> <li>Contents: <tt>["G02NSrQfjFXQ7Io09syajA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0</tt></t></li> <li><t>Contents:</t><t><tt>["G02NSrQfjFXQ7Io09syajA", "given_name","Max"]</tt></li>"Max"]</tt></t></li> </ul> <t><strong>Claim <tt>family_name</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk</tt></li> <li>Disclosure:<br/> <tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1c</tt><br/> <tt>dTAwZmNsbGVyIl0</tt></li> <li>Contents: <tt>["lklxF5jMYlGTPUovMNIvCA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTAwZmNsbGVyIl0</tt></t></li> <li><t>Contents:</t><t><tt>["lklxF5jMYlGTPUovMNIvCA", "family_name","M\u00fcller"]</tt></li>"M\u00fcller"]</tt></t></li> </ul> <t><strong>Claim <tt>nationalities</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE</tt></li> <li>Disclosure:<br/> <tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBb</tt><br/> <tt>IkRFIl1d</tt></li> <li>Contents: <tt>["nPuoQnkRFq3BIeAm7AnXFA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d</tt></t></li> <li><t>Contents:</t><t><tt>["nPuoQnkRFq3BIeAm7AnXFA", "nationalities",["DE"]]</tt></li>["DE"]]</tt></t></li> </ul> <t><strong>Claim <tt>birthdate</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk</tt></li> <li>Disclosure:<br/> <tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2</tt><br/> <tt>LTAxLTI4Il0</tt></li> <li>Contents: <tt>["5bPs1IquZNa0hkaFzzzZNw",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2LTAxLTI4Il0</tt></t></li> <li><t>Contents:</t><t><tt>["5bPs1IquZNa0hkaFzzzZNw", "birthdate","1956-01-28"]</tt></li>"1956-01-28"]</tt></t></li> </ul> <t><strong>Claim <tt>place_of_birth</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo</tt></li> <li>Disclosure:<br/> <tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwg</tt><br/> <tt>eyJjb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1</tt><br/> <tt>MDBlNmphcmtsYXVzdHVyIn1d</tt></li> <li>Contents: <tt>["5a2W0_NrlEZzfqmk_7Pq-w",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwgeyJjb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1MDBlNmphcmtsYXVzdHVyIn1d</tt></t></li> <li><t>Contents:</t><t><tt>["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth",{"country":</tt><br/> <tt>"IS",{"country": "IS", "locality":"\u00deykkvab\u00e6jarklaustur"}]</tt></li>"\u00deykkvab\u00e6jarklaustur"}]</tt></t></li> </ul> <t><strong>Claim <tt>address</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ</tt></li> <li>Disclosure:<br/> <tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2Fs</tt><br/> <tt>aXR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNv</tt><br/> <tt>dW50cnkiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1</tt><br/> <tt>MDBkZmUgMjIifV0</tt></li> <li>Contents: <tt>["y1sVU5wdfJahVdgwPgS7RQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2FsaXR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0</tt></t></li> <li><t>Contents:</t><t><tt>["y1sVU5wdfJahVdgwPgS7RQ", "address",{"locality":</tt><br/> <tt>"Maxstadt",{"locality": "Maxstadt", "postal_code": "12344", "country":"DE",</tt><br/> <tt>"street_address":"DE", "street_address": "Weidenstra\u00dfe22"}]</tt></li>22"}]</tt></t></li> </ul> <t><strong>Claim <tt>birth_middle_name</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI</tt></li> <li>Disclosure:<br/> <tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1l</tt><br/> <tt>IiwgIlRpbW90aGV1cyJd</tt></li> <li>Contents: <tt>["HbQ4X8srVW3QDxnIJdqyOA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1lIiwgIlRpbW90aGV1cyJd</tt></t></li> <li><t>Contents:</t><t><tt>["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name","Timotheus"]</tt></li>"Timotheus"]</tt></t></li> </ul> <t><strong>Claim <tt>salutation</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw</tt></li> <li>Disclosure:<br/> <tt>WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIu</tt><br/> <tt>Il0</tt></li> <li>Contents: <tt>["C9GSoujviJquEgYfojCb1A",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIuIl0</tt></t></li> <li><t>Contents:</t><t><tt>["C9GSoujviJquEgYfojCb1A", "salutation","Dr."]</tt></li>"Dr."]</tt></t></li> </ul> <t><strong>Claim <tt>msisdn</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg</tt></li> <li>Disclosure:<br/> <tt>WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1</tt><br/> <tt>Njc4OSJd</tt></li> <li>Contents: <tt>["kx5kF17V-x0JmwUx9vgvtw",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1Njc4OSJd</tt></t></li> <li><t>Contents:</t><t><tt>["kx5kF17V-x0JmwUx9vgvtw", "msisdn","49123456789"]</tt></li>"49123456789"]</tt></t></li> </ul> <t>The following is a presentation of the SD-JWT:</t> <sourcecodetype="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBbtype="txt"><![CDATA[ eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb Ii1hU3puSWQ5bVdNOG9jdVFvbENsbHN4VmdncTEtdkhXNE90bmhVdFZtV3ciLCAiSUti cllObjN2QTdXRUZyeXN2YmRCSmpERFVfRXZRSXIwVzE4dlRScFVTZyIsICJvdGt4dVQx NG5CaXd6TkozTVBhT2l0T2w5cFZuWE9hRUhhbF94a3lOZktJIl0sICJpc3MiOiAiaHR0 cHM6Ly9pc3N1ZXIuZXhhbXBsZS5jb20iLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6 IDE4ODMwMDAwMDAsICJ2ZXJpZmllZF9jbGFpbXMiOiB7InZlcmlmaWNhdGlvbiI6IHsi X3NkIjogWyI3aDRVRTlxU2N2REtvZFhWQ3VvS2ZLQkpwVkJmWE1GX1RtQUdWYVplM1Nj IiwgInZUd2UzcmFISUZZZ0ZBM3hhVUQyYU14Rno1b0RvOGlCdTA1cUtsT2c5THciXSwg InRydXN0X2ZyYW1ld29yayI6ICJkZV9hbWwiLCAiZXZpZGVuY2UiOiBbeyIuLi4iOiAi dFlKMFREdWN5WlpDUk1iUk9HNHFSTzV2a1BTRlJ4RmhVRUxjMThDU2wzayJ9XX0sICJj bGFpbXMiOiB7Il9zZCI6IFsiUmlPaUNuNl93NVpIYWFka1FNcmNRSmYwSnRlNVJ3dXJS czU0MjMxRFRsbyIsICJTXzQ5OGJicEt6QjZFYW5mdHNzMHhjN2NPYW9uZVJyM3BLcjdO ZFJtc01vIiwgIldOQS1VTks3Rl96aHNBYjlzeVdPNklJUTF1SGxUbU9VOHI4Q3ZKMGNJ TWsiLCAiV3hoX3NWM2lSSDliZ3JUQkppLWFZSE5DTHQtdmpoWDFzZC1pZ09mXzlsayIs ICJfTy13SmlIM2VuU0I0Uk9IbnRUb1FUOEptTHR6LW1oTzJmMWM4OVhvZXJRIiwgImh2 RFhod21HY0pRc0JDQTJPdGp1TEFjd0FNcERzYVUwbmtvdmNLT3FXTkUiXX19LCAiX3Nk X2FsZyI6ICJzaGEtMjU2In0.QoWYWtikm-AtjmPnNVshbGXQl5raEz15PByTmZwfTQg9 W2O3oR6j2tMmysTZZawdo6mNLR_PsZSI25qrUpiNTg~WyIyR0xDNDJzS1F2ZUNmR2Zye U5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1QxODoyNVoiXQ~WyJQYzMzSk0yTGNoY1 VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDdQSzBuc1FETDhCMDZsbWRnVj NMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRX RtMWJHX3djYUtJayIsICJJaHdGcldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZU JJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMW JFVlEiXX1d~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwI l0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0~W yJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTAwZmNsb GVyIl0~WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2Fsa XR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiO iAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0~ ]]> </sourcecode> <t>The Verifier will have this Processed SD-JWT Payload available after validation:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "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" } } } } ]]> </sourcecode> </section> <sectionanchor="sd-jwt-based-verifiable-credentials-sd-jwt-vc"><name>SD-JWT-basedanchor="sd-jwt-based-verifiable-credentials-sd-jwt-vc"><name>SD-JWT-Based Verifiable Credentials (SD-JWT VC)</name> <t>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) <xref target="I-D.ietf-oauth-sd-jwt-vc"/> to represent the concept of a Person Identification Data (PID) as defined in the "PID Rulebook" in <xref target="EUDIW.ARF"/>. This example uses fictional data of a German citizen.</t> <t>Key Binding is applied using the Holder's public key passed in a <tt>cnf</tt> claim in the SD-JWT.</t> <t>The following citizen data is the input JWT Claims Set:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "vct": "urn:eudi:pid:de:1", "iss": "https://pid-issuer.bund.de.example", "given_name": "Erika", "family_name": "Mustermann", "birthdate": "1963-08-12", "address": { "street_address": "Heidestraße 17", "locality": "Köln", "postal_code": "51147", "country": "DE" }, "nationalities": [ "DE" ], "sex": 2, "birth_family_name": "Gabler", "place_of_birth": { "locality": "Berlin", "country": "DE" }, "age_equal_or_over": { "12": true, "14": true, "16": true, "18": true, "21": true, "65": false }, "age_in_years": 62, "age_birth_year": 1963, "issuance_date": "2020-03-11", "expiry_date": "2030-03-12", "issuing_authority": "DE", "issuing_country": "DE" } ]]> </sourcecode> <t>The following is the issued SD-JWT:</t> <sourcecodetype="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1type="txt"><![CDATA[ eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1 uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21 VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJ XclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0F rYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB 5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWk wQnFoV3FaM3dxRDRqRi1xREdrIiwgIkkwMGZjRlVvRFhDdWNwNXl5MnVqcVBzc0RWR2F XTmlVbGlOel9hd0QwZ2MiLCAiS2pBWGdBQTlONVdIRUR0UkloNHU1TW4xWnNXaXhoaFd BaVgtQTRRaXdnQSIsICJMYWk2SVU2ZDdHUWFnWFI3QXZHVHJuWGdTbGQzejhFSWdfZnY zZk9aMVdnIiwgIkxlemphYlJxaVpPWHpFWW1WWmY4Uk1pOXhBa2QzX00xTFo4VTdFNHM zdTQiLCAiUlR6M3FUbUZOSGJwV3JyT01aUzQxRjQ3NGtGcVJ2M3ZJUHF0aDZQVWhsTSI sICJXMTRYSGJVZmZ6dVc0SUZNanBTVGIxbWVsV3hVV2Y0Tl9vMmxka2tJcWM4IiwgIld UcEk3UmNNM2d4WnJ1UnBYemV6U2JrYk9yOTNQVkZ2V3g4d29KM2oxY0UiLCAiX29oSlZ JUUlCc1U0dXBkTlM0X3c0S2IxTUhxSjBMOXFMR3NoV3E2SlhRcyIsICJ5NTBjemMwSVN DaHlfYnNiYTFkTW9VdUFPUTVBTW1PU2ZHb0VlODF2MUZVIl0sICJpc3MiOiAiaHR0cHM 6Ly9waWQtaXNzdWVyLmJ1bmQuZGUuZXhhbXBsZSIsICJpYXQiOiAxNjgzMDAwMDAwLCA iZXhwIjogMTg4MzAwMDAwMCwgInZjdCI6ICJ1cm46ZXVkaTpwaWQ6ZGU6MSIsICJfc2R fYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnY iOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbER sczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U 2dDRqVDlGMkhaUSJ9fX0.ZOZQTqmq8X1mCyFXi0wbV8xjctX1AlEa5TkdnkKOyWvLfW4 0XDb5oj9tzkgwff5s44IDnrfAdgLtmTcojs97_Q~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5S Tjl3IiwgImdpdmVuX25hbWUiLCAiRXJpa2EiXQ~WyJlbHVWNU9nM2dTTklJOEVZbnN4Q V9BIiwgImZhbWlseV9uYW1lIiwgIk11c3Rlcm1hbm4iXQ~WyI2SWo3dE0tYTVpVlBHYm 9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA4LTEyIl0~WyJlSThaV205UW5LUH BOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwgIkhlaWRlc3RyYVx1MDBkZmUgMT ciXQ~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAwZjZ sbiJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUxMT Q3Il0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ~WyJ HMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiQUxaRVJ zU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3OCIsICJEX19XX3VZY3Z SejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNfdzlrIiwgImVCcENYVTFKNWRoSDJ nNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZb1BobzAiLCAieE9QeTktZ0pBTEs2VWJXS0Z MUjg1Y09CeVVEM0FiTndGZzNJM1lmUUVfSSJdfV0~WyJsa2x4RjVqTVlsR1RQVW92TU5 JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d~WyJuUHVvUW5rUkZxM0JJZUFtN0 FuWEZBIiwgInNleCIsIDJd~WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX 2ZhbWlseV9uYW1lIiwgIkdhYmxlciJd~WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13Iiwg ImxvY2FsaXR5IiwgIkJlcmxpbiJd~WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImN vdW50cnkiLCAiREUiXQ~WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29m X2JpcnRoIiwgeyJfc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNq U1BNalphR2t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVaY2xG SFhmLVVTUSJdfV0~WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0~ WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0~WyJIM28xdXN3UDc2 MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0~WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpB IiwgIjE4IiwgdHJ1ZV0~WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1 ZV0~WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd~WyJlSzVvNXB IZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiwgeyJfc2QiOiBbIjF 0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J3a2siLCAiQ1ZLbmx 5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjh fM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajB oczJaTnd4Y3FPbGY4bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR 6YUZDVWNlSVFBYUlkaHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnF xalFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ~WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3 IiwgImFnZV9pbl95ZWFycyIsIDYyXQ~WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgI mFnZV9iaXJ0aF95ZWFyIiwgMTk2M10~WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgI mlzc3VhbmNlX2RhdGUiLCAiMjAyMC0wMy0xMSJd~WyI0S3lSMzJvSVp0LXprV3ZGcWJV TEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzAtMDMtMTIiXQ~WyJjaEJDc3loeWgtSjg2S S1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5IiwgIkRFIl0~WyJmbE5QMW5jTXo5T GctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJERSJd~ ]]> </sourcecode> <t>The following payload is used for the SD-JWT:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "_sd": [ "0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg", "1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow", "2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8", "6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os", "78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM", "90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk", "I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc", "KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA", "Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg", "LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4", "RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM", "W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8", "WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE", "_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs", "y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU" ], "iss": "https://pid-issuer.bund.de.example", "iat": 1683000000, "exp": 1883000000, "vct": "urn:eudi:pid:de:1", "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" } } }]]> </sourcecode>]]></sourcecode> <t>The digests in the SD-JWT payload reference the following Disclosures:</t> <t><strong>Claim <tt>given_name</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg</tt></li> <li>Disclosure:<br/> <tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJp</tt><br/> <tt>a2EiXQ</tt></li> <li>Contents: <tt>["2GLC42sKQveCfGfryNRN9w",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg</tt></t></li> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJpa2EiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "given_name","Erika"]</tt></li>"Erika"]</tt></t></li> </ul> <t><strong>Claim <tt>family_name</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc</tt></li> <li>Disclosure:<br/> <tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11</tt><br/> <tt>c3Rlcm1hbm4iXQ</tt></li> <li>Contents: <tt>["eluV5Og3gSNII8EYnsxA_A",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11c3Rlcm1hbm4iXQ</tt></t></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "family_name","Mustermann"]</tt></li>"Mustermann"]</tt></t></li> </ul> <t><strong>Claim <tt>birthdate</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg</tt></li> <li>Disclosure:<br/> <tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYz</tt><br/> <tt>LTA4LTEyIl0</tt></li> <li>Contents: <tt>["6Ij7tM-a5iVPGboS5tmvVA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA4LTEyIl0</tt></t></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "birthdate","1963-08-12"]</tt></li>"1963-08-12"]</tt></t></li> </ul> <t><strong>Claim <tt>street_address</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8</tt></li> <li>Disclosure:<br/> <tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwg</tt><br/> <tt>IkhlaWRlc3RyYVx1MDBkZmUgMTciXQ</tt></li> <li>Contents: <tt>["eI8ZWm9QnKPpNPeNenHdhQ", "street_address",</tt><br/> <tt>"Heidestra\u00dfe 17"]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwgIkhlaWRlc3RyYVx1MDBkZmUgMTciXQ</tt></t></li> <li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "street_address", "Heidestra\u00dfe 17"]</tt></t></li> </ul> <t><strong>Claim <tt>locality</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k</tt></li> <li>Disclosure:<br/> <tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAw</tt><br/> <tt>ZjZsbiJd</tt></li> <li>Contents: <tt>["Qg_O64zqAxe412a108iroA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAwZjZsbiJd</tt></t></li> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "locality","K\u00f6ln"]</tt></li>"K\u00f6ln"]</tt></t></li> </ul> <t><strong>Claim <tt>postal_code</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I</tt></li> <li>Disclosure:<br/> <tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUx</tt><br/> <tt>MTQ3Il0</tt></li> <li>Contents: <tt>["AJx-095VPrpTtN4QMOqROA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUxMTQ3Il0</tt></t></li> <li><t>Contents:</t><t><tt>["AJx-095VPrpTtN4QMOqROA", "postal_code","51147"]</tt></li>"51147"]</tt></t></li> </ul> <t><strong>Claim <tt>country</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0</tt></li> <li>Disclosure:<br/> <tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ</tt></li> <li>Contents: <tt>["Pc33JM2LchcU_lHggv_ufQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["Pc33JM2LchcU_lHggv_ufQ", "country","DE"]</tt></li>"DE"]</tt></t></li> </ul> <t><strong>Claim <tt>address</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM</tt></li> <li>Disclosure:<br/> <tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6</tt><br/> <tt>IFsiQUxaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3</tt><br/> <tt>OCIsICJEX19XX3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNf</tt><br/> <tt>dzlrIiwgImVCcENYVTFKNWRoSDJnNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZ</tt><br/> <tt>b1BobzAiLCAieE9QeTktZ0pBTEs2VWJXS0ZMUjg1Y09CeVVEM0FiTndGZzNJ</tt><br/> <tt>M1lmUUVfSSJdfV0</tt></li> <li>Contents: <tt>["G02NSrQfjFXQ7Io09syajA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiQUxaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3OCIsICJEX19XX3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNfdzlrIiwgImVCcENYVTFKNWRoSDJnNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZb1BobzAiLCAieE9QeTktZ0pBTEs2VWJXS0ZMUjg1Y09CeVVEM0FiTndGZzNJM1lmUUVfSSJdfV0</tt></t></li> <li><t>Contents:</t><t><tt>["G02NSrQfjFXQ7Io09syajA", "address",{"_sd":</tt><br/> <tt>["ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8",</tt><br/> <tt>"D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k",</tt><br/> <tt>"eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0",</tt><br/> <tt>"xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I"]}]</tt></li>{"_sd": ["ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8", "D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k", "eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0", "xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I"]}]</tt></t></li> </ul> <t><strong>Claim <tt>nationalities</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU</tt></li> <li>Disclosure:<br/> <tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBb</tt><br/> <tt>IkRFIl1d</tt></li> <li>Contents: <tt>["lklxF5jMYlGTPUovMNIvCA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d</tt></t></li> <li><t>Contents:</t><t><tt>["lklxF5jMYlGTPUovMNIvCA", "nationalities",["DE"]]</tt></li>["DE"]]</tt></t></li> </ul> <t><strong>Claim <tt>sex</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk</tt></li> <li>Disclosure:<br/> <tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgInNleCIsIDJd</tt></li> <li>Contents: <tt>["nPuoQnkRFq3BIeAm7AnXFA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgInNleCIsIDJd</tt></t></li> <li><t>Contents:</t><t><tt>["nPuoQnkRFq3BIeAm7AnXFA", "sex",2]</tt></li>2]</tt></t></li> </ul> <t><strong>Claim <tt>birth_family_name</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA</tt></li> <li>Disclosure:<br/> <tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX2ZhbWlseV9uYW1l</tt><br/> <tt>IiwgIkdhYmxlciJd</tt></li> <li>Contents: <tt>["5bPs1IquZNa0hkaFzzzZNw",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX2ZhbWlseV9uYW1lIiwgIkdhYmxlciJd</tt></t></li> <li><t>Contents:</t><t><tt>["5bPs1IquZNa0hkaFzzzZNw", "birth_family_name","Gabler"]</tt></li>"Gabler"]</tt></t></li> </ul> <t><strong>Claim <tt>locality</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE</tt></li> <li>Disclosure:<br/> <tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImxvY2FsaXR5IiwgIkJlcmxp</tt><br/> <tt>biJd</tt></li> <li>Contents: <tt>["5a2W0_NrlEZzfqmk_7Pq-w",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImxvY2FsaXR5IiwgIkJlcmxpbiJd</tt></t></li> <li><t>Contents:</t><t><tt>["5a2W0_NrlEZzfqmk_7Pq-w", "locality","Berlin"]</tt></li>"Berlin"]</tt></t></li> </ul> <t><strong>Claim <tt>country</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ</tt></li> <li>Disclosure:<br/> <tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImNvdW50cnkiLCAiREUiXQ</tt></li> <li>Contents: <tt>["y1sVU5wdfJahVdgwPgS7RQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImNvdW50cnkiLCAiREUiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["y1sVU5wdfJahVdgwPgS7RQ", "country","DE"]</tt></li>"DE"]</tt></t></li> </ul> <t><strong>Claim <tt>place_of_birth</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow</tt></li> <li>Disclosure:<br/> <tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwg</tt><br/> <tt>eyJfc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BN</tt><br/> <tt>alphR2t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVa</tt><br/> <tt>Y2xGSFhmLVVTUSJdfV0</tt></li> <li>Contents: <tt>["HbQ4X8srVW3QDxnIJdqyOA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwgeyJfc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BNalphR2t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVaY2xGSFhmLVVTUSJdfV0</tt></t></li> <li><t>Contents:</t><t><tt>["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth",{"_sd":</tt><br/> <tt>["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE",</tt><br/> <tt>"YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ"]}]</tt></li>{"_sd": ["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE", "YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ"]}]</tt></t></li> </ul> <t><strong>Claim <tt>12</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU</tt></li> <li>Disclosure:<br/> <tt>WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0</tt></li> <li>Contents: <tt>["C9GSoujviJquEgYfojCb1A",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0</tt></t></li> <li><t>Contents:</t><t><tt>["C9GSoujviJquEgYfojCb1A", "12",true]</tt></li>true]</tt></t></li> </ul> <t><strong>Claim <tt>14</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI</tt></li> <li>Disclosure:<br/> <tt>WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0</tt></li> <li>Contents: <tt>["kx5kF17V-x0JmwUx9vgvtw",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0</tt></t></li> <li><t>Contents:</t><t><tt>["kx5kF17V-x0JmwUx9vgvtw", "14",true]</tt></li>true]</tt></t></li> </ul> <t><strong>Claim <tt>16</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI</tt></li> <li>Disclosure:<br/> <tt>WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0</tt></li> <li>Contents: <tt>["H3o1uswP760Fi2yeGdVCEQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0</tt></t></li> <li><t>Contents:</t><t><tt>["H3o1uswP760Fi2yeGdVCEQ", "16",true]</tt></li>true]</tt></t></li> </ul> <t><strong>Claim <tt>18</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg</tt></li> <li>Disclosure:<br/> <tt>WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0</tt></li> <li>Contents: <tt>["OBKlTVlvLg-AdwqYGbP8ZA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0</tt></t></li> <li><t>Contents:</t><t><tt>["OBKlTVlvLg-AdwqYGbP8ZA", "18",true]</tt></li>true]</tt></t></li> </ul> <t><strong>Claim <tt>21</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk</tt></li> <li>Disclosure:<br/> <tt>WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1ZV0</tt></li> <li>Contents: <tt>["M0Jb57t41ubrkSuyrDT3xA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1ZV0</tt></t></li> <li><t>Contents:</t><t><tt>["M0Jb57t41ubrkSuyrDT3xA", "21",true]</tt></li>true]</tt></t></li> </ul> <t><strong>Claim <tt>65</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg</tt></li> <li>Disclosure:<br/> <tt>WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd</tt></li> <li>Contents: <tt>["DsmtKNgpV4dAHpjrcaosAw",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd</tt></t></li> <li><t>Contents:</t><t><tt>["DsmtKNgpV4dAHpjrcaosAw", "65",false]</tt></li>false]</tt></t></li> </ul> <t><strong>Claim <tt>age_equal_or_over</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8</tt></li> <li>Disclosure:<br/> <tt>WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVy</tt><br/> <tt>IiwgeyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4</tt><br/> <tt>SFhBMHI1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lO</tt><br/> <tt>QTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96</tt><br/> <tt>ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4</tt><br/> <tt>bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNl</tt><br/> <tt>SVFBYUlkaHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFx</tt><br/> <tt>alFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ</tt></li> <li>Contents: <tt>["eK5o5pHfgupPpltj1qhAJw",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiwgeyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlkaHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ</tt></t></li> <li><t>Contents:</t><t><tt>["eK5o5pHfgupPpltj1qhAJw", "age_equal_or_over",{"_sd":</tt><br/> <tt>["1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk",</tt><br/> <tt>"CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg",</tt><br/> <tt>"a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg",</tt><br/> <tt>"gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU",</tt><br/> <tt>"hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI",</tt><br/> <tt>"y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI"]}]</tt></li>{"_sd": ["1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk", "CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg", "a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg", "gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU", "hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI", "y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI"]}]</tt></t></li> </ul> <t><strong>Claim <tt>age_in_years</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE</tt></li> <li>Disclosure:<br/> <tt>WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3IiwgImFnZV9pbl95ZWFycyIsIDYy</tt><br/> <tt>XQ</tt></li> <li>Contents: <tt>["j7ADdb0UVb0Li0ciPcP0ew",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3IiwgImFnZV9pbl95ZWFycyIsIDYyXQ</tt></t></li> <li><t>Contents:</t><t><tt>["j7ADdb0UVb0Li0ciPcP0ew", "age_in_years",62]</tt></li>62]</tt></t></li> </ul> <t><strong>Claim <tt>age_birth_year</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4</tt></li> <li>Disclosure:<br/> <tt>WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgImFnZV9iaXJ0aF95ZWFyIiwg</tt><br/> <tt>MTk2M10</tt></li> <li>Contents: <tt>["WpxJrFuX8uSi2p4ht09jvw",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgImFnZV9iaXJ0aF95ZWFyIiwgMTk2M10</tt></t></li> <li><t>Contents:</t><t><tt>["WpxJrFuX8uSi2p4ht09jvw", "age_birth_year",1963]</tt></li>1963]</tt></t></li> </ul> <t><strong>Claim <tt>issuance_date</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8</tt></li> <li>Disclosure:<br/> <tt>WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgImlzc3VhbmNlX2RhdGUiLCAi</tt><br/> <tt>MjAyMC0wMy0xMSJd</tt></li> <li>Contents: <tt>["atSmFACYMbJVKD05o3JgtQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgImlzc3VhbmNlX2RhdGUiLCAiMjAyMC0wMy0xMSJd</tt></t></li> <li><t>Contents:</t><t><tt>["atSmFACYMbJVKD05o3JgtQ", "issuance_date","2020-03-11"]</tt></li>"2020-03-11"]</tt></t></li> </ul> <t><strong>Claim <tt>expiry_date</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM</tt></li> <li>Disclosure:<br/> <tt>WyI0S3lSMzJvSVp0LXprV3ZGcWJVTEtnIiwgImV4cGlyeV9kYXRlIiwgIjIw</tt><br/> <tt>MzAtMDMtMTIiXQ</tt></li> <li>Contents: <tt>["4KyR32oIZt-zkWvFqbULKg",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI0S3lSMzJvSVp0LXprV3ZGcWJVTEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzAtMDMtMTIiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["4KyR32oIZt-zkWvFqbULKg", "expiry_date","2030-03-12"]</tt></li>"2030-03-12"]</tt></t></li> </ul> <t><strong>Claim <tt>issuing_authority</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os</tt></li> <li>Disclosure:<br/> <tt>WyJjaEJDc3loeWgtSjg2SS1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5</tt><br/> <tt>IiwgIkRFIl0</tt></li> <li>Contents: <tt>["chBCsyhyh-J86I-awQDiCQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJjaEJDc3loeWgtSjg2SS1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5IiwgIkRFIl0</tt></t></li> <li><t>Contents:</t><t><tt>["chBCsyhyh-J86I-awQDiCQ", "issuing_authority","DE"]</tt></li>"DE"]</tt></t></li> </ul> <t><strong>Claim <tt>issuing_country</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs</tt></li> <li>Disclosure:<br/> <tt>WyJmbE5QMW5jTXo5TGctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIs</tt><br/> <tt>ICJERSJd</tt></li> <li>Contents: <tt>["flNP1ncMz9Lg-c9qMIz_9g",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJmbE5QMW5jTXo5TGctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJERSJd</tt></t></li> <li><t>Contents:</t><t><tt>["flNP1ncMz9Lg-c9qMIz_9g", "issuing_country","DE"]</tt></li>"DE"]</tt></t></li> </ul> <t>The following is an example of an SD-JWT+KB that discloses only nationality and the fact that the person is over 18 years old:</t> <sourcecodetype="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1type="txt"><![CDATA[ eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1 uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21 VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJ XclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0F rYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB 5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWk wQnFoV3FaM3dxRDRqRi1xREdrIiwgIkkwMGZjRlVvRFhDdWNwNXl5MnVqcVBzc0RWR2F XTmlVbGlOel9hd0QwZ2MiLCAiS2pBWGdBQTlONVdIRUR0UkloNHU1TW4xWnNXaXhoaFd BaVgtQTRRaXdnQSIsICJMYWk2SVU2ZDdHUWFnWFI3QXZHVHJuWGdTbGQzejhFSWdfZnY zZk9aMVdnIiwgIkxlemphYlJxaVpPWHpFWW1WWmY4Uk1pOXhBa2QzX00xTFo4VTdFNHM zdTQiLCAiUlR6M3FUbUZOSGJwV3JyT01aUzQxRjQ3NGtGcVJ2M3ZJUHF0aDZQVWhsTSI sICJXMTRYSGJVZmZ6dVc0SUZNanBTVGIxbWVsV3hVV2Y0Tl9vMmxka2tJcWM4IiwgIld UcEk3UmNNM2d4WnJ1UnBYemV6U2JrYk9yOTNQVkZ2V3g4d29KM2oxY0UiLCAiX29oSlZ JUUlCc1U0dXBkTlM0X3c0S2IxTUhxSjBMOXFMR3NoV3E2SlhRcyIsICJ5NTBjemMwSVN DaHlfYnNiYTFkTW9VdUFPUTVBTW1PU2ZHb0VlODF2MUZVIl0sICJpc3MiOiAiaHR0cHM 6Ly9waWQtaXNzdWVyLmJ1bmQuZGUuZXhhbXBsZSIsICJpYXQiOiAxNjgzMDAwMDAwLCA iZXhwIjogMTg4MzAwMDAwMCwgInZjdCI6ICJ1cm46ZXVkaTpwaWQ6ZGU6MSIsICJfc2R fYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnY iOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbER sczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U 2dDRqVDlGMkhaUSJ9fX0.ZOZQTqmq8X1mCyFXi0wbV8xjctX1AlEa5TkdnkKOyWvLfW4 0XDb5oj9tzkgwff5s44IDnrfAdgLtmTcojs97_Q~WyJlSzVvNXBIZmd1cFBwbHRqMXFo QUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiwgeyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3 U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4 UWlPdFVjemFYQ1lOQTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kx eTBRel96ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4 bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlk aHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21N ZU8wS3FhekdJIl19XQ~WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1Z V0~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFI l1d~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM 0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgIml hdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlBqTVlmTTA3VmJKZE14TElsdXZSTmI 4OEpGbGpTWDRuLUc0M1VjX0JTUk0ifQ.f3TeS_1BWEG78EbIJRh5wgv8nYumk7euzu6x gbgpNB4pbQQqgRPWK-vQjlhhgU1EFGZ9LFakFX_0mgul1G_3mw ]]> </sourcecode> <t>This is the payload of the corresponding Key Binding JWT:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "nonce": "1234567890", "aud": "https://verifier.example.org", "iat": 1748537244, "sd_hash": "PjMYfM07VbJdMxLIluvRNb88JFljSX4n-G43Uc_BSRM" } ]]> </sourcecode> <t>After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "iss": "https://pid-issuer.bund.de.example", "iat": 1683000000, "exp": 1883000000, "vct": "urn:eudi:pid:de:1", "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" } }, "age_equal_or_over": { "18": true }, "nationalities": [ "DE" ] }]]> </sourcecode>]]></sourcecode> </section> <section anchor="w3c-verifiable-credentials-data-model-v2-0"><name>W3C Verifiable Credentials Data Model v2.0</name> <t>This non-normative example illustrates how the artifacts defined in this specification could be used to express a W3C Verifiable Credentials Data Model v2.0 payload <xreftarget="VC_DATA_v2.0"/> payload.</t>target="VC_DATA_v2.0"/>.</t> <t>Key Binding is applied using the Holder's public key passed in a <tt>cnf</tt> claim in the SD-JWT.</t> <t>The following is the input JWT Claims Set:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "@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" } }]]> </sourcecode>]]></sourcecode> <t>The following is the issued SD-JWT:</t> <sourcecodetype="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4type="txt"><![CDATA[ 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.OZomvwO8iw4db89MYCeeomBVStXkT6u7G7FkicPWZnd2 _hGgr0l_u1NHgPVocuOt-m32Uu6kwtPmYFxKk0AOeA~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~ ]]> </sourcecode> <t>The following payload is used for the SD-JWT:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "@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" } } }]]> </sourcecode>]]></sourcecode> <t>The digests in the SD-JWT payload reference the following Disclosures:</t> <t><strong>Claim <tt>atcCode</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI</tt></li> <li>Disclosure:<br/> <tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3Qlgw</tt><br/> <tt>MyJd</tt></li> <li>Contents: <tt>["2GLC42sKQveCfGfryNRN9w",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI</tt></t></li> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd</tt></t></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "atcCode","J07BX03"]</tt></li>"J07BX03"]</tt></t></li> </ul> <t><strong>Claim <tt>medicinalProductName</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo</tt></li> <li>Disclosure:<br/> <tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3RO</tt><br/> <tt>YW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd</tt></li> <li>Contents: <tt>["eluV5Og3gSNII8EYnsxA_A",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd</tt></t></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName","COVID-19</tt><br/> <tt>Vaccine Moderna"]</tt></li>"COVID-19 Vaccine Moderna"]</tt></t></li> </ul> <t><strong>Claim <tt>marketingAuthorizationHolder</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE</tt></li> <li>Disclosure:<br/> <tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6</tt><br/> <tt>YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0</tt></li> <li>Contents: <tt>["6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHolder",</tt><br/> <tt>"Moderna Biotech"]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0</tt></t></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHolder", "Moderna Biotech"]</tt></t></li> </ul> <t><strong>Claim <tt>nextVaccinationDate</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4</tt></li> <li>Disclosure:<br/> <tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRh</tt><br/> <tt>dGUiLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ</tt></li> <li>Contents: <tt>["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate",</tt><br/> <tt>"2021-08-16T13:40:12Z"]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGUiLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate", "2021-08-16T13:40:12Z"]</tt></t></li> </ul> <t><strong>Claim <tt>countryOfVaccination</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg</tt></li> <li>Disclosure:<br/> <tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0</tt><br/> <tt>aW9uIiwgIkdFIl0</tt></li> <li>Contents: <tt>["Qg_O64zqAxe412a108iroA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0aW9uIiwgIkdFIl0</tt></t></li> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "countryOfVaccination","GE"]</tt></li>"GE"]</tt></t></li> </ul> <t><strong>Claim <tt>dateOfVaccination</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0</tt></li> <li>Disclosure:<br/> <tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9u</tt><br/> <tt>IiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0</tt></li> <li>Contents: <tt>["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination",</tt><br/> <tt>"2021-06-23T13:40:12Z"]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0</tt></t></li> <li><t>Contents:</t><t><tt>["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination", "2021-06-23T13:40:12Z"]</tt></t></li> </ul> <t><strong>Claim <tt>order</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g</tt></li> <li>Disclosure:<br/> <tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd</tt></li> <li>Contents: <tt>["Pc33JM2LchcU_lHggv_ufQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd</tt></t></li> <li><t>Contents:</t><t><tt>["Pc33JM2LchcU_lHggv_ufQ", "order","3/3"]</tt></li>"3/3"]</tt></t></li> </ul> <t><strong>Claim <tt>gender</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI</tt></li> <li>Disclosure:<br/> <tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUi</tt><br/> <tt>XQ</tt></li> <li>Contents: <tt>["G02NSrQfjFXQ7Io09syajA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["G02NSrQfjFXQ7Io09syajA", "gender","Female"]</tt></li>"Female"]</tt></t></li> </ul> <t><strong>Claim <tt>birthDate</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU</tt></li> <li>Disclosure:<br/> <tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYx</tt><br/> <tt>LTA4LTE3Il0</tt></li> <li>Contents: <tt>["lklxF5jMYlGTPUovMNIvCA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYxLTA4LTE3Il0</tt></t></li> <li><t>Contents:</t><t><tt>["lklxF5jMYlGTPUovMNIvCA", "birthDate","1961-08-17"]</tt></li>"1961-08-17"]</tt></t></li> </ul> <t><strong>Claim <tt>givenName</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw</tt></li> <li>Disclosure:<br/> <tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJp</tt><br/> <tt>b24iXQ</tt></li> <li>Contents: <tt>["nPuoQnkRFq3BIeAm7AnXFA",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJpb24iXQ</tt></t></li> <li><t>Contents:</t><t><tt>["nPuoQnkRFq3BIeAm7AnXFA", "givenName","Marion"]</tt></li>"Marion"]</tt></t></li> </ul> <t><strong>Claim <tt>familyName</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA</tt></li> <li>Disclosure:<br/> <tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVz</tt><br/> <tt>dGVybWFubiJd</tt></li> <li>Contents: <tt>["5bPs1IquZNa0hkaFzzzZNw",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVzdGVybWFubiJd</tt></t></li> <li><t>Contents:</t><t><tt>["5bPs1IquZNa0hkaFzzzZNw", "familyName","Mustermann"]</tt></li>"Mustermann"]</tt></t></li> </ul> <t><strong>Claim <tt>administeringCentre</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg</tt></li> <li>Disclosure:<br/> <tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50</tt><br/> <tt>cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd</tt></li> <li>Contents: <tt>["5a2W0_NrlEZzfqmk_7Pq-w",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg</tt></t></li> <li><t>Disclosure:</t><t><tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd</tt></t></li> <li><t>Contents:</t><t><tt>["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre","Praxis</tt><br/> <tt>Sommergarten"]</tt></li>"Praxis Sommergarten"]</tt></t></li> </ul> <t><strong>Claim <tt>batchNumber</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM</tt></li> <li>Disclosure:<br/> <tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2</tt><br/> <tt>MjYzODI3MzYiXQ</tt></li> <li>Contents: <tt>["y1sVU5wdfJahVdgwPgS7RQ",spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzODI3MzYiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber","1626382736"]</tt></li>"1626382736"]</tt></t></li> </ul> <t><strong>Claim <tt>healthProfessional</tt></strong>:</t> <ulspacing="compact"> <li>SHA-256 Hash: <tt>1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww</tt></li> <li>Disclosure:<br/> <tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25h</tt><br/> <tt>bCIsICI4ODMxMTAwMDAwMTUzNzYiXQ</tt></li> <li>Contents: <tt>["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional",</tt><br/> <tt>"883110000015376"]</tt></li>spacing="normal"> <li><t>SHA-256 Hash:</t><t><tt>1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww</tt></t></li> <li><t>Disclosure:</t><t><tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCIsICI4ODMxMTAwMDAwMTUzNzYiXQ</tt></t></li> <li><t>Contents:</t><t><tt>["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional", "883110000015376"]</tt></t></li> </ul> <t>This is an example of an SD-JWT+KB that discloses only <tt>type</tt>, <tt>medicinalProductName</tt>, <tt>atcCode</tt> of the vaccine, <tt>type</tt> of the <tt>recipient</tt>, <tt>type</tt>,<tt>order</tt><tt>order</tt>, and <tt>dateOfVaccination</tt>:</t> <sourcecodetype="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4type="txt"><![CDATA[ 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.OZomvwO8iw4db89MYCeeomBVStXkT6u7G7FkicPWZnd2 _hGgr0l_u1NHgPVocuOt-m32Uu6kwtPmYFxKk0AOeA~WyJQYzMzSk0yTGNoY1VfbEhnZ 3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwg ImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyIyR0xD NDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9 nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE 5IFZhY2NpbmUgTW9kZXJuYSJd~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dC J9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyL mV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIklvV1VIO TFsbGYzWEVybDQyYlEzc3hfNTNWMW8xdWpDejA4aERxSEs3RGsifQ.n0vzyIwCFMDVau EaeJIWEKZZchxXMpXTQewHgAkARbOSZxB09IbXXtHfpoGqO_BtNFN2lShJEIQBGyc-Xp HigA]]> </sourcecode>]]></sourcecode> <t>After the validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:</t> <sourcecodetype="json"><![CDATA[{type="json"><![CDATA[ { "@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" } } }]]> </sourcecode>]]></sourcecode> </section> <section anchor="elliptic-curve-key-used-in-the-examples"><name>Elliptic Curve Key Used in the Examples</name> <t>The following Elliptic Curve public key, represented in JWK format, can be used to validate the Issuer signatures in the above examples:</t><artwork><![CDATA[{<artwork><![CDATA[ { "kty": "EC", "crv": "P-256", "x": "b28d4MwZMjw8-00CG4xfnn9SLMVMM19SlqZpVb_uNtQ", "y": "Xv5zWwuoaTgdS6hV43yI6gBwTnjukmFQQnJ_kCxzqk8" }]]> </artwork>]]></artwork> <t>The public key used to validate a Key Binding JWT can be found in the examples as the content of the <tt>cnf</tt> claim.</t> </section> </section> <section anchor="disclosure_format_considerations"><name>Disclosure Format Considerations</name> <t>As described in <xref target="creating_disclosures"/>, the Disclosure structure is JSON containing a 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 different representations but is semantically equivalent, thus avoiding canonicalization. Some further discussion of the considerations around this design decision follows.</t> <t>When receiving an SD-JWT, a Verifier must be able tore-computerecompute digests of the disclosed claim values and, given the same input values, obtain the same digest values as signed by the Issuer.</t> <t>Usually, JSON-based formats transport claim values as simple properties of a JSON object such as this:</t> <artwork><![CDATA[... "family_name": "Möbius", "address": { "street_address": "Schulstr. 12", "locality": "Schulpforta" } ... ]]> </artwork> <t>However, a problem arises when computation over the data needs to be performed and verified, like signing or computing digests. Common signature schemes require the same byte string as input to 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.</t> <t>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</t><artwork><![CDATA[...<artwork><![CDATA[ ... "family_name": "M\u00f6bius", "address": { "street_address": "Schulstr. 12", "locality": "Schulpforta" } ... ]]> </artwork> <t>or as</t><artwork><![CDATA[...<artwork><![CDATA[ ... "family_name": "Möbius", "address": {"locality":"Schulpforta", "street_address":"Schulstr. 12"} ... ]]> </artwork> <t>The two representations of the value in <tt>family_name</tt> are very different on thebyte-level,byte level, but they yield equivalent objects.SameThe same is true for the representations of <tt>address</tt>,varyingwhich vary in white space and order of elements in the object.</t> <t>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 <xref target="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.</t> <t>There are generally two approaches to deal with this problem:</t> <olspacing="compact">spacing="normal"> <li>Canonicalization: The data is transferred in JSON format, potentially introducing variations in its representation, but is transformed into a canonical form before computing a digest. Both the Issuer and the Verifier must use the same canonicalization algorithm to arrive at the same byte string for computing a digest.</li> <li>Source string hardening: Instead of transferring data in a format that may introduce variations, a representation of the data is serialized. This representation is then used as the hashing input at the Verifier, but also transferred to the Verifier and used for the same digest calculation there. This means that the Verifier can easily compute and check the digest of the byte string before finally deserializing and accessing the data.</li> </ol> <t>Mixed approaches are conceivable, i.e., transferring both the original JSON dataplusand 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.</t> <t>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 usingbase64url-encodingbase64url 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.</t> <t>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.</t> <t>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 <xref target="verifier_verification"/> for details.</t> </section> <sectionanchor="document-history"><name>Document History</name> <t>[[ To be removed from the final specification ]]</t> <t>-22</t> <ul spacing="compact"> <li>fix text that was out of sync with the associated example</li> </ul> <t>-21</t> <ul spacing="compact"> <li>A few more minor IESG balloting updates</li> </ul> <t>-20</t> <ul spacing="compact"> <li>IESG balloting updates</li> </ul> <t>-19</t> <ul spacing="compact"> <li>Attempt to improve some language around exactly what bytes get base64url encoded</li> <li>Update the ABNFnumbered="false" anchor="Acknowledgements"><name>Acknowledgements</name> <t>We would like tosomething that is cleaner and more idiomatic</li> <li>updates from AD's reviewthank <contact fullname="Alen Horvat"/>, <contact fullname="Alex Hodder"/>, <contact fullname="Anders Rundgren"/>, <contact fullname="Arjan Geluk"/>, <contact fullname="Chad Parry"/>, <contact fullname="Christian Bormann"/>, <contact fullname="Christian Paquin"/>, <contact fullname="Dale Bowie"/>, <contact fullname="Dan Moore"/>, <contact fullname="David Bakker"/>, <contact fullname="David Waite"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Dick Hardt"/>, <contact fullname="Fabian Hauck"/>, <contact fullname="Filip Skokan"/>, <contact fullname="Giuseppe De Marco"/>, <contact fullname="Jacob Ward"/>, <contact fullname="Jeffrey Yasskin"/>, <contact fullname="John Preuß Mattsson"/>, <contact fullname="Joseph Heenan"/>, <contact fullname="Justin Richer"/>, <contact fullname="Kushal Das"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Matthew Miller"/>, <contact fullname="Michael Fraser"/>, <contact fullname="Michael B. Jones"/>, <contact fullname="Mike Prorock"/>, <contact fullname="Nat Sakimura"/>, <contact fullname="Neil Madden"/>, <contact fullname="Oliver Terbu"/>, <contact fullname="Orie Steele"/>, <contact fullname="Paul Bastian"/>, <contact fullname="Peter Altmann"/>, <contact fullname="Pieter Kasselman"/>, <contact fullname="Richard Barnes"/>, <contact fullname="Rohan Mahy"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Ryosuke Abe"/>, <contact fullname="Sami Rosendahl"/>, <contact fullname="Shawn Butterfield"/>, <contact fullname="Shawn Emery"/>, <contact fullname="Simon Schulz"/>, <contact fullname="Takahiko Kawasaki"/>, <contact fullname="Tobias Looker"/>, <contact fullname="Torsten Lodderstedt"/>, <contact fullname="Vittorio Bertocci"/>, <contact fullname="Watson Ladd"/>, and <contact fullname="Yaron Sheffer"/> for their contributions (some ofcomments</li> </ul> <t>-18</t> <ul spacing="compact"> <li>Update PID examplewhich were substantial) toalign with the latest ARF and update the ARF reference</li> <li>Editorial updates from SECDIR IETF LC review</li> <li>Terminology improvements around the phrase "non-selectively disclosable claims"this draft and"not disclosable"</li> <li>Suggest against using extra claims/headers in the KB-JWT without a good reason</li> </ul> <t>-17</t> <ul spacing="compact"> <li>Acknowledgements updates</li> </ul> <t>-16</t> <ul spacing="compact"> <li>Updates following review of -15 by Hannes Tschofenig, document shepherd</li> <li>Editorial updatestotext introduced in -15</li> <li>Changes based on feedback received after the end ofthesecond working group last call</li> </ul> <t>-15</t> <ul spacing="compact"> <li>Additions and adjustments to privacy considerations</li> <li>Address AD review comments resulting from evaluationinitial set offormal appeal</li> <li>Clarify language around compromised/coerced verifiers</li> </ul> <t>-14</t> <ul spacing="compact"> <li>Address WGLC (part 2) comments</li> <li>Noteimplementations. <!-- [rfced] Acknowledgements: As it appears thatthe Hash Function Claim value"John Mattsson" iscase-sensitive</li> <li>Update the <tt>typ</tt> value in the SD-JWT VC example to <tt>dc+sd-jwt</tt> to align with anticipated changes in the SD-JWT VC draft.</li> </ul> <t>-13</t> <ul spacing="compact"> <li>WGLC (part 1) updates</li> <li>Rewrote introduction</li> <li>Added note on algorithm for Holder's verification of the SD-JWT</li> </ul> <t>-12</t> <ul spacing="compact"> <li>Clarify, add context, or otherwise improve the examples</li> <li>Editorial and reference fixes</li> <li>Better introduce the phrase processed SD-JWT payload in the end of <xref target="sd_jwt_verification"/> on Verifying the SD-JWT</li> <li>Moved considerations around unlinkability to the top of the Privacy Considerations section</li> <li>Remove the brief discussion of publishing private key(s) to attempt to reduce the value of leaked or stolen data</li> </ul> <t>-11</t> <ul spacing="compact"> <li>Add a paragraph attempting to better frame the risks and difficulties around Issuer/Verifier unlinkability (i.e., a government issuer or huge service provider compelling collusion)</li> <li>Tightened the exposition</li> </ul> <t>-10</t> <ul spacing="compact"> <li>Add a section clarifying recursive disclosures and their interdependencies</li> <li>Editorial updates/fixes</li> </ul> <t>-09</t> <ul spacing="compact"> <li>Distinguished SD-JWT from SD-JWT+KB</li> <li>Provide ABNF for the SD-JWT, SD-JWT+KB, and various constituent parts</li> <li>New structure for JSON-serialized SD-JWTs/KB-JWTs to better align with JAdES.</li> <li>Attempt to better explain how salt"John Preuß Mattsson", we updated his name inthe Disclosure makes guessing the preimage of the digest infeasible</li> <li>Consolidate salt entropy and length security consideration subsections</li> <li>Unnumbered most of the examples for improved clarity</li> <li>More definitive language around the exclusive use of the <tt>cnf</tt> claim for enabling Key Binding</li> </ul> <t>-08</t> <ul spacing="compact"> <li>Make RFCs 0020 and 7515 normative references</li> <li>Bethis list, per his preference. (His last name is "Preuß Mattsson".) Please let us know if this is abit more prescriptive in suggesting RFC7800 cnf/jwk be used to convey the Key Binding key</li> <li>Editorial changes aimed at improved clarity</li> <li>Improve unlinkability considerations, mention thatdifferentKB keys must be used</li> <li>Remove the explicit prohibition on HMAC</li> <li>Remove mention of unspecified key binding methods and the Enveloping SD-JWTs section</li> <li>Editorial updates aimed at more consistent treatment of a Disclosure vs the contents of a Disclosure</li> <li>Update PID example</li> <li>Be more explicit"John Mattsson". Also, we saw thatthe VCDM and SD-JWT VC examples are only illustrativenames were mostly ordered by first name anddo not define anything</li> </ul> <t>-07</t> <ul spacing="compact"> <li>Reference RFC4086 in security considerations about salt entropy</li> <li>Update change controller for the Structured Syntax Suffix registration from IESG to IETF per IANA suggestion</li> <li>Strengthen security considerations around claims controlling the validity of the SD-JWT not being selectively disclosable</li> <li>Expand/rework considerations on the choice of hash algorithm</li> <li>Clarify validation around no duplicate digeststhen by last name. We made adjustments between "Shawn Emery" in thepayload (directly or recursively)original andno unused disclosures"Takahiko Kawasaki" accordingly. Please let us know any concerns. Original: ... Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, ... Mahy, Roman Danyliw, Ryosuke Abe, Sami Rosendahl, Shawn Emery, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten ... Currently: ... Yasskin, John Preuß Mattsson, Joseph Heenan, Justin Richer, Kushal ... Barnes, Rohan Mahy, Roman Danyliw, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Shawn Emery, Simon Schulz, Takahiko Kawasaki, Tobias ... --> </t> <t>The work on this document was started at theend of processing</li> <li>Better describe and illustrate the tilde separated format</li> <li>Change claim name from <tt>_sd_hash</tt> to <tt>sd_hash</tt></li> </ul> <t>-06</t> <ul spacing="compact"> <li>Added hash of Issuer-signed part and Disclosures in KB-JWT</li> <li>Fix minor issuesOAuth Security Workshop 2022 insome examples</li> <li>Added IANA media type registration requestTrondheim, Norway.</t> </section> </back> <!-- [rfced] Please let us know if any changes are needed for theJSON Serialization</li> <li>More precise wording around storing artifacts with sensitive data</li> <li>The claim name <tt>_sd</tt> or <tt>...</tt> must notfollowing: a) The following terms appear to be used inconsistently ina disclosure.</li> <li>Added JWT claims registration requests to IANA</li> <li>Ensure claims that control validity are checked after decoding payload</li> <li>Restructure sections around data formats and Example 1</li> <li>Update JSON Serialization to remove the kb_jwt member and allowthis document. Please let us know which form is preferred. Selective Disclosure for JWTs (SD-JWT) / Selectively Disclosable JWT (SD-JWT) b) holder (4 instances) / Holder also allowing thedisclosures to be conveyed elsewhere</li> <li>Expand the Enveloping SD-JWTs sectionholder toalso discuss enveloping JSON serialized SD-JWTs</li> </ul> <t>-05</t> <ul spacing="compact"> <li>Consolidate processing rules for Holder and Verifier</li> <li>Add support for selective disclosurereveal each ofarray elements.</li> <li>Consolidate SD-JWT terminology and format</li> <li>Use the term Key Binding rather than Holder Binding</li> <li>Defined the structurethose nationalities With this set of disclosures, theKey Binding JWT</li> <li>Added a JWS JSON Serialization</li> <li>Added initial IANA media type and structured suffix registration requests</li> <li>Added recommendation for explicit typing of SD-JWTs</li> <li>Added considerations around forwarding credentials</li> <li>Removed Example 2b and mergedholder could include thedemo of decoy digests into Example 2a</li> <li>Improved example for allowed variations in Disclosures</li> <li>Added some text todisclosure theAbstract and Introductionholder would also need tobe more inclusive of JWS with JSON</li> <li>Added some security considerations text about the scope of the Key Binding JWT</li> <li>Aligned examples structure and used the term input JWT Claims Set</li> <li>Replacedinclude thegeneral SD-JWT VC exampledisclosure withone based on Person Identification Data (PID) from the European Digital Identity Wallet Architecture and Reference Framework</li> <li>Added/clarified some privacy considerations in Confidentiality during Transport</li> <li>No longer recommendinghash holder is aclaim name for enveloped SD-JWTs</li> <li>Mention prospective future PQ algs for JWS</li> <li>Include the publicmilitary member or may have a substance use disorder. c) keyin the draft, which can be used to verify the issuer signature examples</li> <li>Clarifybinding (2 instances) / Key Binding 206: cryptographic key binding that<tt>_sd_alg</tt>canonlybeat the top level of the SD-JWT payload</li> <li>Externalized the SD-JWT library that generates examples</li> <li>Attemptpresented toimprove description of security properties</li> </ul> <t>-04</t> <ul spacing="compact"> <li>Improve description of processing of disclosures</li> </ul> <t>-03</t> <ul spacing="compact"> <li>Clarify that other specifications may define enveloping multiple Combined Formats for Presentation</li> <li>Add an example of W3C vc-data-model that uses a JSON-LD object as the claims set</li> <li>Clarify requirements for the combined formats for issuanceandpresentation</li> <li>Added overview of the Security Considerations section</li> <li>Enhanced examples in the Privacy Considerations section</li> <li>Allowverified 2437: Verifier or even forrecursive disclosures</li> <li>Discussion on holder binding and privacy of stored credentials</li> <li>Add some context about SD-JWT being general-purpose despite beingeach session with aproductVerifier. New key binding d) disclosure (35 instances) / Disclosure (251 instances) --> <!-- [rfced] Please review the "Inclusive Language" portion of theOAuth WG</li> <li>More explicitly say that SD-JWTs have to be signed asymmetrically (no MAConline Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> andno <tt>none</tt>)</li> <li>Make sha-256 the default hash algorithm,let us know ifthe hash alg claim is omitted</li> <li>Use ES256 insteadany changes are needed. Updates ofRS256this nature typically result inexamples</li> <li>Rename and move the c14n challenges section to an appendix</li> <li>A bitmorein security considerationsprecise language, which is helpful forChoice of a Hash Algorithm (1st & 2nd preimage resistant andreaders. Note that our script did notmajorly truncated)</li> <li>Remove the notational figures from the Concepts section</li> <li>Change salt to always be a string (rather thanflag anyJSON type)</li> <li>Fix the Document History (which had a premature list for -03)</li> </ul> <t>-02</t> <ul spacing="compact"> <li>Disclosures are now delivered not as a JWTwords in particular, but this should still be reviewed asseparate base64url-encoded JSON objects.</li> <li>In the SD-JWT, digests are collected undera<tt>_sd</tt> claim per level.</li> <li>Terms "II-Disclosures" and "HS-Disclosures" are replaced with "Disclosures".</li> <li>Holder Binding is now separate from delivering the Disclosures and implemented, if required, with a separate JWT.</li> <li>Examples updated and modified to properly explain the specifics of the new SD-JWT format.</li> <li>Examples are now pulled in from the examples directory, not inlined.</li> <li>Updated and automated the W3C VC example.</li> <li>Added examples with multibyte characters to show that the specification and demo code work well with UTF-8.</li> <li>reverted back to hash alg from digest derivation alg (renamed to <tt>_sd_alg</tt>)</li> <li>reformatted</li> </ul> <t>-01</t> <ul spacing="compact"> <li>introduced blinded claim names</li> <li>explained why JSON-encoding of values is needed</li> <li>explained merging algorithm ("processing model")</li> <li>generalized hash alg to digest derivation alg which also enables HMAC to calculate digests</li> <li><tt>_sd_hash_alg</tt> renamed to <tt>sd_digest_derivation_alg</tt></li> <li>Salt/Value Container (SVC) renamed to Issuer-Issued Disclosures (II-Disclosures)</li> <li>SD-JWT-Release (SD-JWT-R) renamed to Holder-Selected Disclosures (HS-Disclosures)</li> <li><tt>sd_disclosure</tt> in II-Disclosures renamed to <tt>sd_ii_disclosures</tt></li> <li><tt>sd_disclosure</tt> in HS-Disclosures renamed to <tt>sd_hs_disclosures</tt></li> <li>clarified relationship between <tt>sd_hs_disclosure</tt> and SD-JWT</li> <li>clarified combined formats for issuance and presentation</li> <li>clarified security requirements for blinded claim names</li> <li>improved description of Holder Binding security considerations - especially around the usage of "alg=none".</li> <li>updated examples</li> <li>text clarifications</li> <li>fixed <tt>cnf</tt> structure in examples</li> <li>added feature summary</li> </ul> <t>-00</t> <ul spacing="compact"> <li>Upload as draft-ietf-oauth-selective-disclosure-jwt-00</li> </ul> <t>[[ pre Working Group Adoption: ]]</t> <t>-02</t> <ul spacing="compact"> <li>Added acknowledgements</li> <li>Improved Security Considerations</li> <li>Stressed entropy requirements for salts</li> <li>Python reference implementation clean-up and refactoring</li> <li><tt>hash_alg</tt> renamed to <tt>_sd_hash_alg</tt></li> </ul> <t>-01</t> <ul spacing="compact"> <li>Editorial fixes</li> <li>Added <tt>hash_alg</tt> claim</li> <li>Renamed <tt>_sd</tt> to <tt>sd_digests</tt> and <tt>sd_release</tt></li> <li>Added descriptions on Holder Binding - more work to do</li> <li>Clarify that signing the SD-JWT is mandatory</li> </ul> <t>-00</t> <ul spacing="compact"> <li>Renamed to SD-JWT (focus on JWT instead of JWS since signature is optional)</li> <li>Make Holder Binding optional</li> <li>Rename proof to release, since when there is no signature, the term "proof" can be misleading</li> <li>Improved the structure of the description</li> <li>Described verification steps</li> <li>All examples generated from python demo implementation</li> <li>Examples for structured objects</li> </ul> </section> </back>best practice. --> </rfc>