rfc9901.original.xml   rfc9901.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process
or - mmark.miek.nl" --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do cName="draft-ietf-oauth-selective-disclosure-jwt-22" number="9901" updates="" ob
cName="draft-ietf-oauth-selective-disclosure-jwt-22" submissionType="IETF" categ soletes="" consensus="true" symRefs="true" sortRefs="true" submissionType="IETF"
ory="std" xml:lang="en" indexInclude="true"> category="std" xml:lang="en" tocInclude="true">
<front> <front>
<title abbrev="SD-JWT">Selective Disclosure for JWTs (SD-JWT)</title><seriesInfo <title abbrev="SD-JWT">Selective Disclosure for JSON Web Tokens (SD-JWTs)</tit
value="draft-ietf-oauth-selective-disclosure-jwt-22" stream="IETF" status="stan le>
dard" name="Internet-Draft"/>
<author initials="D." surname="Fett" fullname="Daniel Fett"><organization>Authle <!-- [rfced] Document title: We expanded "JWT" in the document title. Please l
te</organization><address><postal><street/> et us know if you have any concerns.
</postal><email>mail@danielfett.de</email>
<uri>https://danielfett.de/</uri> Original:
</address></author><author initials="K." surname="Yasuda" fullname="Kristina Yas Selective Disclosure for JWTs (SD-JWT)
uda"><organization>Keio University</organization><address><postal><street/>
</postal><email>kristina@sfc.keio.ac.jp</email> Currently:
</address></author><author initials="B." surname="Campbell" fullname="Brian Camp Selective Disclosure for JSON Web Tokens (SD-JWTs) -->
bell"><organization>Ping Identity</organization><address><postal><street/>
</postal><email>bcampbell@pingidentity.com</email> <seriesInfo name="RFC" value="9901"/>
</address></author><date/>
<area>Security</area> <author initials="D." surname="Fett" fullname="Daniel Fett">
<workgroup>Web Authorization Protocol</workgroup> <organization>Authlete</organization>
<keyword>security</keyword> <address>
<keyword>oauth2</keyword> <email>mail@danielfett.de</email>
<uri>https://danielfett.de/</uri>
</address>
</author>
<author initials="K." surname="Yasuda" fullname="Kristina Yasuda">
<organization>Keio University</organization>
<address>
<email>kristina@sfc.keio.ac.jp</email>
</address>
</author>
<author initials="B." surname="Campbell" fullname="Brian 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> <abstract>
<t>This specification defines a mechanism for the selective disclosure of indivi dual elements of a JSON data structure used as the payload of a JSON Web Signatu re (JWS). <t>This specification defines a mechanism for the selective disclosure of indivi dual elements of a JSON data structure used as the payload of a JSON Web Signatu re (JWS).
The primary use case is the selective disclosure of JSON Web Token (JWT) claims. </t> The primary use case is the selective disclosure of JSON Web Token (JWT) claims. </t>
</abstract> </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> </front>
<middle> <middle>
<section anchor="Introduction"><name>Introduction</name> <section anchor="Introduction"><name>Introduction</name>
<t>JSON data for exchange between systems is often secured against modification <t>The exchange of JSON data between systems is often secured against modificati
using JSON Web Signatures (JWS) <xref target="RFC7515"/>. on using JSON Web Signatures (JWSs) <xref target="RFC7515"/>.
A popular application of JWS is JSON Web Token (JWT) <xref target="RFC7519"/>, a A popular application of JWS is the JSON Web Token (JWT) <xref target="RFC7519"/
format that is often used to represent a user's identity. >, 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 examp le, is a JWT containing the user's claims created by the server for consumption by a relying party. An ID Token as defined in OpenID Connect <xref target="OpenID.Core"/>, for examp le, 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> 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. <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). In this model, a JWT containing many claims is issued to an intermediate party, who holds the JWT (the Holder).
The Holder can then present the JWT to different verifying parties (Verifiers), that each may only require a subset of the claims in the JWT. The Holder can then present the JWT to different verifying parties (Verifiers) t hat 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 birth date. For example, the JWT may contain claims representing both an address and a birth date.
The Holder may elect to disclose only the address to one Verifier, and only the birthdate to a different Verifier.</t> 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 deman d a mechanism enabling selective disclosure of data elements while ensuring that Verifiers can still check the authenticity of the data provided. <t>Privacy principles of minimal disclosure in conjunction with this model deman d a mechanism enabling selective disclosure of data elements while ensuring that Verifiers can still check the authenticity of the data provided.
This specification, Selective Disclosure for JSON Web Tokens (SD-JWT), defines s uch a mechanism for JSON payloads of JSON Web Signatures (JWS), with JWTs as the primary use case.</t> This specification defines such a mechanism for JSON payloads of JWSs, with JWTs as the primary use case.</t>
<t>SD-JWT is based on an approach called "salted hashes": For any data element t hat 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. <t>SD-JWT is based on an approach called "salted hashes": For any data element t hat 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 t he cleartext of those claims it wants to disclose. For presentation to a Verifier, the Holder sends the signed payload along with t he 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. 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 ele ments, an additional salt value is used when creating the digest and sent along with the cleartext when disclosing it.</t> To ensure that Verifiers cannot guess cleartext values of non-disclosed data ele ments, 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 bindin g the SD-JWT to a key under the control of the Holder (Key Binding). <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 bindin g 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. 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-speci fic data, herein defined as the Key Binding JWT. It usually does so by signing over a data structure containing transaction-speci fic data, herein defined as the Key Binding JWT.
An SD-JWT with a Key Binding JWT is called SD-JWT+KB in this specification.</t> An SD-JWT with a Key Binding JWT is called "SD-JWT+KB" in this specification.</t >
<section anchor="feature-summary"><name>Feature Summary</name> <section anchor="feature-summary"><name>Feature Summary</name>
<t>This specification defines two primary data formats:</t> <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 disclo sures, enabling selective disclosure of portions of the JWS payload. It comprise s the following:</t> <li><t>SD-JWT is a composite structure, consisting of a JWS plus optional disclo sures, enabling selective disclosure of portions of the JWS payload. It comprise s the following:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>A format for enabling selective disclosure in nested JSON data structures, <li>A format for enabling selective disclosure in nested JSON data structures,
supporting selectively disclosable object properties (name/value pairs) and arra supporting selectively disclosable object properties (name/value pairs) and arra
y elements</li> y elements.</li>
<li>A format for encoding the selectively disclosable data items</li> <li>A format for encoding the selectively disclosable data items.</li>
<li>A format extending the JWS Compact Serialization, allowing for the combined <li>A format extending the JWS Compact Serialization, allowing for the combined
transport of the Issuer-signed JSON data structure and the disclosable data item s</li> transport of the Issuer-signed JSON data structure and the disclosable data item s.</li>
<li>An alternate format extending the JWS JSON Serialization, also allowing for <li>An alternate format extending the JWS JSON Serialization, also allowing for
transport of the Issuer-signed JSON data structure and disclosure data</li> transport of the Issuer-signed JSON data structure and disclosure data.</li>
</ul></li> </ul></li>
<li><t>SD-JWT+KB is a composite structure of an SD-JWT and a cryptographic key b inding that can be presented to and verified by the Verifier. It comprises the f ollowing:</t> <li><t>SD-JWT+KB is a composite structure of an SD-JWT and a cryptographic key b inding that can be presented to and verified by the Verifier. It comprises the f ollowing:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>A mechanism for associating an SD-JWT with a key pair</li> <li>A mechanism for associating an SD-JWT with a key pair.</li>
<li>A format for a Key Binding JWT (KB-JWT) that allows proof of possession of t he private key of <li>A format for a Key Binding JWT (KB-JWT) that allows proof of possession of t he private key of
the associated key pair</li> the associated key pair.</li>
<li>A format extending the SD-JWT format for the combined transport of the SD-JW T <li>A format extending the SD-JWT format for the combined transport of the SD-JW T
and the KB-JWT</li> and the KB-JWT.</li>
</ul></li> </ul></li>
</ol> </ol>
</section> </section>
<section anchor="conventions-and-terminology"><name>Conventions and Terminology< /name> <section anchor="conventions-and-terminology"><name>Conventions and Terminology< /name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and ",
only when, they "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t><strong>Base64url</strong> denotes the URL-safe base64 encoding without paddi ng defined in <t><strong>Base64url</strong> denotes the URL-safe base64 encoding without paddi ng defined in
Section 2 of <xref target="RFC7515"/>.</t> <xref target="RFC7515" section="2"/>.</t>
<t>Throughout the document the term "claims" refers generally to both <t>Throughout this document, the term "claims" refers generally to
object properties (name/value pairs) as well as array elements.</t> object properties (name/value pairs) as well as array elements.</t>
<dl spacing="compact"> <dl spacing="normal" newline="true">
<dt>Selective Disclosure:</dt> <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> <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> <dt>Selectively Disclosable JWT (SD-JWT):</dt>
<dd>A composite structure, consisting of an Issuer-signed JWT (JWS, <xref target <dd>A composite structure, consisting of an Issuer-signed JWT (JWS; see <xref ta
="RFC7515"/>) and zero or more Disclosures, which rget="RFC7515"/>) and zero or more Disclosures, which
supports selective disclosure as defined in this document. It can contain both r supports selective disclosure as defined in this document. It can contain both r
egular claims and digests of selectively-disclosable claims.</dd> egular claims and digests of selectively disclosable claims.</dd>
<dt>Disclosure:</dt> <dt>Disclosure:</dt>
<dd>A base64url-encoded string of a JSON array that contains a salt, a claim nam e (present when the claim is a name/value pair and absent when the claim is an a rray element), and a claim value. The Disclosure is used to calculate a digest f or the respective claim. The term Disclosure refers to the whole base64url-encod ed string.</dd> <dd>A base64url-encoded string of a JSON array that contains a salt, a claim nam e (present when the claim is a name/value pair and absent when the claim is an a rray element), and a claim value. The Disclosure is used to calculate a digest f or the respective claim. The term Disclosure refers to the whole base64url-encod ed string.</dd>
<dt>Key Binding:</dt> <dt>Key Binding:</dt>
<dd>Ability of the Holder to prove possession of an SD-JWT by proving <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 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 r eference to this public key).</dd> the public key corresponding to the private key controlled by the Holder (or a r eference to this public key).</dd>
<dt>Key Binding JWT (KB-JWT):</dt> <dt>Key Binding JWT (KB-JWT):</dt>
<dd>A Key Binding JWT is said to "be tied to" a particular SD-JWT when its paylo ad <dd>A Key Binding JWT is said to "be tied to" a particular SD-JWT when its paylo ad
is signed using the key included in the SD-JWT payload, and the KB-JWT contains 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 <xr ef target="kb-jwt"/>.</dd> a hash of the SD-JWT in its <tt>sd_hash</tt> claim. Its format is defined in <xr ef target="kb-jwt"/>.</dd>
<dt>Selectively Disclosable JWT with Key Binding (SD-JWT+KB):</dt> <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 th at SD-JWT.</dd> <dd>A composite structure, comprising an SD-JWT and a Key Binding JWT tied to th at SD-JWT.</dd>
<dt>Processed SD-JWT Payload</dt> <dt>Processed SD-JWT Payload:</dt>
<dd>The JSON object resulting from verification and processing of the Issuer-sig ned SD-JWT, <dd>The JSON object resulting from verification and processing of the Issuer-sig ned SD-JWT,
with digest placeholders replaced by the corresponding values from the Disclosur es.</dd> with digest placeholders replaced by the corresponding values from the Disclosur es.</dd>
<dt>Issuer:</dt> <dt>Issuer:</dt>
<dd>An entity that creates SD-JWTs.</dd> <dd>An entity that creates SD-JWTs.</dd>
<dt>Holder:</dt> <dt>Holder:</dt>
<dd>An entity that received SD-JWTs from the Issuer and has control over them. I n the context of this document, the term may refer to the actual user, the suppo rting hardware and software in their possession, or both.</dd> <dd>An entity that received SD-JWTs from the Issuer and has control over them. I n the context of this document, the term may refer to the actual user, the suppo rting hardware and software in their possession, or both.</dd>
<dt>Verifier:</dt> <dt>Verifier:</dt>
<dd>An entity that requests, checks, and extracts the claims from an SD-JWT with its respective Disclosures.</dd> <dd>An entity that requests, checks, and extracts the claims from an SD-JWT with its respective Disclosures.</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="flow-diagram"><name>Flow Diagram</name> <section anchor="flow-diagram"><name>Flow Diagram</name>
<figure><name>SD-JWT Issuance and Presentation Flow <figure><name>SD-JWT Issuance and Presentation Flow</name>
</name> <artwork><![CDATA[
<sourcecode type="ascii-art"><![CDATA[ +------------+ +------------+
| | | |
| Issuer | | Issuer |
| | | |
+------------+ +------------+
| |
Issues SD-JWT Issues SD-JWT
including all Disclosures including all Disclosures
| |
v v
+------------+ +------------+
skipping to change at line 163 skipping to change at line 186
| |
v v
+-------------+ +-------------+
| |+ | |+
| Verifiers ||+ | Verifiers ||+
| ||| | |||
+-------------+|| +-------------+||
+-------------+| +-------------+|
+-------------+ +-------------+
]]> ]]>
</sourcecode> </artwork>
</figure> </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>
<section anchor="concepts"><name>Concepts</name> <section anchor="concepts"><name>Concepts</name>
<t>This section describes SD-JWTs with their respective Disclosures and Key Bind ing at a <t>This section describes SD-JWTs with their respective Disclosures and Key Bind ing at a
conceptual level, abstracting from the data formats described in <xref target="d ata_formats"/>.</t> conceptual level, abstracting from the data formats described in <xref target="d ata_formats"/>.</t>
<section anchor="sd-jwt-and-disclosures"><name>SD-JWT and Disclosures</name> <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 digest s over the selectively disclosable claims with the Disclosures outside the docum ent. Disclosures can be omitted without breaking the signature, and modifying th em can be detected. Selectively disclosable claims can be individual object prop erties (name/value pairs) or array elements.</t> <t>An SD-JWT, at its core, is a digitally signed JSON document containing digest s over the selectively disclosable claims with the Disclosures outside the docum ent. Disclosures can be omitted without breaking the signature, and modification s to them can be detected. Selectively disclosable claims can be individual obje ct properties (name/value pairs) or array elements.</t>
<t>Each digest value ensures the integrity of, and maps to, the respective Discl osure. 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="d ata_formats"/>. <t>Each digest value ensures the integrity of, and maps to, the respective Discl osure. 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="d ata_formats"/>.
When presenting an SD-JWT to a Verifier, the Holder only includes the Disclosure s for the claims that it wants to reveal to that Verifier.</t> When presenting an SD-JWT to a Verifier, the Holder only includes the Disclosure s for the claims that it wants to reveal to that Verifier.</t>
<t>An SD-JWT MAY also contain cleartext claims that are always disclosed to the Verifier.</t> <t>An SD-JWT <bcp14>MAY</bcp14> also contain cleartext claims that are always di sclosed to the Verifier.</t>
</section> </section>
<section anchor="disclosing-to-a-verifier"><name>Disclosing to a Verifier</name> <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 pa rt of the SD-JWT.</t> <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 pa rt of the SD-JWT.</t>
</section> </section>
<section anchor="optional-key-binding"><name>Optional Key Binding</name> <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 c <t>Key Binding is an optional feature. When Key Binding is required by the use c
ase, the SD-JWT MUST contain information about the key material controlled by th ase, the SD-JWT <bcp14>MUST</bcp14> contain information about the key material c
e Holder.</t> ontrolled by the Holder.</t>
<blockquote><t>Note: How the public key is included in SD-JWT is described in <x <aside><t>Note: How the public key is included in SD-JWT is described in <xref t
ref target="key_binding"/>.</t> arget="key_binding"/>.</t>
</blockquote><t>When a Verifier requires Key Binding, the Holder presents an SD- </aside>
JWT+KB, consisting of an SD-JWT as well as a Key Binding JWT tied to that SD-JWT
. <t>When a Verifier requires Key Binding, the Holder presents an SD-JWT+KB, consi
sting 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> The Key Binding JWT encodes a signature by the Holder's private key over</t>
<ul spacing="compact"> <ul spacing="normal">
<li>a hash of the SD-JWT,</li> <li>a hash of the SD-JWT,</li>
<li>a nonce to ensure the freshness of the signature, and</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> <li>an audience value to indicate the intended Verifier for the document.</li>
</ul> </ul>
<t>Details of the format of Key Binding JWTs are described in <xref target="kb-j wt"/>.</t> <t>Details of the format of Key Binding JWTs are described in <xref target="kb-j wt"/>.</t>
</section> </section>
<section anchor="verification"><name>Verification</name> <section anchor="verification"><name>Verification</name>
<t>At a high level, the Verifier</t> <t>At a high level, the Verifier</t>
<ul spacing="compact"> <ul spacing="normal">
<li>receives either an SD-JWT or an SD-JWT+KB from the Holder,</li> <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) us ing the Issuer's public key,</li> <li>verifies the signature on the SD-JWT (or the SD-JWT inside the SD-JWT+KB) us ing the Issuer's public key,</li>
<li>verifies the signature on the KB-JWT using the public key included (or refer enced) in the SD-JWT, if the Verifier's policy requires Key Binding, and</li> <li>verifies the signature on the KB-JWT using the public key included (or refer enced) 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 tha t each digest is contained in the SD-JWT.</li> <li>calculates the digests over the Holder-Selected Disclosures and verifies tha t each digest is contained in the SD-JWT.</li>
</ul> </ul>
<t>The detailed algorithm is described in <xref target="verifier_verification"/> .</t> <t>The detailed algorithm is described in <xref target="verifier_verification"/> .</t>
</section> </section>
</section> </section>
<section anchor="data_formats"><name>SD-JWT and SD-JWT+KB Data Formats</name> <section anchor="data_formats"><name>SD-JWT and SD-JWT+KB Data Formats</name>
<t>An SD-JWT is composed of</t> <t>An SD-JWT is composed of</t>
<ul spacing="compact"> <ul spacing="normal">
<li>an Issuer-signed JWT, and</li> <li>an Issuer-signed JWT, and</li>
<li>zero or more Disclosures.</li> <li>zero or more Disclosures.</li>
</ul> </ul>
<t>An SD-JWT+KB is composed of</t> <t>An SD-JWT+KB is composed of</t>
<ul spacing="compact"> <ul spacing="normal">
<li>an SD-JWT (i.e., an Issuer-signed JWT and zero or more Disclosures), and</li > <li>an SD-JWT (i.e., an Issuer-signed JWT and zero or more Disclosures), and</li >
<li>a Key Binding JWT.</li> <li>a Key Binding JWT.</li>
</ul> </ul>
<t>The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in <t>The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in Sect
<xref target="iss-signed-jwt"/>, <xref target="creating_disclosures"/>, and <xre ions
f target="kb-jwt"/> respectively.</t> <xref target="iss-signed-jwt" format="counter"/>, <xref target="creating_disclos
ures" format="counter"/>, and <xref target="kb-jwt" format="counter"/>, respecti
vely.</t>
<t>The compact serialized format for the SD-JWT is the concatenation of each par t delineated with a single tilde ('~') character as follows:</t> <t>The compact serialized format for the SD-JWT is the concatenation of each par t delineated with a single tilde ('~') character as follows:</t>
<artwork><![CDATA[<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclos <artwork><![CDATA[
ure N>~ <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~
]]> ]]>
</artwork> </artwork>
<t>The order of the concatenated parts MUST be the Issuer-signed JWT,
<t>The order of the concatenated parts <bcp14>MUST</bcp14> be the Issuer-signed
JWT,
a tilde character, zero or more Disclosures each followed by a tilde character, a tilde character, zero or more Disclosures each followed by a tilde character,
and lastly the optional Key Binding JWT. and lastly the optional Key Binding JWT.
In the case that there is no Key Binding JWT, the last element MUST be an empty In the case that there is no Key Binding JWT, the last element <bcp14>MUST</bcp1
string and the last separating tilde character MUST NOT be omitted.</t> 4> be an empty
string and the last separating tilde character <bcp14>MUST NOT</bcp14> be omitte
d.</t>
<t>The serialized format for an SD-JWT+KB extends the SD-JWT format by concatena ting a Key Binding JWT.</t> <t>The serialized format for an SD-JWT+KB extends the SD-JWT format by concatena ting a Key Binding JWT.</t>
<artwork><![CDATA[<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclos <artwork><![CDATA[
ure N>~<KB-JWT> <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~<KB-JWT>
]]> ]]>
</artwork> </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 charact
ers:
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~<KB-JWT>
(512): Warning: Too long line found (L786), 2 characters longer than 72 charact
ers:
["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 i s present <t>The two formats can be distinguished by the final <tt>~</tt> character that i s present
on an SD-JWT. A Verifier that expects an SD-JWT MUST verify that the final on an SD-JWT. A Verifier that expects an SD-JWT <bcp14>MUST</bcp14> verify that
tilde-separated component is empty. A Verifier that expects an SD-JWT+KB MUST v the final
erify tilde-separated component is empty. A Verifier that expects an SD-JWT+KB <bcp14
>MUST</bcp14> verify
that its final tilde-separated component is a valid KB-JWT.</t> that its final tilde-separated component is a valid KB-JWT.</t>
<t>The Disclosures are linked to the Issuer-signed JWT through the <t>The Disclosures are linked to the Issuer-signed JWT through the
digest values included therein.</t> 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 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>When presenting to a Verifier, the Holder sends only the selected set of the Disclosures in the SD-JWT.</t>
<t>The Holder MAY send any subset of the Disclosures to the Verifier, i.e., <t>The Holder <bcp14>MAY</bcp14> send any subset of the Disclosures to the Verif ier, i.e.,
none, some, or all Disclosures. For data that the Holder does not want to reveal none, some, or all Disclosures. For data that the Holder does not want to reveal
to the Verifier, the Holder MUST NOT send Disclosures or reveal the salt values to the Verifier, the Holder <bcp14>MUST NOT</bcp14> send Disclosures or reveal t
in any he salt values in any
other way. A Holder MUST NOT send a Disclosure that was not included in the issu other way. A Holder <bcp14>MUST NOT</bcp14> send a Disclosure that was not inclu
ed ded in the issued
SD-JWT or send a Disclosure more than once.</t> SD-JWT or send a Disclosure more than once.</t>
<t>To further illustrate the SD-JWT format, the following examples show a few di fferent <t>To further illustrate the SD-JWT format, the following examples show a few di fferent
SD-JWT permutations, both with and without various constituent parts.</t> SD-JWT permutations, both with and without various constituent parts.</t>
<t>An SD-JWT without Disclosures:</t> <t>An SD-JWT without Disclosures:</t>
<artwork><![CDATA[<Issuer-signed JWT>~ <artwork><![CDATA[
<Issuer-signed JWT>~
]]> ]]>
</artwork> </artwork>
<t>An SD-JWT with Disclosures:</t> <t>An SD-JWT with Disclosures:</t>
<artwork><![CDATA[<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~ <artwork><![CDATA[
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~
]]> ]]>
</artwork> </artwork>
<t>An SD-JWT+KB without Disclosures:</t> <t>An SD-JWT+KB without Disclosures:</t>
<artwork><![CDATA[<Issuer-signed JWT>~<KB-JWT> <artwork><![CDATA[
<Issuer-signed JWT>~<KB-JWT>
]]> ]]>
</artwork> </artwork>
<t>An SD-JWT+KB with Disclosures:</t> <t>An SD-JWT+KB with Disclosures:</t>
<artwork><![CDATA[<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~<KB-JWT> <artwork><![CDATA[
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~<KB-JWT>
]]> ]]>
</artwork> </artwork>
<t>As an alternative illustration of the SD-JWT format, ABNF <xref target="RFC52 34"/> for the <t>As an alternative illustration of the SD-JWT format, ABNF <xref target="RFC52 34"/> for the
SD-JWT, SD-JWT+KB, and various constituent parts is provided here (for those who celebrate):</t> SD-JWT, SD-JWT+KB, and various constituent parts is provided here (for those who celebrate):</t>
<sourcecode type="abnf"><![CDATA[ALPHA = %x41-5A / %x61-7A ; A-Z / a-z <sourcecode type="abnf"><![CDATA[
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9 DIGIT = %x30-39 ; 0-9
BASE64URL = 1*(ALPHA / DIGIT / "-" / "_") BASE64URL = 1*(ALPHA / DIGIT / "-" / "_")
JWT = BASE64URL "." BASE64URL "." BASE64URL JWT = BASE64URL "." BASE64URL "." BASE64URL
DISCLOSURE = BASE64URL DISCLOSURE = BASE64URL
SD-JWT = JWT "~" *(DISCLOSURE "~") SD-JWT = JWT "~" *(DISCLOSURE "~")
KB-JWT = JWT KB-JWT = JWT
SD-JWT-KB = SD-JWT KB-JWT SD-JWT-KB = SD-JWT KB-JWT
]]> ]]>
</sourcecode> </sourcecode>
<section anchor="iss-signed-jwt"><name>Issuer-signed JWT</name> <section anchor="iss-signed-jwt"><name>Issuer-Signed JWT</name>
<t>An SD-JWT has a JWT component that MUST be signed using the Issuer's private <!-- [rfced] Regarding the use of font styling (i.e., <tt> and <strong>), please
key. It MUST NOT use the <tt>none</tt> algorithm.</t> review the questions below.
Note: For <tt>-related items, view the list here: https://www.rfc-editor.org/aut
hors/rfc9901tt.txt
a) May we update instances of <tt>none</tt> to "none" for increased clarity in t
he 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 m
arks in the text file. Is the goal of <tt> to indicate fixed-width font or to c
all attention to the various items?
Some similar text seems to be marked as both <sourcecode> and <tt>. Please revi
ew 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 that <bcp14>MUST</bcp14> be signed using the Is
suer's private
key. It <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> <t>The payload of an SD-JWT is a JSON object according to the following rules:</ t>
<ol spacing="compact"> <ol spacing="normal">
<li>The payload MAY contain the <tt>_sd_alg</tt> key described in <xref target=" <li>The payload <bcp14>MAY</bcp14> contain the <tt>_sd_alg</tt> key described in
hash_function_claim"/>.</li> <xref target="hash_function_claim"/>.</li>
<li>The payload MAY contain one or more digests of Disclosures to enable selecti <li>The payload <bcp14>MAY</bcp14> contain one or more digests of Disclosures to
ve disclosure of the respective claims, created and formatted as described in <x enable selective disclosure of the respective claims, created and formatted as
ref target="creating_disclosures"/>.</li> described in <xref target="creating_disclosures"/>.</li>
<li>The payload MAY contain one or more decoy digests to obscure the actual numb <li>The payload <bcp14>MAY</bcp14> contain one or more decoy digests to obscure
er of claims in the SD-JWT, created and formatted as described in <xref target=" the actual number of claims in the SD-JWT, created and formatted as described in
decoy_digests"/>.</li> <xref target="decoy_digests"/>.</li>
<li>The payload MAY contain one or more permanently disclosed claims.</li> <li>The payload <bcp14>MAY</bcp14> contain one or more permanently disclosed cla
<li>The payload MAY contain the Holder's public key(s) or reference(s) thereto, ims.</li>
as explained in <xref target="key_binding"/>.</li> <li>The payload <bcp14>MAY</bcp14> contain the Holder's public key(s) or referen
<li>The payload MAY contain further claims such as <tt>iss</tt>, <tt>iat</tt>, e ce(s) thereto, as explained in <xref target="key_binding"/>.</li>
tc. as defined or required by the application using SD-JWTs.</li> <li>The payload <bcp14>MAY</bcp14> contain further claims such as <tt>iss</tt>,
<li>The payload MUST NOT contain the claims <tt>_sd</tt> or <tt>...</tt> except <tt>iat</tt>, etc. as defined or required by the application using SD-JWTs.</li>
for the purpose of conveying digests as described in <xref target="embedding_obj <li>The payload <bcp14>MUST NOT</bcp14> contain the claims <tt>_sd</tt> or <tt>.
ect_properties"/> and <xref target="embedding_array_elements"/> respectively bel ..</tt> except for the purpose of conveying digests as described in Sections <xr
ow.</li> ef target="embedding_object_properties" format="counter"/> and <xref target="emb
edding_array_elements" format="counter"/>, respectively.</li>
</ol> </ol>
<t>The same digest value MUST NOT appear more than once in the SD-JWT.</t> <t>The same digest value <bcp14>MUST NOT</bcp14> appear more than once in the SD
<t>Application and profiles of SD-JWT SHOULD be explicitly typed. See <xref targ -JWT.</t>
et="explicit_typing"/> for more details.</t> <t>Application and profiles of SD-JWT <bcp14>SHOULD</bcp14> be explicitly typed.
<t>It is the Issuer who decides which claims are selectively disclosable by the See <xref target="explicit_typing"/> for more details.</t>
Holder and which are not. Claims MAY be included as plaintext as well, e.g., if <t>It is the Issuer who decides which claims are selectively disclosable by the
hiding the particular claims from the Verifier is not required in the intended u Holder and which are not. Claims <bcp14>MAY</bcp14> be included as plaintext as
se case. See <xref target="sd-validity-claims"/> for considerations on making va well, e.g., if hiding the particular claims from the Verifier is not required in
lidity-controlling claims such as <tt>exp</tt> selectively disclosable.</t> the intended use case. See <xref target="sd-validity-claims"/> for consideratio
ns on making validity-controlling claims such as <tt>exp</tt> selectively disclo
sable.</t>
<t>Claims that are not selectively disclosable are included in the SD-JWT in pla intext just as they would be in any other JSON structure.</t> <t>Claims that are not selectively disclosable are included in the SD-JWT in pla intext just as they would be in any other JSON structure.</t>
<section anchor="hash_function_claim"><name>Hash Function Claim</name> <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 <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, th is claim MUST the digests as described in <xref target="creating_disclosures"/>. When used, th is claim <bcp14>MUST</bcp14>
appear at the top level of the SD-JWT payload. It appear at the top level of the SD-JWT payload. It
MUST NOT be used in any object nested within the payload. If the <tt>_sd_alg</t <bcp14>MUST NOT</bcp14> be used in any object nested within the payload. If the
t> <tt>_sd_alg</tt>
claim is not present at the top level, a default value of <tt>sha-256</tt> MUST claim is not present at the top level, a default value of <tt>sha-256</tt> <bcp1
be used.</t> 4>MUST</bcp14> be used.</t>
<t>This claim value is a case-sensitive string with the hash algorithm identifie r. <t>This claim value is a case-sensitive string with the hash algorithm identifie r.
The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name The hash algorithm identifier <bcp14>MUST</bcp14> be a hash algorithm value from
String" column in the IANA "Named Information Hash Algorithm" registry the "Hash Name
<xref target="IANA.Hash.Algorithms"/> or a value defined in another specificatio String" column in the "Named Information Hash Algorithm Registry"
n and/or <xref target="Hash.Algs"/> or a value defined in another specification and/or
profile of this specification.</t> profile of this specification.</t>
<t>To promote interoperability, implementations MUST support the <tt>sha-256</tt > hash <t>To promote interoperability, implementations <bcp14>MUST</bcp14> support the <tt>sha-256</tt> hash
algorithm.</t> algorithm.</t>
<t>See <xref target="security_considerations"/> for requirements regarding entro py of the salt, <t>See <xref target="security_considerations"/> for requirements regarding entro py of the salt,
minimum length of the salt, and choice of a hash algorithm.</t> minimum length of the salt, and choice of a hash algorithm.</t>
</section> </section>
<section anchor="key_binding"><name>Key Binding</name> <section anchor="key_binding"><name>Key Binding</name>
<t>If the Issuer wants to enable Key Binding, it includes a public key <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"/>. 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 in Section 3.2 of <xref target= "RFC7800"/>, is The <tt>jwk</tt> confirmation method, as defined in <xref target="RFC7800" secti on="3.2"/>, is
suggested for doing so, however, other confirmation methods can be used.</t> suggested for doing so, however, other confirmation methods can be used.</t>
<blockquote><t>Note that, as was stated in <xref target="RFC7800"/>,
<aside><t>Note that, as was stated in <xref target="RFC7800"/>,
if an application needs to represent multiple proof-of-possession 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 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-posses claim names, in addition to <tt>cnf</tt>, to hold the additional proof-of-posses
sion key information.</t> sion key information.</t></aside>
</blockquote><t>It is out of the scope of this document to describe how the Hold
er key pair is <!-- [rfced] Sections 4.1.2 and subsequent: We have changed instances of <blockq
established. For example, the Holder MAY create a key pair and provide a public uote> to <aside> throughout. Please review and let us know if any updates are n
key to the Issuer, eeded.
the Issuer MAY create the key pair for the Holder, or
Holder and Issuer MAY use pre-established key material.</t> Per <https://authors.ietf.org/en/rfcxml-vocabulary#aside>, the
<blockquote><t>Note: The examples throughout this document use the <tt>cnf</tt> <aside> element is defined as "a container for content that is
claim with the <tt>jwk</tt> member to include 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 Holder <bcp14>MAY</bcp14> create a key pair and pr
ovide a public key to the Issuer,
the Issuer <bcp14>MAY</bcp14> create the key pair for the Holder, or
Holder and Issuer <bcp14>MAY</bcp14> use pre-established key material.</t>
<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> the raw public key by value in SD-JWT.</t>
</blockquote></section> </aside></section>
</section> </section>
<section anchor="creating_disclosures"><name>Disclosures</name> <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> <t>Disclosures are created differently depending on whether a claim is an object property (name/value pair) or an array element.</t>
<ul spacing="compact"> <ul spacing="normal">
<li>For a claim that is an object property, the Issuer creates a Disclosure as d escribed in <xref target="disclosures_for_object_properties"/>.</li> <li>For a claim that is an object property, the Issuer creates a Disclosure as d escribed in <xref target="disclosures_for_object_properties"/>.</li>
<li>For a claim that is an array element, the Issuer creates a Disclosure as des cribed in <xref target="disclosures_for_array_elements"/>.</li> <li>For a claim that is an array element, the Issuer creates a Disclosure as des cribed in <xref target="disclosures_for_array_elements"/>.</li>
</ul> </ul>
<section anchor="disclosures_for_object_properties"><name>Disclosures for Object Properties</name> <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 Issuer MUST create a Disclosure as follows:</t> <t>For each claim that is an object property and that is to be made selectively disclosable, the Issuer <bcp14>MUST</bcp14> create a Disclosure as follows:</t>
<ul spacing="compact"> <ul spacing="normal">
<li><t>Create a JSON array of three elements in this order:</t> <li><t>Create a JSON array of three elements in the following order:</t>
<ol spacing="compact"> <ol spacing="normal">
<li>A salt value. MUST be a string. See <xref target="salt-entropy"/> for securi <li>A salt value. <bcp14>MUST</bcp14> be a string. See <xref target="salt-entrop
ty considerations. To achieve the recommended entropy of the salt, the Issuer ca y"/> for security considerations. To achieve the recommended entropy of the salt
n base64url-encode 128 bits of cryptographically secure random data, producing a , the Issuer can base64url-encode 128 bits of cryptographically secure random da
string. The salt value MUST be unique for each claim that is to be selectively ta, producing a string. The salt value <bcp14>MUST</bcp14> be unique for each cl
disclosed. The Issuer MUST NOT reveal the salt value to any party other than the aim that is to be selectively disclosed. The Issuer <bcp14>MUST NOT</bcp14> reve
Holder.</li> al 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. It MUS <li>The claim name, or key, as it would be used in a regular JWT payload. It <bc
T be a string and MUST NOT be <tt>_sd</tt>, <tt>...</tt>, or a claim name existi p14>MUST</bcp14> be a string and <bcp14>MUST NOT</bcp14> be <tt>_sd</tt>, <tt>..
ng in the object as a permanently disclosed claim.</li> .</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, a rrays, null, and objects.</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, a rrays, null, and objects.</li>
</ol></li> </ol></li>
<li>base64url-encode the UTF-8 byte sequence of the JSON array. This string is t he Disclosure.</li> <li>base64url-encode the UTF-8 byte sequence of the JSON array. This string is t he Disclosure.</li>
</ul> </ul>
<blockquote><t>Note: The order was decided based on readability considerations: salts have a <aside><t>Note: The order was decided based on readability considerations: Salts have a
constant length within the SD-JWT, claim names would be around the same length 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 all the time, and claim values would vary in size, potentially being large
objects.</t> objects.</t>
</blockquote><t>The following example illustrates the steps described above.</t> </aside>
<t>The following example illustrates the steps described above.</t>
<t>The array is created as follows:</t> <t>The array is created as follows:</t>
<sourcecode type="json"><![CDATA[["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möb <sourcecode type="json"><![CDATA[
ius"] ["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]
]]> ]]>
</sourcecode> </sourcecode>
<t>The resulting Disclosure is: <tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1p
bHlfbmFtZSIsICJNw7ZiaXVzIl0</tt></t> <t>The resultant Disclosure is:</t>
<t><tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0</
tt></t>
<t>Note that variations in whitespace, encoding of Unicode characters, ordering of object properties, etc., are allowed <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 before base64url-encoding because the digest is calculated over the base64url-encoded v alue itself. in the JSON representation and no canonicalization needs to be performed before base64url encoding because the digest is calculated over the base64url-encoded v alue itself.
For example, the following strings are all valid and encode the For example, the following strings are all valid and encode the
same claim value "Möbius":</t> same claim value "Möbius":</t>
<ul spacing="compact"> <ul spacing="normal">
<li>A different way to encode the unicode umlaut:<br/> <li><t>A different way to encode the unicode umlaut:</t>
<tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNX</tt><br/> <t><tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNXHUwMGY2Yml1c
<tt>HUwMGY2Yml1cyJd</tt></li> yJd</tt></t></li>
<li>No white space:<br/> <li><t>No white space:</t>
<tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Y</tt><br/> <t><tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Yml1cyJd</tt>
<tt>ml1cyJd</tt></li> </t></li>
<li>Newline characters between elements:<br/> <li><t>Newline characters between elements:</t>
<tt>WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiT</tt><br/> <t><tt>WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiTcO2Yml1cyIKX
<tt>cO2Yml1cyIKXQ</tt></li> Q</tt></t></li>
</ul> </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>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 consid erations on the Disclosure format approach.</t> <t>See <xref target="disclosure_format_considerations"/> for some further consid erations on the Disclosure format approach.</t>
</section> </section>
<section anchor="disclosures_for_array_elements"><name>Disclosures for Array Ele ments</name> <section anchor="disclosures_for_array_elements"><name>Disclosures for Array Ele ments</name>
<t>For each claim that is an array element and that is to be made selectively di sclosable, the Issuer MUST create a Disclosure as follows:</t> <t>For each claim that is an array element and that is to be made selectively di sclosable, the Issuer <bcp14>MUST</bcp14> create a Disclosure as follows:</t>
<ul spacing="compact"> <ul spacing="normal">
<li><t>The array MUST contain two elements in this order:</t> <li><t>The array <bcp14>MUST</bcp14> contain two elements in this order:</t>
<ol spacing="compact"> <ol spacing="normal">
<li>The salt value as described in <xref target="disclosures_for_object_properti es"/>.</li> <li>The salt value as described in <xref target="disclosures_for_object_properti es"/>.</li>
<li>The array element that is to be hidden. This value can be of any type that i s allowed in JSON, including numbers, strings, booleans, arrays, and objects.</l i> <li>The array element that is to be hidden. This value can be of any type that i s allowed in JSON, including numbers, strings, booleans, arrays, and objects.</l i>
</ol></li> </ol></li>
</ul> </ul>
<t>The Disclosure string is created by base64url-encoding the UTF-8 byte sequenc e of the resulting JSON array as described in <xref target="disclosures_for_obje ct_properties"/>. The same considerations regarding <t>The Disclosure string is created by base64url-encoding the UTF-8 byte sequenc e of the resultant JSON array as described in <xref target="disclosures_for_obje ct_properties"/>. The same considerations regarding
variations in the result of the JSON encoding apply.</t> 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> <t>For example, a Disclosure for the second element of the <tt>nationalities</tt > array in the following JWT Claims Set:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"nationalities": ["DE", "FR", "US"] "nationalities": ["DE", "FR", "US"]
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>could be created by first creating the following array:</t> <t>could be created by first creating the following array:</t>
<sourcecode type="json"><![CDATA[["lklxF5jMYlGTPUovMNIvCA", "FR"] <sourcecode type="json"><![CDATA[
["lklxF5jMYlGTPUovMNIvCA", "FR"]
]]> ]]>
</sourcecode> </sourcecode>
<t>The resulting Disclosure would be: <tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIk
ZSIl0</tt></t> <t>The resultant Disclosure would be:</t> <t><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkN
<blockquote><t>Note that the size of an array alone can potentially reveal unint BIiwgIkZSIl0</tt></t>
ended information. <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 consistent ly pad the size of an array can help obscure The use of decoys, as described in <xref target="decoy_digests"/>, to consistent ly pad the size of an array can help obscure
the actual number of elements present in any particular instance.</t> the actual number of elements present in any particular instance.</t></aside>
</blockquote></section> </section>
<section anchor="hashing_disclosures"><name>Hashing Disclosures</name> <section anchor="hashing_disclosures"><name>Hashing Disclosures</name>
<t>For embedding references to the Disclosures in the SD-JWT, each Disclosure is <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 describ hashed using the hash algorithm specified in the <tt>_sd_alg</tt> claim describ
ed in <xref target="hash_function_claim"/>, or SHA-256 if no algorithm is specif ed in <xref target="hash_function_claim"/>, or SHA-256 if no algorithm is specif
ied. The resulting digest is then included in the SD-JWT payload instead of the ied. The resultant digest is then included in the SD-JWT payload instead of the
original claim value, as described next.</t> original claim value, as described next.</t>
<t>The digest MUST be taken over the US-ASCII bytes of the base64url-encoded val <!-- [rfced] May we change "taken" to "chosen" or "preferred" for clarity?
ue that is the Disclosure. This follows the convention in JWS <xref target="RFC7
515"/> and JWE <xref target="RFC7516"/>. The bytes of the digest MUST then be ba Section 4.2.3:
se64url-encoded.</t> 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 base64
url-encoded value that is the Disclosure. This follows the convention in JWS <xr
ef target="RFC7515"/> and JWE <xref target="RFC7516"/>. The bytes of the digest
<bcp14>MUST</bcp14> then be base64url encoded.</t>
<t>It is important to note that:</t> <t>It is important to note that:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>The input to the hash function MUST be the base64url-encoded Disclosure, not <li>The input to the hash function <bcp14>MUST</bcp14> be the base64url-encoded
the bytes encoded by the base64url string.</li> Disclosure, not the bytes encoded by the base64url string.</li>
<li>The bytes of the output of the hash function MUST be base64url-encoded, and <li>The bytes of the output of the hash function <bcp14>MUST</bcp14> be base64ur
are not the bytes making up the (sometimes used) hex representation of the bytes l encoded, and are not the bytes making up the (sometimes used) hex representati
of the digest.</li> on of the bytes of the digest.</li>
</ul> </ul>
<t>For example, the base64url-encoded SHA-256 digest of the Disclosure <t>For example, the base64url-encoded SHA-256 digest of the Disclosure
<tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0</tt> <tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0</tt>
for the <tt>family_name</tt> claim from <xref target="disclosures_for_object_pro perties"/> above is for the <tt>family_name</tt> claim from <xref target="disclosures_for_object_pro perties"/> above is
<tt>X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0</tt>.</t> <tt>X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0</tt>.</t>
</section> </section>
<section anchor="embedding_disclosure_digests"><name>Embedding Disclosure Digest s in SD-JWTs</name> <section anchor="embedding_disclosure_digests"><name>Embedding Disclosure Digest s in SD-JWTs</name>
<t>For selectively disclosable claims, the digests of the Disclosures are embedd ed 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> <t>For selectively disclosable claims, the digests of the Disclosures are embedd ed 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>
<ul spacing="compact"> <ul spacing="normal">
<li>For a claim that is an object property, the Issuer embeds a Disclosure diges t as described in <xref target="embedding_object_properties"/>.</li> <li>For a claim that is an object property, the Issuer embeds a Disclosure diges t 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> <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> </ul>
<section anchor="embedding_object_properties"><name>Object Properties</name> <section anchor="embedding_object_properties"><name>Object Properties</name>
<!-- [rfced] We are having trouble parsing this sentence. Please consider wheth
er 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 <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> key MUST refer to an array of s trings, each key <tt>_sd</tt> in the object. The <tt>_sd</tt> key <bcp14>MUST</bcp14> refer t o an array of strings, each
string being a digest of a Disclosure or a decoy digest as described in <xref ta rget="decoy_digests"/>. string being a digest of a Disclosure or a decoy digest as described in <xref ta rget="decoy_digests"/>.
An <tt>_sd</tt> key can be present at any level of the JSON object hierarchy, in cluding the top-level, An <tt>_sd</tt> key can be present at any level of the JSON object hierarchy, in cluding the top-level,
nested deeper as described in <xref target="nested_data"/>, or in recursive disc losures as described in <xref target="recursive_disclosures"/>.</t> nested deeper as described in <xref target="nested_data"/>, or in recursive disc losures as described in <xref target="recursive_disclosures"/>.</t>
<t>The array MAY be empty in case the Issuer decided not to selectively disclose <t>The array <bcp14>MAY</bcp14> be empty in case the Issuer decided not to selec
any of the claims at that level. However, it is RECOMMENDED to omit the <tt>_sd< tively disclose
/tt> any of the claims at that level. However, it is <bcp14>RECOMMENDED</bcp14> to om
it the <tt>_sd</tt>
key in this case to save space.</t> key in this case to save space.</t>
<t>The Issuer MUST hide the original order of the claims in the array. To ensure <t>The Issuer <bcp14>MUST</bcp14> hide the original order of the claims in the a
this, it is RECOMMENDED to shuffle the array of hashes, e.g., by sorting it rray. To ensure
this, it is <bcp14>RECOMMENDED</bcp14> to shuffle the array of hashes, e.g., by
sorting it
alphanumerically or randomly, after potentially adding 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 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> does not depend on the original order of elements.</t>
<t>For example, using the digest of the Disclosure from <xref target="hashing_di sclosures"/>, <t>For example, using the digest of the Disclosure from <xref target="hashing_di sclosures"/>,
the Issuer could create the following SD-JWT payload to make <tt>family_name</tt > the Issuer could create the following SD-JWT payload to make <tt>family_name</tt >
selectively disclosable:</t> selectively disclosable:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"given_name": "Alice", "given_name": "Alice",
"_sd": ["X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0"] "_sd": ["X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0"]
} }
]]> ]]>
</sourcecode> </sourcecode>
</section> </section>
<section anchor="embedding_array_elements"><name>Array Elements</name> <section anchor="embedding_array_elements"><name>Array Elements</name>
<t>Digests of Disclosures for array elements are added to the array in the same <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 position as the original claim value in the array. For each digest, an object
of the form <tt>{"...": "&lt;digest&gt;"}</tt> is added to the array. The key MU of the form <tt>{"...": "&lt;digest&gt;"}</tt> is added to the array. The key <b
ST always be the cp14>MUST</bcp14> always be the
string <tt>...</tt> (three dots). The value MUST be the digest of the Disclosure string <tt>...</tt> (three dots). The value <bcp14>MUST</bcp14> be the digest of
created as the Disclosure created as
described in <xref target="hashing_disclosures"/>. There MUST NOT be any other k described in <xref target="hashing_disclosures"/>. There <bcp14>MUST NOT</bcp14>
eys in the be any other keys in the
object. Note that the string <tt>...</tt> was chosen because the ellipsis charac ter, typically entered as three period characters, is commonly used in places wh ere content is omitted from the present context.</t> object. Note that the string <tt>...</tt> was chosen because the ellipsis charac ter, typically entered as three period characters, is commonly used in places wh ere content is omitted from the present context.</t>
<t>For example, using the digest of the array element Disclosure created above i n <xref target="disclosures_for_array_elements"/>, <t>For example, using the digest of the array element Disclosure created in <xre f target="disclosures_for_array_elements"/>,
the Issuer could create the following SD-JWT payload to make the second element the Issuer could create the following SD-JWT payload to make the second element
of the <tt>nationalities</tt> array selectively disclosable:</t> of the <tt>nationalities</tt> array selectively disclosable:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"nationalities": "nationalities":
["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}, "US"] ["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}, "US"]
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>As described in <xref target="verifier_verification"/>, Verifiers ignore all selectively <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 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 example above, the verification process would output an array with only two
elements, <tt>["DE", "US"]</tt>, unless the matching Disclosure for the second e lement is received, elements, <tt>["DE", "US"]</tt>, unless the matching Disclosure for the second e lement is received,
in which case the output would be a three element array, <tt>["DE", "FR", "US"]< /tt>.</t> in which case the output would be a three-element array, <tt>["DE", "FR", "US"]< /tt>.</t>
</section> </section>
</section> </section>
<section anchor="decoy_digests"><name>Decoy Digests</name> <section anchor="decoy_digests"><name>Decoy Digests</name>
<t>An Issuer MAY add additional digests to the SD-JWT payload that are not assoc iated with <t>An Issuer <bcp14>MAY</bcp14> add additional digests to the SD-JWT payload tha t are not associated with
any claim. The purpose of such "decoy" digests is to make it more difficult for 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 c ontained in the SD-JWT. Decoy an adversarial Verifier to see the original number of claims or array elements c ontained in the SD-JWT. Decoy
digests MAY be added both to the <tt>_sd</tt> array for objects as well as in ar digests <bcp14>MAY</bcp14> be added both to the <tt>_sd</tt> array for objects a
rays.</t> s well as in arrays.</t>
<t>It is RECOMMENDED to create the decoy digests by hashing over a <t>It is <bcp14>RECOMMENDED</bcp14> to create the decoy digests by hashing over
cryptographically secure random number. The bytes of the digest MUST then be a
base64url-encoded as above. The same digest function as for the Disclosures MUST cryptographically secure random number. The bytes of the digest <bcp14>MUST</bcp
14> then be
base64url encoded as above. The same digest function as for the Disclosures <bcp
14>MUST</bcp14>
be used.</t> be used.</t>
<t>For decoy digests, no Disclosure is sent to the Holder, i.e., the Holder will <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 see digests that do not correspond to any Disclosure. See
<xref target="decoy_digests_privacy"/> for additional privacy considerations.</t > <xref target="decoy_digests_privacy"/> for additional privacy considerations.</t >
<t>To ensure readability and replicability, the examples in this specification d o <t>To ensure readability and replicability, the examples in this specification d o
not contain decoy digests unless explicitly stated. For an example not contain decoy digests unless explicitly stated. For an example
with decoy digests, see <xref target="example-simple_structured"/>.</t> with decoy digests, see <xref target="example-simple_structured"/>.</t>
</section> </section>
<section anchor="recursive_disclosures"><name>Recursive Disclosures</name> <section anchor="recursive_disclosures"><name>Recursive Disclosures</name>
<t>The algorithms above are compatible with "recursive disclosures", in which on e <t>The algorithms above are compatible with "recursive disclosures", in which on e
selectively disclosed field reveals the existence of more selectively selectively disclosed field reveals the existence of more selectively
disclosable fields. For example, consider the following JSON structure:</t> disclosable fields. For example, consider the following JSON structure:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"family_name": "Möbius", "family_name": "Möbius",
"nationalities": ["DE", "FR", "UK"] "nationalities": ["DE", "FR", "UK"]
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>When the Holder has multiple nationalities, the issuer may wish to conceal
<t>When the Holder has multiple nationalities, the Issuer may wish to conceal
the presence of any statement regarding nationalities while also allowing the the presence of any statement regarding nationalities while also allowing the
holder to reveal each of those nationalities individually. holder to reveal each of those nationalities individually.
This can be accomplished by first making the entries within the "nationalities" This can be accomplished by first making the entries within the "nationalities"
array selectively disclosable, and then making the whole "nationalities" field array selectively disclosable, and then making the whole "nationalities" field
selectively disclosable.</t> selectively disclosable.</t>
<t>The following shows each of the entries within the "nationalities" array bein g made selectively disclosable:</t> <t>The following shows each of the entries within the "nationalities" array bein g made selectively disclosable:</t>
<!-- [rfced] Would it be appropriate to treat "Content of Disclosures:" as regul
ar 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 <source
code>.
For example, currently, the xml includes the following:
<sourcecode type="ascii-art"><![CDATA[{ <sourcecode type="ascii-art"><![CDATA[{
"family_name": "Möbius", "family_name": "Möbius",
"nationalities": [ "nationalities": [
{ "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" } { "...": "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" }, { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" },
{ "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" } { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" }
] ]
} }
Content of Disclosures: Content of Disclosures:
PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"] PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"]
r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"] r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"]
nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"] nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"]
]]> ]]>
</sourcecode> </sourcecode>
<t>Followed by making the whole "nationalities" array selectively disclosable:</ t> <t>Followed by making the whole "nationalities" array selectively disclosable:</ t>
<sourcecode type="ascii-art"><![CDATA[{ <sourcecode><![CDATA[
{
"family_name": "Möbius", "family_name": "Möbius",
"_sd": [ "5G1srw3RG5W4pVTwSsYxeOWosRBbzd18ZoWKkC-hBL4" ] "_sd": [ "5G1srw3RG5W4pVTwSsYxeOWosRBbzd18ZoWKkC-hBL4" ]
} }
Content of Disclosures: Content of Disclosures:
PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"] PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"]
r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"] r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"]
nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"] nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"]
5G1srw3... = ["4drfeTtSUK3aY_-PF12gcX","nationalities", 5G1srw3... = ["4drfeTtSUK3aY_-PF12gcX","nationalities",
[ [
skipping to change at line 570 skipping to change at line 825
nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"] nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"]
5G1srw3... = ["4drfeTtSUK3aY_-PF12gcX","nationalities", 5G1srw3... = ["4drfeTtSUK3aY_-PF12gcX","nationalities",
[ [
{ "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" }, { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" },
{ "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" }, { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" },
{ "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" } { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" }
] ]
] ]
]]> ]]>
</sourcecode> </sourcecode>
<t>With this set of disclosures, the holder could include the disclosure with ha sh <t>With this set of disclosures, the holder could include the disclosure with ha sh
<tt>PmnlrRj...</tt> to disclose only the "DE" nationality, or include both <tt>P mnlrRj...</tt> <tt>PmnlrRj...</tt> to disclose only the "DE" nationality, or include both <tt>P mnlrRj...</tt>
and <tt>r823HFN...</tt> to disclose both the "DE" and "FR" nationalities, but hi de the and <tt>r823HFN...</tt> to disclose both the "DE" and "FR" nationalities, but hi de the
"UK" nationality. In either case, the holder would also need to include 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 disclosure with hash <tt>5G1srw3...</tt> to disclose the <tt>nationalities</tt> field that
contains the respective elements.</t> contains the respective elements.</t>
<t>Note that making recursive redactions introduces dependencies between the <t>Note that making recursive redactions introduces dependencies between the
disclosure objects in an SD-JWT. The <tt>r823HFN...</tt> disclosure cannot be u sed disclosure objects in an SD-JWT. The <tt>r823HFN...</tt> disclosure cannot be u sed
without the <tt>5G1srw3...</tt> disclosure; since a Verifier would not have a ma tching without the <tt>5G1srw3...</tt> disclosure; since a Verifier would not have a ma tching
hash that would tell it where the content of the <tt>r823HFN...</tt> disclosure should 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-JWT be inserted. If a disclosure object is included in an SD-JWT, then the SD-JWT
MUST include any other disclosure objects necessary to process the first <bcp14>MUST</bcp14> include any other disclosure objects necessary to process th e first
disclosure object. In other words, any disclosure object in an SD-JWT must 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 "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 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 o bjects without also of the <tt>PmnlrRj...</tt>, <tt>r823HFN...</tt>, <tt>nP5GYjw..</tt> disclosure o bjects without also
including the <tt>5G1srw3...</tt> disclosure object.</t> including the <tt>5G1srw3...</tt> disclosure object.</t>
</section> </section>
</section> </section>
<section anchor="kb-jwt"><name>Key Binding JWT</name> <section anchor="kb-jwt"><name>Key Binding JWT</name>
<t>This section defines the Key Binding JWT, which encodes a <t>This section defines the Key Binding JWT, which encodes a
signature over an SD-JWT by the Holder's private key.</t> signature over an SD-JWT by the Holder's private key.</t>
<t>The Key Binding JWT MUST be a JWT according to <xref target="RFC7519"/>, and it MUST contain the following elements:</t> <t>The Key Binding JWT <bcp14>MUST</bcp14> be a JWT according to <xref target="R FC7519"/>, and it <bcp14>MUST</bcp14> contain the following elements:</t>
<ul spacing="compact"> <ul spacing="normal">
<li><t>in the JOSE header,</t> <li><t>in the JOSE header,</t>
<ul spacing="compact"> <ul spacing="normal">
<li><tt>typ</tt>: REQUIRED. MUST be <tt>kb+jwt</tt>, which explicitly types the <li><tt>typ</tt>: <bcp14>REQUIRED</bcp14>. <bcp14>MUST</bcp14> be <tt>kb+jwt</tt
Key Binding JWT as recommended in Section 3.11 of <xref target="RFC8725"/>.</li> >, which explicitly types the Key Binding JWT as recommended in <xref target="RF
<li><tt>alg</tt>: REQUIRED. A digital signature algorithm identifier such as per C8725" section="3.11"/>.</li>
IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST NOT be <t <li><tt>alg</tt>: <bcp14>REQUIRED</bcp14>. A digital signature algorithm identif
t>none</tt>.</li> ier such as per the IANA "JSON Web Signature and Encryption Algorithms" registry
. It <bcp14>MUST NOT</bcp14> be <tt>none</tt>.</li>
</ul></li> </ul></li>
<li><t>in the JWT payload,</t> <li><t>in the JWT payload,</t>
<ul spacing="compact"> <ul spacing="normal">
<li><tt>iat</tt>: REQUIRED. The value of this claim MUST be the time at which th <li><tt>iat</tt>: <bcp14>REQUIRED</bcp14>. The value of this claim <bcp14>MUST</
e Key Binding JWT was issued using the syntax defined in <xref target="RFC7519"/ bcp14> be the time at which the Key Binding JWT was issued using the syntax defi
>.</li> ned in <xref target="RFC7519"/>.</li>
<li><tt>aud</tt>: REQUIRED. The value MUST be a single string that identifies th <li><tt>aud</tt>: <bcp14>REQUIRED</bcp14>. The value <bcp14>MUST</bcp14> be a si
e intended receiver of the Key Binding JWT. How the value is represented is up t ngle string that identifies the intended receiver of the Key Binding JWT. How th
o the protocol used and out of scope of this specification.</li> e value is represented is up to the protocol used and is out of scope for this s
<li><tt>nonce</tt>: REQUIRED. Ensures the freshness of the signature or its bind pecification.</li>
ing to the given transaction. The value type of this claim MUST be a string. How <li><tt>nonce</tt>: <bcp14>REQUIRED</bcp14>. Ensures the freshness of the signat
this value is obtained is up to the protocol used and out of scope of this spec ure or its binding to the given transaction. The value type of this claim <bcp14
ification.</li> >MUST</bcp14> be a string. How this value is obtained is up to the protocol used
<li><tt>sd_hash</tt>: REQUIRED. The base64url-encoded hash value over the Issuer and is out of scope for this specification.</li>
-signed JWT and the selected Disclosures as defined below.</li> <li><tt>sd_hash</tt>: <bcp14>REQUIRED</bcp14>. The base64url-encoded hash value
over the Issuer-signed JWT and the selected Disclosures as defined below.</li>
</ul></li> </ul></li>
</ul> </ul>
<t>The general extensibility model of JWT means that additional claims and heade r parameters can be added to the Key Binding JWT. <t>The general extensibility model of JWT means that additional claims and heade r parameters can be added to the Key Binding JWT.
However, unless there is a compelling reason, this SHOULD be avoided, as it may harm interoperability and burden conceptual integrity.</t> However, unless there is a compelling reason, this <bcp14>SHOULD</bcp14> be avoi ded, as it may harm interoperability and burden conceptual integrity.</t>
<section anchor="integrity-protection-of-the-presentation"><name>Binding to an S D-JWT</name> <section anchor="integrity-protection-of-the-presentation"><name>Binding to an S D-JWT</name>
<t>The hash value in the <tt>sd_hash</tt> claim binds the KB-JWT to the specific SD-JWT. <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> value MUST be taken over the US-ASCII bytes of the The <tt>sd_hash</tt> value <bcp14>MUST</bcp14> be taken over the US-ASCII bytes of the
encoded SD-JWT, i.e., encoded SD-JWT, i.e.,
the Issuer-signed JWT, a tilde character, and zero or more Disclosures selected 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> for presentation to the Verifier, each followed by a tilde character:</t>
<artwork><![CDATA[<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclos <artwork><![CDATA[
ure N>~ <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~
]]> ]]>
</artwork> </artwork>
<t>The bytes of the digest MUST then be base64url-encoded.</t>
<t>The same hash algorithm as for the Disclosures MUST be used (defined by <t>The bytes of the digest <bcp14>MUST</bcp14> then be base64url encoded.</t>
<t>The same hash algorithm as for the Disclosures <bcp14>MUST</bcp14> be used (d
efined by
the <tt>_sd_alg</tt> element in the Issuer-signed JWT or the default value, as d efined the <tt>_sd_alg</tt> element in the Issuer-signed JWT or the default value, as d efined
in <xref target="hash_function_claim"/>).</t> in <xref target="hash_function_claim"/>).</t>
</section> </section>
<section anchor="validating-the-key-binding-jwt"><name>Validating the Key Bindin g JWT</name> <section anchor="validating-the-key-binding-jwt"><name>Validating the Key Bindin g JWT</name>
<t>Whether to require Key Binding is up to the Verifier's policy, based on the s et <t>Whether to require Key Binding is up to the Verifier's policy, based on the s et
of trust requirements such as trust frameworks it belongs to. See of trust requirements (such as trust frameworks) it belongs to. See
<xref target="key_binding_security"/> for security considerations.</t> <xref target="key_binding_security"/> for security considerations.</t>
<t>If the Verifier requires Key Binding, the Verifier MUST ensure that the key w ith which it validates the signature on <t>If the Verifier requires Key Binding, the Verifier <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 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</t t> member, the key. For example, if the SD-JWT contains a <tt>cnf</tt> value with a <tt>jwk</t t> member, the
Verifier would parse the provided JWK and use it to verify the Key Binding JWT.< /t> Verifier would parse the provided JWK and use it to verify the Key Binding JWT.< /t>
<t>Details of the Validation process are defined in <xref target="verifier_verif ication"/>.</t> <t>Details of the validation process are defined in <xref target="verifier_verif ication"/>.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="main-example"><name>Example SD-JWT</name> <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> <t>In this example, a simple SD-JWT is demonstrated. This example is split into issuance and presentation.</t>
<blockquote><t>Note: Throughout the examples in this document, line breaks had t <!-- [rfced] Note that we have adjusted this text to remove a specific character
o be added to count that is allowed per line. The number of characters is different dependin
JSON strings and base64-encoded strings to adhere to the 72-character limit for g on whether the text is running text (69 chars), sourcecode (69 chars), or artw
lines in RFCs and for readability. JSON does not allow line breaks within string ork (72 chars).
s.</t>
</blockquote> 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>
</aside>
<section anchor="issuance"><name>Issuance</name> <section anchor="issuance"><name>Issuance</name>
<t>The following data about the user comprises the input JWT Claims Set used by the Issuer:</t> <t>The following data about the user comprises the input JWT Claims Set used by the Issuer:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"sub": "user_42", "sub": "user_42",
"given_name": "John", "given_name": "John",
"family_name": "Doe", "family_name": "Doe",
"email": "johndoe@example.com", "email": "johndoe@example.com",
"phone_number": "+1-202-555-0101", "phone_number": "+1-202-555-0101",
"phone_number_verified": true, "phone_number_verified": true,
"address": { "address": {
"street_address": "123 Main St", "street_address": "123 Main St",
"locality": "Anytown", "locality": "Anytown",
"region": "Anystate", "region": "Anystate",
skipping to change at line 676 skipping to change at line 950
"updated_at": 1570000000, "updated_at": 1570000000,
"nationalities": [ "nationalities": [
"US", "US",
"DE" "DE"
] ]
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>In this example, the following decisions were made by the Issuer in construct ing the SD-JWT:</t> <t>In this example, the following decisions were made by the Issuer in construct ing the SD-JWT:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>The <tt>nationalities</tt> array is always visible, but its contents are sel ectively disclosable.</li> <li>The <tt>nationalities</tt> array is always visible, but its contents are sel ectively 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>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>All other claims are selectively disclosable.</li>
<li>For <tt>address</tt>, the Issuer is using a flat structure, i.e., all the cl aims <li>For <tt>address</tt>, the Issuer is using a flat structure, i.e., all the cl aims
in the <tt>address</tt> claim can only be disclosed in full. Other options are in the <tt>address</tt> claim can only be disclosed in full. Other options are
discussed in <xref target="nested_data"/>.</li> discussed in <xref target="nested_data"/>.</li>
</ul> </ul>
<t>The following payload is used for the SD-JWT:</t> <t>The following payload is used for the SD-JWT:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"_sd": [ "_sd": [
"CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI", "CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI",
"JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE", "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE",
"PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI", "PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI",
"TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo", "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo",
"XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM", "XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM",
"XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE", "XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE",
"gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM", "gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM",
"jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4" "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4"
], ],
skipping to change at line 721 skipping to change at line 996
"jwk": { "jwk": {
"kty": "EC", "kty": "EC",
"crv": "P-256", "crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
} }
} }
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>The respective Disclosures, created by the Issuer, are listed below. <t>The respective Disclosures, created by the Issuer, are listed below.
In the text below and in other locations in this specification, 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-Encode d SHA-256 Hash:".</t> the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encode d SHA-256 Hash:".</t>
<t><strong>Claim <tt>given_name</tt></strong>:</t>
<ul spacing="compact"> <ul>
<li>SHA-256 Hash: <tt>jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4</tt></li> <li><t>Claim <tt>given_name</tt>:</t>
<li>Disclosure:<br/> <ul spacing="normal">
<tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o</tt><br/> <li><t>SHA-256 Hash:</t><t><tt>jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4</tt><
<tt>biJd</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWU
<tt>["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]</tt></li> iLCAiSm9obiJd</tt></t></li>
</ul> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]</tt>
<t><strong>Claim <tt>family_name</tt></strong>:</t> </t></li>
</ul></li></ul>
<ul spacing="compact"> <t><strong>Claim <tt>family_name</tt></strong>:</t>
<li>SHA-256 Hash: <tt>TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo</tt><
<tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRv</tt><br/> /t></li>
<tt>ZSJd</tt></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1
<li>Contents: lIiwgIkRvZSJd</tt></t></li>
<tt>["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]</tt></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]</tt>
</t></li>
</ul> </ul>
<t><strong>Claim <tt>email</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>email</tt></strong>:</t>
<li>SHA-256 Hash: <tt>JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE</tt><
<tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VA</tt><br/> /t></li>
<tt>ZXhhbXBsZS5jb20iXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImp
<li>Contents: vaG5kb2VAZXhhbXBsZS5jb20iXQ</tt></t></li>
<tt>["6Ij7tM-a5iVPGboS5tmvVA", "email", "johndoe@example.com"]</tt></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "email", "johndoe@example.
com"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>phone_number</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>phone_number</tt></strong>:</t>
<li>SHA-256 Hash: <tt>PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI</tt><
<tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIr</tt><br/> /t></li>
<tt>MS0yMDItNTU1LTAxMDEiXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJ
<li>Contents: lciIsICIrMS0yMDItNTU1LTAxMDEiXQ</tt></t></li>
<tt>["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number",</tt><br/> <li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number", "+1-202-55
<tt>"+1-202-555-0101"]</tt></li> 5-0101"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>phone_number_verified</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>phone_number_verified</tt></strong>:</t>
<li>SHA-256 Hash: <tt>XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM</tt><
<tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJp</tt><br/> /t></li>
<tt>ZmllZCIsIHRydWVd</tt></li> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJ
<li>Contents: lcl92ZXJpZmllZCIsIHRydWVd</tt></t></li>
<tt>["Qg_O64zqAxe412a108iroA", "phone_number_verified", true]</tt></li> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "phone_number_verified", t
rue]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>address</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>address</tt></strong>:</t>
<li>SHA-256 Hash: <tt>XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE</tt><
<tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVl</tt><br/> /t></li>
<tt>dF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRv</tt><br/> <li><t>Disclosure:</t><t><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB
<tt>d24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0</tt></li> 7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmV
<li>Contents: naW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0</tt></t></li>
<tt>["AJx-095VPrpTtN4QMOqROA", "address", {"street_address":</tt><br/> <li><t>Contents:</t><t><tt>["AJx-095VPrpTtN4QMOqROA", "address", {"street_addres
<tt>"123 Main St", "locality": "Anytown", "region": "Anystate",</tt><br/> s": "123 Main St", "locality": "Anytown", "region": "Anystate", "country": "US"}
<tt>"country": "US"}]</tt></li> ]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>birthdate</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>birthdate</tt></strong>:</t>
<li>SHA-256 Hash: <tt>gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM</tt><
<tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQw</tt><br/> /t></li>
<tt>LTAxLTAxIl0</tt></li> <li><t>Disclosure:</t><t><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSI
<li>Contents: sICIxOTQwLTAxLTAxIl0</tt></t></li>
<tt>["Pc33JM2LchcU_lHggv_ufQ", "birthdate", "1940-01-01"]</tt></li> <li><t>Contents:</t><t><tt>["Pc33JM2LchcU_lHggv_ufQ", "birthdate", "1940-01-01"]
</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>updated_at</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>updated_at</tt></strong>:</t>
<li>SHA-256 Hash: <tt>CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI</tt><
<tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcw</tt><br/> /t></li>
<tt>MDAwMDAwXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQ
<li>Contents: iLCAxNTcwMDAwMDAwXQ</tt></t></li>
<tt>["G02NSrQfjFXQ7Io09syajA", "updated_at", 1570000000]</tt></li> <li><t>Contents:</t><t><tt>["G02NSrQfjFXQ7Io09syajA", "updated_at", 1570000000]<
/tt></t></li>
</ul> </ul>
<t><strong>Array Entry</strong>:</t>
<ul spacing="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>
</ul>
<t><strong>Array Entry</strong>:</t> <t><strong>Array Entry</strong>:</t>
<ul 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>
<ul spacing="compact"> <t><strong>Array Entry</strong>:</t>
<li>SHA-256 Hash: <tt>7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0</tt><
<tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0</tt></t
<tt>["nPuoQnkRFq3BIeAm7AnXFA", "DE"]</tt></li> ></li>
<li><t>Contents:</t><t><tt>["nPuoQnkRFq3BIeAm7AnXFA", "DE"]</tt></t></li>
</ul> </ul>
<t>The payload is then signed by the Issuer to create the following Issuer-signe d JWT:</t>
<sourcecode type="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qt <t>The payload is then signed by the Issuer to create the following Issuer-signe
and0In0.eyJfc2QiOiBb d JWT:</t>
<sourcecode type="txt"><![CDATA[
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1 dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2 TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15 InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
skipping to change at line 850 skipping to change at line 1096
ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz
-CXo6R04b7jYrpj9mNRAvVssXou1iw -CXo6R04b7jYrpj9mNRAvVssXou1iw
]]> ]]>
</sourcecode> </sourcecode>
<t>Adding the Disclosures produces the SD-JWT:</t> <t>Adding the Disclosures produces the SD-JWT:</t>
<sourcecode type="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qt <sourcecode type="txt"><![CDATA[
and0In0.eyJfc2QiOiBb eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1 dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2 TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15 InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
skipping to change at line 890 skipping to change at line 1137
</sourcecode> </sourcecode>
</section> </section>
<section anchor="presentation"><name>Presentation</name> <section anchor="presentation"><name>Presentation</name>
<t>The following non-normative example shows an SD-JWT+KB as <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 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 beginnin g, tilde-separated parts, with the Issuer-signed JWT as shown above in the beginnin g,
four Disclosures (for the claims <tt>given_name</tt>, <tt>family_name</tt>, <tt> address</tt>, and one of the 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 eleme nt.</t> <tt>nationalities</tt>) in the middle, and the Key Binding JWT as the last eleme nt.</t>
<sourcecode type="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qt <sourcecode type="txt"><![CDATA[
and0In0.eyJfc2QiOiBb eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1 dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2 TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15 InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
skipping to change at line 922 skipping to change at line 1170
~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~eyJhbGciOiAiRVMyNTYiLCA ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~eyJhbGciOiAiRVMyNTYiLCA
idHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodH idHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodH
RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF
9oYXNoIjogIjBfQWYtMkItRWhMV1g1eWRoX3cyeHp3bU82aU02NkJfMlFDRWFuSTRmVV 9oYXNoIjogIjBfQWYtMkItRWhMV1g1eWRoX3cyeHp3bU82aU02NkJfMlFDRWFuSTRmVV
kifQ.T3SIus2OidNl41nmVkTZVCKKhOAX97aOldMyHFiYjHm261eLiJ1YiuONFiMN8Ql kifQ.T3SIus2OidNl41nmVkTZVCKKhOAX97aOldMyHFiYjHm261eLiJ1YiuONFiMN8Ql
CmYzDlBLAdPvrXh52KaLgUQ CmYzDlBLAdPvrXh52KaLgUQ
]]> ]]>
</sourcecode> </sourcecode>
<t>The following Key Binding JWT payload was created and signed for this present ation by the Holder:</t> <t>The following Key Binding JWT payload was created and signed for this present ation by the Holder:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"nonce": "1234567890", "nonce": "1234567890",
"aud": "https://verifier.example.org", "aud": "https://verifier.example.org",
"iat": 1748537244, "iat": 1748537244,
"sd_hash": "0_Af-2B-EhLWX5ydh_w2xzwmO6iM66B_2QCEanI4fUY" "sd_hash": "0_Af-2B-EhLWX5ydh_w2xzwmO6iM66B_2QCEanI4fUY"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>If the Verifier did not require Key Binding, then the Holder could have <t>If the Verifier did not require Key Binding, then the Holder could have
presented the SD-JWT with selected Disclosures directly, instead of encapsulatin g it in presented the SD-JWT with selected Disclosures directly, instead of encapsulatin g it in
an SD-JWT+KB.</t> an SD-JWT+KB.</t>
<t>After validation, the Verifier will have the following Processed SD-JWT Paylo ad available for further handling:</t> <t>After validation, the Verifier will have the following Processed SD-JWT Paylo ad available for further handling:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"iss": "https://issuer.example.com", "iss": "https://issuer.example.com",
"iat": 1683000000, "iat": 1683000000,
"exp": 1883000000, "exp": 1883000000,
"sub": "user_42", "sub": "user_42",
"nationalities": [ "nationalities": [
"US" "US"
], ],
"cnf": { "cnf": {
"jwk": { "jwk": {
"kty": "EC", "kty": "EC",
skipping to change at line 962 skipping to change at line 1212
"address": { "address": {
"street_address": "123 Main St", "street_address": "123 Main St",
"locality": "Anytown", "locality": "Anytown",
"region": "Anystate", "region": "Anystate",
"country": "US" "country": "US"
}, },
"given_name": "John" "given_name": "John"
} }
]]> ]]>
</sourcecode> </sourcecode>
</section> </section>
</section> </section>
<section anchor="nested_data"><name>Considerations on Nested Data in SD-JWTs</na me> <section anchor="nested_data"><name>Considerations on Nested Data in SD-JWTs</na me>
<t>Being JSON, an object in an SD-JWT payload MAY contain name/value pairs where <t>Being JSON, an object in an SD-JWT payload <bcp14>MAY</bcp14> contain name/va
the value is another object or objects MAY be elements in arrays. In SD-JWT, th lue pairs where the value is another object or objects <bcp14>MAY</bcp14> be ele
e Issuer decides for each claim individually, on each level of the JSON, whether ments in arrays. In SD-JWT, the Issuer decides for each claim individually, on e
the claim should be selectively disclosable or not. This choice can be made on ach level of the JSON, whether or not the claim should be selectively disclosabl
each level independent of whether keys higher in the hierarchy are selectively d e. This choice can be made on each level independent of whether keys higher in t
isclosable.</t> he hierarchy are selectively disclosable.</t>
<t>From this it follows that the <tt>_sd</tt> key containing digests MAY appear <t>From this it follows that the <tt>_sd</tt> key containing digests <bcp14>MAY<
multiple /bcp14> appear multiple
times in an SD-JWT, and likewise, there MAY be multiple arrays within the times in an SD-JWT, and likewise, there <bcp14>MAY</bcp14> be multiple arrays wi
thin the
hierarchy with each having selectively disclosable elements. Digests of hierarchy with each having selectively disclosable elements. Digests of
selectively disclosable claims MAY even appear within other Disclosures.</t> selectively disclosable claims <bcp14>MAY</bcp14> even appear within other Discl
<t>The following examples illustrate some of the options an Issuer has. It is up osures.</t>
to the Issuer to decide which structure to use, depending on, for example, the <t>The following examples illustrate some of the options an Issuer has. It is up
expected use cases for the SD-JWT, requirements for privacy, size considerations to the Issuer to decide which structure to use, depending on, for example, the
, or operating environment requirements. For more examples with nested structure expected use cases for the SD-JWT, requirements for privacy, size considerations
s, see <xref target="example-simple_structured"/> and <xref target="example-comp , or operating environment requirements. For more examples with nested structure
lex-structured-sd-jwt"/>.</t> s, see Appendices <xref target="example-simple_structured" format="counter"/> an
d <xref target="example-complex-structured-sd-jwt" format="counter"/>.</t>
<t>The following input JWT Claims Set is used as an example throughout this sect ion:</t> <t>The following input JWT Claims Set is used as an example throughout this sect ion:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"address": { "address": {
"street_address": "Schulstr. 12", "street_address": "Schulstr. 12",
"locality": "Schulpforta", "locality": "Schulpforta",
"region": "Sachsen-Anhalt", "region": "Sachsen-Anhalt",
"country": "DE" "country": "DE"
} }
} }
]]> ]]>
</sourcecode> </sourcecode>
<blockquote><t>Note: The following examples of the structures are non-normative
and are not intended to <!-- [rfced] For clarity in the text output, may we add "claim" after address he
re? While "claim" is enclosed in <tt>, which makes it visually distinct from su
rrounding text in the html and pdf, there is no such visual distinction in the t
ext.
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 a
re not intended to
represent all possible options. They are also not meant to define or restrict 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> 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> <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 D isclosure.</t> <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 D isclosure.</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"_sd": [ "_sd": [
"fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do" "fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"
], ],
"iss": "https://issuer.example.com", "iss": "https://issuer.example.com",
"iat": 1683000000, "iat": 1683000000,
"exp": 1883000000, "exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"_sd_alg": "sha-256" "_sd_alg": "sha-256"
} }
]]> ]]>
skipping to change at line 1004 skipping to change at line 1273
"fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do" "fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"
], ],
"iss": "https://issuer.example.com", "iss": "https://issuer.example.com",
"iat": 1683000000, "iat": 1683000000,
"exp": 1883000000, "exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"_sd_alg": "sha-256" "_sd_alg": "sha-256"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>The Issuer would create the following Disclosure referenced by the one hash i n the SD-JWT:</t> <t>The Issuer would create the following Disclosure referenced by the one hash i n the SD-JWT:</t>
<t><strong>Claim <tt>address</tt></strong>:</t> <t><strong>Claim <tt>address</tt></strong>:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>SHA-256 Hash: <tt>fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do</tt></li> <li><t>SHA-256 Hash:</t><t><tt>fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do</tt><
<li>Disclosure:<br/> /t></li>
<tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVl</tt><br/> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB
<tt>dF9hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1</tt><br/> 7InN0cmVldF9hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1bHBmb3J0YSI
<tt>bHBmb3J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRy</tt><br/> sICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRyeSI6ICJERSJ9XQ</tt></t></li>
<tt>eSI6ICJERSJ9XQ</tt></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "address", {"street_addres
<li>Contents: s": "Schulstr. 12", "locality": "Schulpforta", "region": "Sachsen-Anhalt", "coun
<tt>["2GLC42sKQveCfGfryNRN9w", "address", {"street_address":</tt><br/> try": "DE"}]</tt></t></li>
<tt>"Schulstr. 12", "locality": "Schulpforta", "region":</tt><br/>
<tt>"Sachsen-Anhalt", "country": "DE"}]</tt></li>
</ul> </ul>
</section> </section>
<section anchor="example-structured-sd-jwt"><name>Example: Structured SD-JWT</na me> <section anchor="example-structured-sd-jwt"><name>Example: Structured SD-JWT</na me>
<t>The Issuer may instead decide to make the <tt>address</tt> claim contents sel ectively disclosable individually:</t> <t>The Issuer may instead decide to make the <tt>address</tt> claim contents sel ectively disclosable individually:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"iss": "https://issuer.example.com", "iss": "https://issuer.example.com",
"iat": 1683000000, "iat": 1683000000,
"exp": 1883000000, "exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"address": { "address": {
"_sd": [ "_sd": [
"6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
"KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88", "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88",
"WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM" "WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"
] ]
}, },
"_sd_alg": "sha-256" "_sd_alg": "sha-256"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>In this case, the Issuer would use the following data in the Disclosures for the <tt>address</tt> sub-claims:</t> <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> <t><strong>Claim <tt>street_address</tt></strong>:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>SHA-256 Hash: <tt>9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM</tt></li> <li><t>SHA-256 Hash:</t><t><tt>9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM</tt><
<li>Disclosure:<br/> /t></li>
<tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwg</tt><br/> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGR
<tt>IlNjaHVsc3RyLiAxMiJd</tt></li> yZXNzIiwgIlNjaHVsc3RyLiAxMiJd</tt></t></li>
<li>Contents: <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulst
<tt>["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]</tt></li> r. 12"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>locality</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>locality</tt></strong>:</t>
<li>SHA-256 Hash: <tt>6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0</tt><
<tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVs</tt><br/> /t></li>
<tt>cGZvcnRhIl0</tt></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5Iiw
<li>Contents: gIlNjaHVscGZvcnRhIl0</tt></t></li>
<tt>["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]</tt></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]
</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>region</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>region</tt></strong>:</t>
<li>SHA-256 Hash: <tt>KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88</tt><
<tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2Vu</tt><br/> /t></li>
<tt>LUFuaGFsdCJd</tt></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJ
<li>Contents: TYWNoc2VuLUFuaGFsdCJd</tt></t></li>
<tt>["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]</tt></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"
]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>country</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>country</tt></strong>:</t>
<li>SHA-256 Hash: <tt>WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM</tt><
<tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCA
<tt>["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]</tt></li> iREUiXQ</tt></t></li>
<li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]</tt></t><
/li>
</ul> </ul>
<t>The Issuer may also make one sub-claim of <tt>address</tt> permanently disclo sed and hide only the other sub-claims:</t>
<sourcecode type="json"><![CDATA[{ <t>The Issuer may also make one sub-claim of <tt>address</tt> permanently disclo
sed and hide only the other sub-claims:</t>
<sourcecode type="json"><![CDATA[
{
"iss": "https://issuer.example.com", "iss": "https://issuer.example.com",
"iat": 1683000000, "iat": 1683000000,
"exp": 1883000000, "exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"address": { "address": {
"_sd": [ "_sd": [
"6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
"KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88" "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88"
], ],
skipping to change at line 1100 skipping to change at line 1354
"6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
"KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88" "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88"
], ],
"country": "DE" "country": "DE"
}, },
"_sd_alg": "sha-256" "_sd_alg": "sha-256"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>In this case, there would be no Disclosure for <tt>country</tt>, since it is provided in the clear.</t> <t>In this case, there would be no Disclosure for <tt>country</tt>, since it is provided in the clear.</t>
</section> </section>
<section anchor="example-sd-jwt-with-recursive-disclosures"><name>Example: SD-JW T with Recursive Disclosures</name> <section anchor="example-sd-jwt-with-recursive-disclosures"><name>Example: SD-JW T with Recursive Disclosures</name>
<t>The Issuer may also decide to make the <tt>address</tt> claim contents select ively disclosable recursively, i.e., the <tt>address</tt> claim is made selectiv ely disclosable as well as its sub-claims:</t> <t>The Issuer may also decide to make the <tt>address</tt> claim contents select ively disclosable recursively, i.e., the <tt>address</tt> claim is made selectiv ely disclosable as well as its sub-claims:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"_sd": [ "_sd": [
"HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg" "HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg"
], ],
"iss": "https://issuer.example.com", "iss": "https://issuer.example.com",
"iat": 1683000000, "iat": 1683000000,
"exp": 1883000000, "exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"_sd_alg": "sha-256" "_sd_alg": "sha-256"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>The Issuer creates Disclosures first for the sub-claims and then includes the
ir digests in the Disclosure for the <tt>address</tt> claim:</t>
<t><strong>Claim <tt>street_address</tt></strong>:</t>
<ul spacing="compact"> <t>The Issuer first creates Disclosures for the sub-claims and then includes the
<li>SHA-256 Hash: <tt>9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM</tt></li> ir digests in the Disclosure for the <tt>address</tt> claim:</t>
<li>Disclosure:<br/>
<tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwg</tt><br/> <t><strong>Claim <tt>street_address</tt></strong>:</t>
<tt>IlNjaHVsc3RyLiAxMiJd</tt></li> <ul spacing="normal">
<li>Contents: <li><t>SHA-256 Hash:</t><t><tt>9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM</tt><
<tt>["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]</tt></li> /t></li>
<li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGR
yZXNzIiwgIlNjaHVsc3RyLiAxMiJd</tt></t></li>
<li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulst
r. 12"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>locality</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>locality</tt></strong>:</t>
<li>SHA-256 Hash: <tt>6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0</tt><
<tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVs</tt><br/> /t></li>
<tt>cGZvcnRhIl0</tt></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5Iiw
<li>Contents: gIlNjaHVscGZvcnRhIl0</tt></t></li>
<tt>["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]</tt></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]
</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>region</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>region</tt></strong>:</t>
<li>SHA-256 Hash: <tt>KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88</tt><
<tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2Vu</tt><br/> /t></li>
<tt>LUFuaGFsdCJd</tt></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJ
<li>Contents: TYWNoc2VuLUFuaGFsdCJd</tt></t></li>
<tt>["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]</tt></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"
]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>country</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>country</tt></strong>:</t>
<li>SHA-256 Hash: <tt>WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM</tt><
<tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCA
<tt>["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]</tt></li> iREUiXQ</tt></t></li>
<li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]</tt></t><
/li>
</ul> </ul>
<t><strong>Claim <tt>address</tt></strong>:</t> <t><strong>Claim <tt>address</tt></strong>:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>SHA-256 Hash: <tt>HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg</tt></li> <li><t>SHA-256 Hash:</t><t><tt>HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg</tt><
<li>Disclosure:<br/> /t></li>
<tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6</tt><br/> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB
<tt>IFsiNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVk</tt><br/> 7Il9zZCI6IFsiNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCIsICI5Z2p
<tt>MCIsICI5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3Nmtt</tt><br/> WdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgIktVUkRQaDRaQzE5LTN0aXo
<tt>WXlNIiwgIktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEy</tt><br/> tRGYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV
<tt>TjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8y</tt><br/> 4NjVfWl8ycm8yamZYTSJdfV0</tt></t></li>
<tt>cm8yamZYTSJdfV0</tt></li> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "address", {"_sd": ["6vh9b
<li>Contents: q-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76
<tt>["Qg_O64zqAxe412a108iroA", "address", {"_sd":</tt><br/> kmYyM", "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88", "WN9r9dCBJ8HTCsS2jKASxTjE
<tt>["6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",</tt><br/> yW5m5x65_Z_2ro2jfXM"]}]</tt></t></li>
<tt>"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",</tt><br/>
<tt>"KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88",</tt><br/>
<tt>"WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]</tt></li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="verification-1"><name>Verification and Processing</name> <section anchor="verification-1"><name>Verification and Processing</name>
<section anchor="sd_jwt_verification"><name>Verification of the SD-JWT</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 <t>Upon receiving an SD-JWT, either directly or as a component of an SD-JWT+KB, a Holder
or a Verifier needs to ensure that:</t> or Verifier needs to ensure that:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>the Issuer-signed JWT is valid, and</li> <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 conte nts of other Disclosures).</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 conte nts of other Disclosures).</li>
</ul> </ul>
<t>The Holder or the Verifier MUST perform the following checks when receiving <t>The Holder or the Verifier <bcp14>MUST</bcp14> perform the following checks w hen receiving
an SD-JWT to validate the SD-JWT and extract the payload:</t> an SD-JWT to validate the SD-JWT and extract the payload:</t>
<ol spacing="compact"> <ol type="1" spacing="normal">
<li>Separate the SD-JWT into the Issuer-signed JWT and the Disclosures (if any). </li> <li>Separate the SD-JWT into the Issuer-signed JWT and the Disclosures (if any). </li>
<li><t>Validate the Issuer-signed JWT:</t> <li><t>Validate the Issuer-signed JWT:</t>
<ol spacing="compact"> <ol type="a" spacing="normal">
<li>Ensure that a signing algorithm was used that was deemed secure for the appl <li>Ensure that the used signing algorithm was deemed secure for the application
ication. Refer to <xref target="RFC8725"/>, Sections 3.1 and 3.2 for details. Th . Refer to <xref target="RFC8725"/>, Sections <xref target="RFC8725" section="3.
e <tt>none</tt> algorithm MUST NOT be accepted.</li> 1" sectionFormat="bare"/> and <xref target="RFC8725" section="3.2" sectionFormat
<li>Validate the signature over the Issuer-signed JWT per Section 5.2 of <xref t ="bare"/> for details. The <tt>none</tt> algorithm <bcp14>MUST NOT</bcp14> be ac
arget="RFC7515"/>.</li> cepted.</li>
<li>Validate the signature over the Issuer-signed JWT per <xref target="RFC7515"
section="5.2"/>.</li>
<li>Validate the Issuer and that the signing key belongs to this Issuer.</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 algor ithm is deemed secure according to the Holder or Verifier's policy (see <xref ta rget="hash_function_claim"/>).</li> <li>Check that the <tt>_sd_alg</tt> claim value is understood and the hash algor ithm is deemed secure according to the Holder or Verifier's policy (see <xref ta rget="hash_function_claim"/>).</li>
</ol></li> </ol></li>
<li><t>Process the Disclosures and embedded digests in the Issuer-signed JWT as follows:</t> <li><t>Process the Disclosures and embedded digests in the Issuer-signed JWT as follows:</t>
<ol spacing="compact"> <ol type="a" spacing="normal">
<li><t>For each Disclosure provided:</t> <li><t>For each Disclosure provided:</t>
<ol spacing="compact"> <ol type="i" spacing="normal">
<li>Calculate the digest over the base64url-encoded string as described in <xref target="hashing_disclosures"/>.</li> <li>Calculate the digest over the base64url-encoded string as described in <xref target="hashing_disclosures"/>.</li>
</ol></li> </ol></li>
<li><t>(*) Identify all embedded digests in the Issuer-signed JWT as follows:</t > <li><t>(*) Identify all embedded digests in the Issuer-signed JWT as follows:</t >
<ol spacing="compact"> <ol type="i" spacing="normal">
<li>Find all objects having an <tt>_sd</tt> key that refers to an array of strin gs.</li> <li>Find all objects having an <tt>_sd</tt> key that refers to an array of strin gs.</li>
<li>Find all array elements that are objects with one key, that key being <tt>.. .</tt> and referring to a string.</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> </ol></li>
<li><t>(**) For each embedded digest found in the previous step:</t> <li><t>(**) For each embedded digest found in the previous step:</t>
<ol spacing="compact"> <ol type="i" spacing="normal">
<li>Compare the value with the digests calculated previously and find the matchi <li>Compare the value with the digests calculated previously and find the matchi
ng Disclosure. If no such Disclosure can be found, the digest MUST be ignored.</ ng Disclosure. If no such Disclosure can be found, the digest <bcp14>MUST</bcp14
li> > be ignored.</li>
<li><t>If the digest was found in an object's <tt>_sd</tt> key:</t> <li><t>If the digest was found in an object's <tt>_sd</tt> key:</t>
<ol spacing="compact"> <ol type="1" spacing="normal">
<li>If the contents of the respective Disclosure is not a JSON array of three el <li>If the contents of the respective Disclosure is not a JSON array of three el
ements (salt, claim name, claim value), the SD-JWT MUST be rejected.</li> ements (salt, claim name, claim value), the SD-JWT <bcp14>MUST</bcp14> be reject
<li>If the claim name is <tt>_sd</tt> or <tt>...</tt>, the SD-JWT MUST be reject ed.</li>
ed.</li> <li>If the claim name is <tt>_sd</tt> or <tt>...</tt>, the SD-JWT <bcp14>MUST</b
<li>If the claim name already exists at the level of the <tt>_sd</tt> key, the S cp14> be rejected.</li>
D-JWT MUST be rejected.</li> <li>If the claim name already exists at the level of the <tt>_sd</tt> key, the S
D-JWT <bcp14>MUST</bcp14> be rejected.</li>
<li>Insert, at the level of the <tt>_sd</tt> key, a new claim using the claim na me and claim value from the Disclosure.</li> <li>Insert, at the level of the <tt>_sd</tt> key, a new claim using the claim na me and claim value from the Disclosure.</li>
<li>Recursively process the value using the steps described in (*) and (**).</li > <li>Recursively process the value using the steps described in (*) and (**).</li >
</ol></li> </ol></li>
<li><t>If the digest was found in an array element:</t> <li><t>If the digest was found in an array element:</t>
<ol spacing="compact"> <ol type="1" spacing="normal">
<li>If the contents of the respective Disclosure is not a JSON array of two elem <li>If the contents of the respective Disclosure is not a JSON array of two elem
ents (salt, value), the SD-JWT MUST be rejected.</li> ents (salt, value), the SD-JWT <bcp14>MUST</bcp14> be rejected.</li>
<li>Replace the array element with the value from the Disclosure.</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 > <li>Recursively process the value using the steps described in (*) and (**).</li >
</ol></li> </ol></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 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 p ayload. If this results in an object with no properties, it should be represente d as an empty object <tt>{}</tt>.</li> <li>Remove all <tt>_sd</tt> keys and their contents from the Issuer-signed JWT p ayload. If this results in an object with no properties, it should be represente d as an empty object <tt>{}</tt>.</li>
<li>Remove the claim <tt>_sd_alg</tt> from the SD-JWT payload.</li> <li>Remove the claim <tt>_sd_alg</tt> from the SD-JWT payload.</li>
</ol></li> </ol></li>
<li>If any digest value is encountered more than once in the Issuer-signed JWT p <li>If any digest value is encountered more than once in the Issuer-signed JWT p
ayload (directly or recursively via other Disclosures), the SD-JWT MUST be rejec ayload (directly or recursively via other Disclosures), the SD-JWT <bcp14>MUST</
ted.</li> bcp14> be rejected.</li>
<li>If any Disclosure was not referenced by digest value in the Issuer-signed JW <li>If any Disclosure was not referenced by digest value in the Issuer-signed JW
T (directly or recursively via other Disclosures), the SD-JWT MUST be rejected.< T (directly or recursively via other Disclosures), the SD-JWT <bcp14>MUST</bcp14
/li> > be rejected.</li>
<li>Check that the SD-JWT is valid using claims such as <tt>nbf</tt>, <tt>exp</t <li>Check that the SD-JWT is valid using claims such as <tt>nbf</tt>, <tt>exp</t
t>, and <tt>aud</tt> in the processed payload, if present. If a required validit t>, and <tt>aud</tt> in the processed payload, if present. If a required validit
y-controlling claim is missing (see <xref target="sd-validity-claims"/>), the SD y-controlling claim is missing (see <xref target="sd-validity-claims"/>), the SD
-JWT MUST be rejected.</li> -JWT <bcp14>MUST</bcp14> be rejected.</li>
</ol> </ol>
JWT <span class="insert">&lt;bcp14&gt;MUST&lt;/bcp14&gt;</span> be rejected.&lt; <t>If any step fails, the SD-JWT is not valid, and processing <bcp14>MUST</bcp14
/li&gt; > be aborted. Otherwise, the JSON document resulting from the preceding processi
<t>If any step fails, the SD-JWT is not valid, and processing MUST be aborted. O ng and verification steps, herein referred to as the "Processed SD-JWT Payload",
therwise, the JSON document resulting from the preceding processing and verifica can be made available to the application to be used for its intended purpose.</
tion steps, herein referred to as the Processed SD-JWT Payload, can be made avai t>
lable to the application to be used for its intended purpose.</t>
<blockquote><t>Note that these processing steps do not yield any guarantees to t <aside><t>Note that these processing steps do not yield any guarantees to the Ho
he Holder about having received a complete set of Disclosures. That is, for some lder about having received a complete set of Disclosures. That is, for some dige
digest values in the Issuer-signed JWT (which are not decoy digests) there may st values in the Issuer-signed JWT (which are not decoy digests), there may be n
be no corresponding Disclosures, for example, if the message from the Issuer was o corresponding Disclosures, for example, if the message from the Issuer was tru
truncated. ncated.
It is up to the Holder how to maintain the mapping between the Disclosures and t It is up to the Holder how to maintain the mapping between the Disclosures and t
he plaintext claim values to be able to display them to the user when needed.</t he plaintext claim values to be able to display them to the user when needed.</t
> ></aside>
</blockquote></section> </section>
<section anchor="holder_verification"><name>Processing by the Holder</name> <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 Hold er <t>The Issuer provides the Holder with an SD-JWT, not an SD-JWT+KB. If the Hold er
receives an SD-JWT+KB, it MUST be rejected.</t> receives an SD-JWT+KB, it <bcp14>MUST</bcp14> be rejected.</t>
<t>When receiving an SD-JWT, the Holder MUST do the following:</t> <t>When receiving an SD-JWT, the Holder <bcp14>MUST</bcp14> do the following:</t
>
<ol spacing="compact"> <ol type="1" spacing="normal">
<li>Process the SD-JWT as defined in <xref target="sd_jwt_verification"/> to val idate it and extract the payload.</li> <li>Process the SD-JWT as defined in <xref target="sd_jwt_verification"/> to val idate 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> <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> </ol>
<t>For presentation to a Verifier, the Holder MUST perform the following (or equ ivalent) steps (in addition to the checks described in <xref target="sd_jwt_veri fication"/> performed after receiving the SD-JWT):</t> <t>For presentation to a Verifier, the Holder <bcp14>MUST</bcp14> perform the fo llowing (or equivalent) steps (in addition to the checks described in <xref targ et="sd_jwt_verification"/> performed after receiving the SD-JWT):</t>
<ol spacing="compact"> <ol type="1" spacing="normal">
<li>Decide which Disclosures to release to the Verifier, obtaining consent if ne cessary (note that if and how consent is attained is out of scope for this docum ent).</li> <li>Decide which Disclosures to release to the Verifier, obtaining consent if ne cessary (note that if and how consent is attained is out of scope for this docum ent).</li>
<li><t>Verify that each selected Disclosure satisfies one of the two following c onditions:</t> <li><t>Verify that each selected Disclosure satisfies one of the two following c onditions:</t>
<ol spacing="compact"> <ol type="a" spacing="normal">
<li>The hash of the Disclosure is contained in the Issuer-signed JWT claims</li> <li>The hash of the Disclosure is contained in the Issuer-signed JWT claims.</li
<li>The hash of the Disclosure is contained in the claim value of another select >
ed Disclosure</li> <li>The hash of the Disclosure is contained in the claim value of another select
ed Disclosure.</li>
</ol></li> </ol></li>
<li>Assemble the SD-JWT, including the Issuer-signed JWT and the selected Disclo sures (see <xref target="data_formats"/> for the format).</li> <li>Assemble the SD-JWT, including the Issuer-signed JWT and the selected Disclo sures (see <xref target="data_formats"/> for the format).</li>
<li><t>If Key Binding is not required:</t> <li><t>If Key Binding is not required:</t>
<ol spacing="compact"> <ol type="a" spacing="normal">
<li>Send the SD-JWT to the Verifier.</li> <li>Send the SD-JWT to the Verifier.</li>
</ol></li> </ol></li>
<li><t>If Key Binding is required:</t> <li><t>If Key Binding is required:</t>
<ol spacing="compact"> <ol type="a" spacing="normal">
<li>Create a Key Binding JWT tied to the SD-JWT.</li> <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>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> <li>Send the SD-JWT+KB to the Verifier.</li>
</ol></li> </ol></li>
</ol> </ol>
</section> </section>
<section anchor="verifier_verification"><name>Verification by the Verifier</name > <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 <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_verifi cation"/>, Verifiers need to ensure that</t> an SD-JWT+KB, in addition to the checks described in <xref target="sd_jwt_verifi cation"/>, Verifiers need to ensure that</t>
<ul spacing="compact"> <ul spacing="normal">
<li>if Key Binding is required, then the Holder has provided an SD-JWT+KB, and</ li> <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> <li>the Key Binding JWT is signed by the Holder and valid.</li>
</ul> </ul>
<t>To this end, Verifiers MUST follow the following steps (or equivalent):</t> <t>To this end, Verifiers <bcp14>MUST</bcp14> follow the following steps (or equ ivalent):</t>
<ol spacing="compact"> <ol type="1" spacing="normal">
<li>Determine if Key Binding is to be checked according to the Verifier's policy <li>Determine if Key Binding is to be checked according to the Verifier's policy
for the use case at hand. This decision MUST NOT be based on whether for the use case at hand. This decision <bcp14>MUST NOT</bcp14> be based on whet
a Key Binding JWT is provided by the Holder or not. Refer to <xref target="key_b her
inding_security"/> for or not a Key Binding JWT is provided by the Holder. Refer to <xref target="key_b
inding_security"/> for
details.</li> details.</li>
<li>If Key Binding is required and the Holder has provided an SD-JWT (without Ke y Binding), the Verifier MUST reject the presentation.</li> <li>If Key Binding is required and the Holder has provided an SD-JWT (without Ke y Binding), the Verifier <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 B inding JWT.</li> <li>If the Holder has provided an SD-JWT+KB, parse it into an SD-JWT and a Key B inding JWT.</li>
<li>Process the SD-JWT as defined in <xref target="sd_jwt_verification"/> to val idate the presentation and extract the payload.</li> <li>Process the SD-JWT as defined in <xref target="sd_jwt_verification"/> to val idate the presentation and extract the payload.</li>
<li><t>If Key Binding is required:</t> <li><t>If Key Binding is required:</t>
<ol spacing="compact"> <ol type="a" spacing="normal">
<li>Determine the public key for the Holder from the SD-JWT (see <xref target="k ey_binding"/>).</li> <li>Determine the public key for the Holder from the SD-JWT (see <xref target="k ey_binding"/>).</li>
<li>Ensure that a signing algorithm was used that was deemed secure for the appl <li>Ensure that a signing algorithm was used that was deemed secure for the appl
ication. Refer to <xref target="RFC8725"/>, Sections 3.1 and 3.2 for details. Th ication. Refer to <xref target="RFC8725"/>, Sections <xref target="RFC8725" sect
e <tt>none</tt> algorithm MUST NOT be accepted.</li> ion="3.1" sectionFormat="bare"/> and <xref target="RFC8725" section="3.2" sectio
<li>Validate the signature over the Key Binding JWT per Section 5.2 of <xref tar nFormat="bare"/> for details. The <tt>none</tt> algorithm <bcp14>MUST NOT</bcp14
get="RFC7515"/>.</li> > be accepted.</li>
<li>Validate the signature over the Key Binding JWT per <xref target="RFC7515" s
ection="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 <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 <t t>iat</tt> claim, is within an acceptable window.</li> <li>Check that the creation time of the Key Binding JWT, as determined by the <t t>iat</tt> claim, is within an acceptable window.</li>
<li>Determine that the Key Binding JWT is bound to the current transaction and w as created for this Verifier (replay detection) by validating <tt>nonce</tt> and <tt>aud</tt> claims.</li> <li>Determine that the Key Binding JWT is bound to the current transaction and w as 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 i n <xref target="integrity-protection-of-the-presentation"/> and verify that it m atches the value of the <tt>sd_hash</tt> claim in the Key Binding JWT.</li> <li>Calculate the digest over the Issuer-signed JWT and Disclosures as defined i n <xref target="integrity-protection-of-the-presentation"/> and verify that it m atches 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 <xr ef target="RFC7519"/> and <xref target="RFC8725"/>.</li> <li>Check that the Key Binding JWT is a valid JWT in all other respects, per <xr ef target="RFC7519"/> and <xref target="RFC8725"/>.</li>
</ol></li> </ol></li>
</ol> </ol>
<t>If any step fails, the presentation is not valid and processing MUST be abort ed.</t> <t>If any step fails, the presentation is not valid and processing <bcp14>MUST</ bcp14> be aborted.</t>
<t>Otherwise, the Processed SD-JWT Payload can be passed to the application to b e used for the intended purpose.</t> <t>Otherwise, the Processed SD-JWT Payload can be passed to the application to b e used for the intended purpose.</t>
</section> </section>
</section> </section>
<section anchor="json_serialization"><name>JWS JSON Serialization</name> <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 <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 is OPTIONAL. </t> Serialization from <xref target="RFC7515"/>. Supporting this format is <bcp14>OP TIONAL</bcp14>.</t>
<section anchor="json_serialization_unprotected_headers"><name>New Unprotected H eader Parameters</name> <section anchor="json_serialization_unprotected_headers"><name>New Unprotected H eader Parameters</name>
<t>For both the General and Flattened JSON Serialization, the SD-JWT or SD-JWT+K B is represented <t>For both the General and Flattened JSON Serialization, the SD-JWT or SD-JWT+K B is represented
as a JSON object according to Section 7.2 of <xref target="RFC7515"/>. The follo wing new as a JSON object according to <xref target="RFC7515" section="7.2"/>. The follow ing new
unprotected header parameters are defined:</t> unprotected header parameters are defined:</t>
<ul spacing="compact"> <dl spacing="normal">
<li><tt>disclosures</tt>: An array of strings where each element is an individua <dt><tt>disclosures</tt>:</dt><dd>An array of strings where each element is an i
l ndividual
Disclosure as described in <xref target="creating_disclosures"/>.</li> Disclosure as described in <xref target="creating_disclosures"/>.</dd>
<li><tt>kb_jwt</tt>: Present only in an SD-JWT+KB, the Key Binding JWT as descri <dt><tt>kb_jwt</tt>:</dt><dd>Present only in an SD-JWT+KB, the Key Binding JWT a
bed in <xref target="kb-jwt"/>.</li> s described in <xref target="kb-jwt"/>.</dd>
</ul> </dl>
<t>In an SD-JWT+KB, <tt>kb_jwt</tt> MUST be present when using the JWS JSON Seri <t>In an SD-JWT+KB, <tt>kb_jwt</tt> <bcp14>MUST</bcp14> be present when using th
alization, e JWS JSON Serialization,
and the digest in the <tt>sd_hash</tt> claim MUST be taken over the SD-JWT as de and the digest in the <tt>sd_hash</tt> claim <bcp14>MUST</bcp14> be taken over t
scribed he SD-JWT as described
in <xref target="integrity-protection-of-the-presentation"/>. This means that ev en when using in <xref target="integrity-protection-of-the-presentation"/>. This means that ev en when using
the JWS JSON Serialization, the representation as a regular SD-JWT Compact Seria lization MUST be the JWS JSON Serialization, the representation as a regular SD-JWT Compact Seria lization <bcp14>MUST</bcp14> be
created temporarily to calculate the digest. In detail, the SD-JWT Compact Seria lization part is built created temporarily to calculate the digest. In detail, the SD-JWT Compact Seria lization part is built
by concatenating the protected header, the payload, and the signature of the JWS 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 th e JSON serialized SD-JWT using a <tt>.</tt> character as a separator, and using th e
Disclosures from the <tt>disclosures</tt> member of the unprotected header.</t> 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 di gest, and <t>Unprotected headers other than <tt>disclosures</tt> are not covered by the di gest, and
therefore, as usual, are not protected against tampering.</t> therefore, as usual, are not protected against tampering.</t>
</section> </section>
<section anchor="flattened-json-serialization"><name>Flattened JSON Serializatio n</name> <section anchor="flattened-json-serialization"><name>Flattened JSON Serializatio n</name>
<t>In case of the Flattened JSON Serialization, there is only one unprotected <t>In the case of Flattened JSON Serialization, there is only one unprotected
header.</t> header.</t>
<t>The following is a non-normative example of a JWS JSON serialized SD-JWT as <t>The following is a non-normative example of a JWS JSON serialized SD-JWT as
issued using the Flattened JSON Serialization:</t> issued using the Flattened JSON Serialization:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"header": { "header": {
"disclosures": [ "disclosures": [
"WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICJqb2huX2RvZV80M "WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICJqb2huX2RvZV80M
iJd", iJd",
"WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob
iJd", iJd",
"WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ
SJd", SJd",
"WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImJpcnRoZGF0ZSIsICIxOTQwL "WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImJpcnRoZGF0ZSIsICIxOTQwL
TAxLTAxIl0" TAxLTAxIl0"
skipping to change at line 1385 skipping to change at line 1624
Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
"protected": "protected":
"eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
"signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK "signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK
y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ" y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>The following is an SD-JWT+KB with two Disclosures:</t> <t>The following is an SD-JWT+KB with two Disclosures:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"header": { "header": {
"disclosures": [ "disclosures": [
"WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ
SJd", SJd",
"WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob
iJd" iJd"
], ],
"kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25j "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25j
ZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW ZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW
1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlZqdFBz 1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlZqdFBz
skipping to change at line 1420 skipping to change at line 1660
"protected": "protected":
"eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
"signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK "signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK
y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ" y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"
} }
]]> ]]>
</sourcecode> </sourcecode>
</section> </section>
<section anchor="general-json-serialization"><name>General JSON Serialization</n ame> <section anchor="general-json-serialization"><name>General JSON Serialization</n ame>
<t>In case of the General JSON Serialization, there are multiple unprotected <t>In the case of General JSON Serialization, there are multiple unprotected
headers (one per signature). If present, <tt>disclosures</tt> and <tt>kb_jwt</tt headers (one per signature). If present, <tt>disclosures</tt> and <tt>kb_jwt</tt
>, MUST be > <bcp14>MUST</bcp14> be
included in the first unprotected header and MUST NOT be present in any included in the first unprotected header and <bcp14>MUST NOT</bcp14> be present
in any
following unprotected headers.</t> following unprotected headers.</t>
<t>The following is a non-normative example of a presentation of a JWS JSON <t>The following is a non-normative example of a presentation of a JWS JSON
serialized SD-JWT including a Key Binding JWT using the General JSON serialized SD-JWT, including a Key Binding JWT using the General JSON
Serialization:</t> Serialization:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk
U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl
JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS
IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG
ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi
I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG
lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm
Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
skipping to change at line 1480 skipping to change at line 1721
] ]
} }
]]> ]]>
</sourcecode> </sourcecode>
</section> </section>
<section anchor="verification-of-the-jws-json-serialized-sd-jwt"><name>Verificat ion of the JWS JSON Serialized SD-JWT</name> <section anchor="verification-of-the-jws-json-serialized-sd-jwt"><name>Verificat ion of the JWS JSON Serialized SD-JWT</name>
<t>Verification of the JWS JSON serialized SD-JWT follows the rules defined in <t>Verification of the JWS JSON serialized SD-JWT follows the rules defined in
<xref target="verification"/>, except for the following aspects:</t> <xref target="verification"/>, except for the following aspects:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>The SD-JWT or SD-JWT+KB does not need to be split into component parts and t he Disclosures <li>The SD-JWT or SD-JWT+KB does not need to be split into component parts and t he Disclosures
can be found in the <tt>disclosures</tt> member of the unprotected header.</li> 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 Verifier MUST <li>To verify the digest in <tt>sd_hash</tt> in the Key Binding JWT of an SD-JWT +KB, the Verifier <bcp14>MUST</bcp14>
assemble the string to be hashed as described in assemble the string to be hashed as described in
<xref target="json_serialization_unprotected_headers"/>.</li> <xref target="json_serialization_unprotected_headers"/>.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="security_considerations"><name>Security Considerations</name> <section anchor="security_considerations"><name>Security Considerations</name>
<t>Security considerations in this section help achieve the following properties <t>The security considerations help achieve the following properties:</t>
:</t>
<t><strong>Selective Disclosure:</strong> An adversary in the role of the Verifi
er cannot obtain
information from an SD-JWT about any claim name or claim value that was not
explicitly disclosed by the Holder unless that information can be derived from
other disclosed claims or sources other than the presented SD-JWT.</t>
<t><strong>Integrity:</strong> 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 appl
ication of Key Binding can ensure that the presenter of an SD-JWT credential is
the Holder of the credential.</t>
<section anchor="sec-is-jwt"><name>Mandatory Signing of the Issuer-signed JWT</n <dl spacing="normal" newline="true">
ame> <dt><strong>Selective Disclosure:</strong></dt><dd>An adversary in the role
<t>The JWT MUST be signed by the Issuer to protect the integrity of the issued of the Verifier cannot obtain information from an SD-JWT about any claim
name or claim value that was not explicitly disclosed by the Holder unless
that information can be derived from other disclosed claims or sources other
than the presented SD-JWT.</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 appl
ication of Key Binding can ensure that the presenter of an SD-JWT credential is
the Holder of the credential.</t></dd></dl>
<section anchor="sec-is-jwt"><name>Mandatory Signing of the Issuer-Signed JWT</n
ame>
<t>The JWT <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., 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 change the "email" attribute to take over the victim's account or add an
attribute indicating a fake academic qualification).</t> attribute indicating a fake academic qualification).</t>
<t>The Verifier MUST always check the signature of the Issuer-signed JWT to ensu <t>The Verifier <bcp14>MUST</bcp14> always check the signature of the Issuer-sig
re that it ned JWT to ensure that it
has not been tampered with since the issuance. The Issuer-signed JWT MUST be rej has not been tampered with since its issuance. The Issuer-signed JWT <bcp14>MUST
ected if the signature cannot be verified.</t> </bcp14> be rejected if the signature cannot be verified.</t>
<t>The security of the Issuer-signed JWT depends on the security of the signatur e algorithm. <t>The security of the Issuer-signed JWT depends on the security of the signatur e algorithm.
Per the last paragraph of Section 5.2 of <xref target="RFC7515"/>, it is an Per the last paragraph of <xref target="RFC7515" section="5.2"/>, it is an
application-specific decision to choose the appropriate JWS application-specific decision to choose the appropriate JWS
algorithm from <xref target="IANA.JWS.Algorithms"/>, including post-quantum algo rithms, when they are ready.</t> algorithm from <xref target="JWS.Algs"/>, including post-quantum algorithms, whe n they are ready.</t>
</section> </section>
<section anchor="sec-disclosures"><name>Manipulation of Disclosures</name> <section anchor="sec-disclosures"><name>Manipulation of Disclosures</name>
<t>Holders can manipulate the Disclosures by changing the values of the claims <t>Holders can manipulate the Disclosures by changing the values of the claims
before sending them to the Verifier. The Verifier MUST check the Disclosures to before sending them to the Verifier. The Verifier <bcp14>MUST</bcp14> check the Disclosures to
ensure that the values of the claims are correct, i.e., the digests of the Discl osures are actually present in the signed SD-JWT.</t> ensure that the values of the claims are correct, i.e., the digests of the Discl osures are actually present in the signed SD-JWT.</t>
<t>A naive Verifier that extracts <t>A naive Verifier that extracts
all claim values from the Disclosures (without checking the hashes) and inserts them into the SD-JWT payload 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 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 Disclosures, such an implementation could not determine the correct place in a
nested object where a claim needs to be inserted. Therefore, the naive implement ation nested object where a claim needs to be inserted. Therefore, the naive implement ation
would not only be insecure, but also incorrect.</t> would not only be insecure, but also incorrect.</t>
<t>The steps described in <xref target="verifier_verification"/> ensure that the Verifier <t>The steps described in <xref target="verifier_verification"/> ensure that the Verifier
checks the Disclosures correctly.</t> checks the Disclosures correctly.</t>
</section> </section>
<section anchor="salt-entropy"><name>Entropy of the Salt</name> <section anchor="salt-entropy"><name>Entropy of the Salt</name>
<t>The security model that conceals the plaintext claims relies on the high entr opy <t>The security model that conceals the plaintext claims relies on the high entr opy
random data of the salt as additional input to the hash function. The randomness 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 val ue. It also ensures that the same plaintext claim value does not produce the same digest val ue. It also
makes it infeasible to guess the preimage of the digest (thereby learning the makes it infeasible to guess the preimage of the digest (thereby learning the
plaintext claim value) by enumerating the potential value plaintext claim value) by enumerating the potential value
space for a claim into the hash function to search for a matching digest 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 gue ssed, It is therefore vitally important that unrevealed salts cannot be learned or gue ssed,
even if other salts have been revealed. As such, each salt MUST be created even if other salts have been revealed. As such, each salt <bcp14>MUST</bcp14> b e created
in such a manner that it is cryptographically random, sufficiently long, and in such a manner that it is cryptographically random, sufficiently long, and
has high enough entropy that it is infeasible to guess. A has high enough entropy that it is infeasible to guess. A
new salt MUST be chosen for each claim independently of other salts. new salt <bcp14>MUST</bcp14> be chosen for each claim independently of other sal
See Randomness Requirements for Security <xref target="RFC4086"/> for considerat ts.
ions See "Randomness Requirements for Security" <xref target="RFC4086"/> for consider
ations
on generating random values.</t> on generating random values.</t>
<t>The RECOMMENDED minimum length of the randomly-generated portion of the salt <t>The <bcp14>RECOMMENDED</bcp14> minimum length of the randomly generated porti
is 128 bits.</t> on of the salt is 128 bits.</t>
<t>The Issuer MUST ensure that a new salt value is chosen for each claim, <t>The Issuer <bcp14>MUST</bcp14> ensure that a new salt value is chosen for eac
h claim,
including when the same claim name occurs at different places in the 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="exampl e-complex-structured-sd-jwt"/>, structure of the SD-JWT. This can be seen in the example in <xref target="exampl e-complex-structured-sd-jwt"/>,
where multiple claims with the name <tt>type</tt> appear, but each of them has where multiple claims with the name <tt>type</tt> appear, but each of them has
a different salt.</t> a different salt.</t>
</section> </section>
<section anchor="choice-of-a-hash-algorithm"><name>Choice of a Hash Algorithm</n ame> <section anchor="choice-of-a-hash-algorithm"><name>Choice of a Hash Algorithm</n ame>
<t>To ensure privacy of claims that are selectively disclosable, but are not bei <!-- [rfced] We are wondering whether "but" should be "and" here? That is, it m
ng disclosed in a given presentation, ust be preimage resistant and not allow an observer to infer any partial informa
the hash function MUST ensure that it is infeasible to calculate any portion of tion?
the three elements
(salt, claim name, claim value) from a particular digest. This implies the hash Original:
function MUST 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 selectively disclosable but are not bein
g disclosed in a given presentation,
the hash function <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
function <bcp14>MUST</bcp14>
be preimage resistant, but should also not allow an observer to infer any partia l information about be preimage resistant, but should also not allow an observer to infer any partia l information about
the undisclosed content. In the terminology of cryptographic commitment schemes, the hash function the undisclosed content. In the terminology of cryptographic commitment schemes, the hash function
needs to be computationally hiding.</t> needs to be computationally hiding.</t>
<t>To ensure the integrity of selectively disclosable claims, the hash function <t>To ensure the integrity of selectively disclosable claims, the hash function
MUST be second-preimage <bcp14>MUST</bcp14> be second-preimage
resistant. That is, for any combination of salt, claim name and claim value, it resistant. That is, for any combination of salt, claim name, and claim value, it
is infeasible to find a different combination of salt, is infeasible to find a different combination of salt,
claim name and claim value that result in the same digest.</t> claim name, and claim value that results in the same digest.</t>
<t>The hash function SHOULD also be collision resistant. Although not essential <t>The hash function <bcp14>SHOULD</bcp14> also be collision resistant. Although
to the anticipated uses of not essential to the anticipated uses of
SD-JWT, without collision resistance an Issuer may be able to find multiple disc losures that have the SD-JWT, without collision resistance an Issuer may be able to find multiple disc losures that have the
same hash value. In which case, the signature over the SD-JWT would not then com mit the Issuer to the contents of the same hash value. In which case, the signature over the SD-JWT would not then com mit the Issuer to the contents of the
JWT. The collision resistance of the hash function used to generate digests SHOU LD JWT. The collision resistance of the hash function used to generate digests <bcp 14>SHOULD</bcp14>
match the collision resistance of the hash function used by the signature scheme . For example, use of 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 l east 256-bit collision the ES512 signature algorithm would require a disclosure hash function with at l east 256-bit collision
resistance, such as SHA-512.</t> resistance, such as SHA-512.</t>
<t>Inclusion in the "Named Information Hash Algorithm" registry <xref target="IA NA.Hash.Algorithms"/> <t>Inclusion in the "Named Information Hash Algorithm Registry" <xref target="Ha sh.Algs"/>
alone does not indicate a hash algorithm's suitability for use in SD-JWT (it con tains several alone does not indicate a hash algorithm's suitability for use in SD-JWT (it con tains several
heavily truncated digests, such as <tt>sha-256-32</tt> and <tt>sha-256-64</tt>, which are unfit for security heavily truncated digests, such as <tt>sha-256-32</tt> and <tt>sha-256-64</tt>, which are unfit for security
applications).</t> applications).</t>
</section> </section>
<section anchor="key_binding_security"><name>Key Binding</name> <section anchor="key_binding_security"><name>Key Binding</name>
<t>Key Binding aims to ensure that the presenter of an SD-JWT credential is actu ally the Holder of the credential. <t>Key Binding aims to ensure that the presenter of an SD-JWT credential is actu ally 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. 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> 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 <t>Without Key Binding, a Verifier only gets the proof that the
credential was issued by a particular Issuer, but the credential itself 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 can be replayed by anyone who gets access to it. This means that, for
example, after a credential was leaked to an attacker, the attacker can example, after the credential was leaked to an attacker, the attacker can
present the credential to any verifier that does not require a present the credential to any Verifier that does not require a
binding. But also a malicious Verifier to which the Holder presented the binding. Also, a malicious Verifier to which the Holder presented the
credential can present the credential to another Verifier if that other credential can present the credential to another Verifier if that other
Verifier does not require Key Binding.</t> Verifier does not require Key Binding.</t>
<t>Verifiers MUST decide whether Key Binding is required for a <t>Verifiers <bcp14>MUST</bcp14> decide whether Key Binding is required for a
particular use case before verifying a credential. This decision particular use case before verifying a credential. This decision
can be informed by various factors including, but not limited to the following: can be informed by various factors including but not limited to the following:
business requirements, the use case, the type of business requirements, the use case, the type of
binding between a Holder and its credential that is required for a use 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 case, the sensitivity of the use case, the expected properties of a
credential, the type and contents of other credentials expected to be credential, the type and contents of other credentials expected to be
presented at the same time, etc.</t> presented at the same time, etc.</t>
<t>It is important that a Verifier does not make its security policy <t>It is important that a Verifier not make its security policy
decisions based on data that can be influenced by an attacker. For this reason, decisions based on data that can be influenced by an attacker. For this reason,
when deciding whether Key when deciding whether or not Key
Binding is required or not, Verifiers MUST NOT take into account Binding is required, Verifiers <bcp14>MUST NOT</bcp14> take into account
whether the Holder has provided an SD-JWT+KB or a bare SD-JWT, since otherwise a whether the Holder has provided an SD-JWT+KB or a bare SD-JWT; otherwise, an
n attacker could strip the KB-JWT from an SD-JWT+KB and present the resultant SD-J
attacker could strip the KB-JWT from an SD-JWT+KB and present the resulting SD-J WT.</t>
WT.</t> <t>Furthermore, Verifiers should be aware that Key Binding information may have
<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
been added to an SD-JWT in a format that they do not recognize and therefore may not be able to tell whether or not the SD-JWT supports Key Binding.</t>
not be able to tell whether the SD-JWT supports Key Binding or not.</t>
<t>If a Verifier determines that Key Binding is required for a <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 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 an invalid Key Binding JWT, then the Verifier will reject the presentation
when following the verification steps described in <xref target="verifier_verifi cation"/>.</t> when following the verification steps described in <xref target="verifier_verifi cation"/>.</t>
</section> </section>
<section anchor="concealing-claim-names"><name>Concealing Claim Names</name> <section anchor="concealing-claim-names"><name>Concealing Claim Names</name>
<t>SD-JWT ensures that names of claims that are selectively disclosable are <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 attacke r from learning the names of such always concealed unless the claim's value is disclosed. This prevents an attacke r from learning the names of such
claims. However, the names of the claims that are permanently claims. However, the names of the claims that are permanently
disclosed are not hidden. This includes the keys of objects that themselves disclosed are not hidden. This includes the keys of objects that themselves
are not concealed, but contain concealed claims. This limitation are not concealed, but contain concealed claims. This limitation
needs to be taken into account by Issuers when creating the structure of needs to be taken into account by Issuers when creating the structure of
the SD-JWT.</t> the SD-JWT.</t>
</section> </section>
<section anchor="sd-validity-claims"><name>Selectively-Disclosable Validity Clai <section anchor="sd-validity-claims"><name>Selectively Disclosable Validity Clai
ms</name> ms</name>
<t>An Issuer MUST NOT allow any content to be selectively disclosable that is cr <t>An Issuer <bcp14>MUST NOT</bcp14> allow any content to be selectively disclos
itical for evaluating the able that is critical for evaluating the
SD-JWT's authenticity or validity. SD-JWT's authenticity or validity.
The exact list of such content will depend on the application The exact list of such content will depend on the application
and SHOULD be listed by any application-specific profiles of SD-JWT. and <bcp14>SHOULD</bcp14> be listed by any application-specific profiles of SD-J
The following is a list of registered JWT claim names that SHOULD be considered WT.
as The following is a list of registered JWT claim names that <bcp14>SHOULD</bcp14>
security-critical:</t> be considered as
security critical:</t>
<ul spacing="compact"> <ul spacing="normal">
<li><tt>iss</tt> (Issuer)</li> <li><tt>iss</tt> (Issuer)</li>
<li><tt>aud</tt> (Audience), although issuers MAY allow individual entries in th e array to be selectively disclosable</li> <li><tt>aud</tt> (Audience), although issuers <bcp14>MAY</bcp14> allow individua l entries in the array to be selectively disclosable</li>
<li><tt>exp</tt> (Expiration Time)</li> <li><tt>exp</tt> (Expiration Time)</li>
<li><tt>nbf</tt> (Not Before)</li> <li><tt>nbf</tt> (Not Before)</li>
<li><tt>cnf</tt> (Confirmation Key)</li> <li><tt>cnf</tt> (Confirmation Key)</li>
</ul> </ul>
<t>Issuers will typically include claims controlling the validity of the SD-JWT <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 they would do so. Therefore, Verifiers cannot in plaintext in the SD-JWT payload, but there is no guarantee they will do so. T herefore, Verifiers cannot
reliably depend on that and need to operate as though security-critical claims m ight be reliably depend on that and need to operate as though security-critical claims m ight be
selectively disclosable.</t> selectively disclosable.</t>
<t>Verifiers therefore MUST ensure that all claims they deem necessary for check ing <t>Verifiers therefore <bcp14>MUST</bcp14> ensure that all claims they deem nece ssary for checking
the validity of an SD-JWT in the given context are present (or disclosed, respec tively) during the validity of an SD-JWT in the given context are present (or disclosed, respec tively) during
validation of the SD-JWT. This is implemented in the last validation of the SD-JWT. This is implemented in the last
step of the verification defined in <xref target="sd_jwt_verification"/>.</t> 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 <t>The precise set of required validity claims will typically be defined by
operating environment rules, application-specific profile, or the credential for mat and MAY include claims other than operating environment rules, an application-specific profile, or the credential format, and <bcp14>MAY</bcp14> include claims other than
those listed herein.</t> those listed herein.</t>
</section> </section>
<section anchor="issuer_signature_key_distribution"><name>Distribution and Rotat ion of Issuer Signature Verification Key</name> <section anchor="issuer_signature_key_distribution"><name>Distribution and Rotat ion of Issuer Signature Verification Key</name>
<t>This specification does not define how signature verification keys of <t>This specification does not define how signature verification keys of
Issuers are distributed to Verifiers. However, it is RECOMMENDED that Issuers are distributed to Verifiers. However, it is <bcp14>RECOMMENDED</bcp14> that
Issuers publish their keys in a way that allows for efficient and secure Issuers publish their keys in a way that allows for efficient and secure
key rotation and revocation, for example, by publishing keys at a key rotation and revocation, for example, by publishing keys at a
predefined location using the JSON Web Key Set (JWKS) format <xref target="RFC75 17"/>. predefined location using the JSON Web Key Set (JWKS) format <xref target="RFC75 17"/>.
Verifiers need to ensure that they are not using expired or revoked keys Verifiers need to ensure that they are not using expired or revoked keys
for signature verification using reasonable and appropriate means for the given for signature verification using reasonable and appropriate means for the given
key-distribution method.</t> key-distribution method.</t>
</section> </section>
<section anchor="forwarding-credentials"><name>Forwarding Credentials</name> <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 <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. that does not enforce Key Binding.
When doing so, that entity may remove Disclosures such that the receiver 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> 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 <t>For example, a device manufacturer might produce an SD-JWT
containing information about upstream and downstream supply chain contributors. containing information about upstream and downstream supply chain contributors.
Each supply chain party can verify only the claims that were selectively disclos ed to them Each supply chain party can verify only the claims that were selectively disclos ed to them
by an upstream party, and they can choose to further reduce the disclosed claims by an upstream party, and they can choose to further reduce the disclosed claims
when presenting to a downstream party.</t> when presenting to a downstream party.</t>
<t>In some scenarios this behavior could be desirable, <t>In some scenarios, this behavior could be desirable;
but if it is not, Issuers need to support and Verifiers need to enforce Key Bind if it is not, Issuers need to support and Verifiers need to enforce Key Binding.
ing.</t> </t>
</section> </section>
<section anchor="integrity-of-sd-jwts-and-sd-jwt-kbs"><name>Integrity of SD-JWTs and SD-JWT+KBs</name> <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 is integrity-protected by the Issuer's <t>With an SD-JWT, the Issuer-signed JWT is integrity protected by the Issuer's
signature, and the values of the Disclosures are integrity-protected by the dige signature, and the values of the Disclosures are integrity protected by the dige
sts sts
included therein. The specific set of Disclosures, however, included therein. The specific set of Disclosures, however,
is not integrity-protected; the SD-JWT can be modified by adding or is not integrity protected; the SD-JWT can be modified by adding or
removing Disclosures and still be valid.</t> removing Disclosures and still be valid.</t>
<t>With an SD-JWT+KB, the set of selected Disclosures is integrity-protected. <t>With an SD-JWT+KB, the set of selected Disclosures is integrity protected.
The signature in the Key Binding JWT covers a The signature in the Key Binding JWT covers a
specific SD-JWT, with a specific Issuer-signed JWT and a specific set of 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 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 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 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 that the Holder intended to send; no intermediate party has added, removed, or
modified the list of Disclosures.</t> modified the list of Disclosures.</t>
</section> </section>
<section anchor="explicit_typing"><name>Explicit Typing</name> <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 <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 whic h one kind of JWT is mistaken for another. SD-JWTs are also potentially (described in <xref target="RFC8725" sectionFormat="of" section="2.8"/>) in whic h 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 is subject to such confusion attacks, so in the absence of other techniques, it is
RECOMMENDED that application profiles of SD-JWT specify an explicit type <bcp14>RECOMMENDED</bcp14> that application profiles of SD-JWT specify an explic
by including the <tt>typ</tt> header parameter when the SD-JWT is issued, and fo it type
r Verifiers to check this value.</t> by including the <tt>typ</tt> header parameter when the SD-JWT is issued, and th
<t>When explicit typing using the <tt>typ</tt> header is employed for an SD-JWT, at Verifiers check this value.</t>
it is RECOMMENDED that a media type name of the format <t>When explicit typing using the <tt>typ</tt> header is employed for an SD-JWT,
it is <bcp14>RECOMMENDED</bcp14> that a media type name of the format
"application/example+sd-jwt" be used, where "example" is replaced by the identif ier for the specific kind of SD-JWT. "application/example+sd-jwt" be used, where "example" is replaced by the identif ier for the specific kind of SD-JWT.
The definition of <tt>typ</tt> in Section 4.1.9 of <xref target="RFC7515"/> reco mmends that the "application/" prefix be omitted, so The definition of <tt>typ</tt> in <xref target="RFC7515" section="4.1.9"/> recom mends that the "application/" prefix be omitted, so
"example+sd-jwt" would be the value of the <tt>typ</tt> header parameter.</t> "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 J SON objects, or different kinds of JWT Claim Sets.</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 J SON objects or different kinds of JWT Claim Sets.</t>
</section> </section>
<section anchor="key-pair-generation-and-lifecycle-management"><name>Key Pair Ge neration and Lifecycle Management</name> <section anchor="key-pair-generation-and-lifecycle-management"><name>Key Pair Ge neration and Lifecycle Management</name>
<t>Implementations of SD-JWT rely on asymmetric cryptographic keys and must ther efore ensure that key pair generation, <t>Implementations of SD-JWT rely on asymmetric cryptographic keys and must ther efore ensure that key pair generation,
handling, storage, and lifecycle management are performed securely.</t> 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 <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"/>. 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> This includes:</t>
<ul spacing="compact"> <ul>
<li>Secure Generation: Using cryptographically secure methods and random number <li>Secure Generation: Using cryptographically secure methods and random number
generators.</li> generators.</li>
<li>Secure Storage: Protecting private keys from unauthorized access.</li> <li>Secure Storage: Protecting private keys from unauthorized access.</li>
<li>Lifecycle Management: Ensuring secure key rotation, revocation, and disposal <li>Lifecycle Management: Ensuring secure key rotation, revocation, and disposa
as needed.</li> l as needed.</li>
</ul> </ul>
<t>Appropriate key management is essential, as any compromise can lead to unauth orized disclosure or forgery of SD-JWTs.</t> <t>Appropriate key management is essential, as any compromise can lead to unauth orized disclosure or forgery of SD-JWTs.</t>
</section> </section>
</section> </section>
<section anchor="privacy_considerations"><name>Privacy Considerations</name> <section anchor="privacy_considerations"><name>Privacy Considerations</name>
<section anchor="unlinkability"><name>Unlinkability</name> <section anchor="unlinkability"><name>Unlinkability</name>
<t>Unlinkability is a property whereby adversaries are prevented from correlatin g <t>Unlinkability is a property whereby adversaries are prevented from correlatin g
credential presentations of the same user beyond the user's consent. credential presentations of the same user beyond the user's consent.
Without unlinkability, an adversary might be able to learn more about the user t han the user Without unlinkability, an adversary might be able to learn more about the user t han the user
intended to disclose, for example:</t> intended to disclose, for example:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>Cooperating Verifiers might want to track users across services to build <li>Cooperating Verifiers might want to track users across services to build
advertising profiles.</li> advertising profiles.</li>
<li>Issuers might want to track where users present their credentials to enable <li>Issuers might want to track where users present their credentials to enable
surveillance.</li> surveillance.</li>
<li>After a data breach at multiple Verifiers, publicly available information <li>After a data breach at multiple Verifiers, publicly available information
might allow linking identifiable information presented to Verifier A with might allow linking identifiable information presented to Verifier A with
originally anonymous information presented to Verifier B, therefore revealing originally anonymous information presented to Verifier B, therefore revealing
the identities of users of Verifier B.</li> the identities of users of Verifier B.</li>
</ul> </ul>
<t>The following types of unlinkability are discussed below:</t> <t>The following types of unlinkability are discussed below:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>Presentation Unlinkability: A Verifier should not be able to link two <li>Presentation Unlinkability: A Verifier should not be able to link two
presentations of the same credential.</li> presentations of the same credential.</li>
<li>Verifier/Verifier Unlinkability: The presentations made to two different <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 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 presenta tions Verifiers collude, or if they are forced by a third party to reveal the presenta tions
made to them, or data leaks from one Verifier to the other).</li> made to them, or data leaks from one Verifier to the other).</li>
<li>Issuer/Verifier Unlinkability (Honest Verifier): An Issuer of a credential <li>Issuer/Verifier Unlinkability (Honest Verifier): An Issuer of a credential
should not be able to know that a user presented this credential unless should not be able to know that a user presented this credential unless
the Verifier is sharing presentation data with the Issuer the Verifier is sharing presentation data with the Issuer
accidentally, deliberately, or because it is forced to do so.</li> accidentally, deliberately, or because it is forced to do so.</li>
<li>Issuer/Verifier Unlinkability (Careless/Colluding/Compromised/Coerced Verifi er): An Issuer of a <li>Issuer/Verifier Unlinkability (Careless/Colluding/Compromised/Coerced Verifi er): >An Issuer of a
credential should under no circumstances be able to tell that a user presented t his credential to credential should under no circumstances be able to tell that a user presented t his credential to
a certain Verifier. In particular this includes cases when the Verifier accident ally or deliberately shares a certain Verifier. In particular, this includes cases when the Verifier acciden tally or deliberately shares
presentation data with the Issuer or is forced to do so.</li> presentation data with the Issuer or is forced to do so.</li>
</ul> </ul>
<t>In all cases, unlinkability is limited to cases where the disclosed claims do <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 not contain information that directly or indirectly identifies the user. For
example, when a taxpayer identification number is contained in the disclosed cla ims, the Issuer and example, when a taxpayer identification number is contained in the disclosed cla ims, the Issuer and
Verifier can easily link the user's transactions. However, when the user only 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 t he same user.</t> 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 t he same user.</t>
<t>Issuer/Verifier unlinkability with a careless, colluding, compromised, or coe rced Verifier cannot be <t>Issuer/Verifier unlinkability with a careless, colluding, compromised, or coe rced Verifier cannot be
achieved in salted-hash based selective disclosure approaches, such as SD-JWT, a s the achieved in salted hash-based selective disclosure approaches, such as SD-JWT, a s the
issued credential with the Issuer's signature is directly presented to the Verif ier, who can forward it to issued credential with the Issuer's signature is directly presented to the Verif ier, who can forward it to
the Issuer. To reduce the risk of revealing the data later on, <xref target="dat a_storage"/> defines the Issuer. To reduce the risk of revealing the data later on, <xref target="dat a_storage"/> defines
requirements to reduce the amount of data stored.</t> requirements to reduce the amount of data stored.</t>
<t>In considering Issuer/Verifier unlinkability, it is important to note the pot ential for an asymmetric power dynamic <t>In considering Issuer/Verifier unlinkability, it is important to note the pot ential for an asymmetric power dynamic
between Issuers and Verifiers. This dynamic can compel an otherwise honest Verif ier into collusion. between Issuers and Verifiers. This dynamic can compel an otherwise Honest Verif ier into collusion.
For example, a governmental Issuer might have the authority to mandate that a Ve rifier report back information For example, a governmental Issuer might have the authority to mandate that a Ve rifier report back information
about the credentials presented to it. Legal requirements could further enforce this, explicitly undermining about the credentials presented to it. Legal requirements could further enforce this, explicitly undermining
Issuer/Verifier unlinkability. Similarly, a large service provider issuing crede ntials might implicitly pressure Issuer/Verifier unlinkability. Similarly, a large service provider issuing crede ntials might implicitly pressure
Verifiers into collusion by incentivizing participation in their larger operatin g environment. Verifiers into collusion by incentivizing participation in their larger operatin g environment.
Deployers of SD-JWT must be aware of these potential power dynamics, 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> mitigate them as much as possible, and/or make the risks transparent to the user .</t>
<t>Contrary to that, Issuer/Verifier unlinkability with an honest Verifier can g enerally be achieved. <t>Contrary to that, Issuer/Verifier unlinkability with an Honest Verifier can g enerally be achieved.
However, a callback from the Verifier to the Issuer, such as a revocation check, could potentially 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. disclose information about the credential's usage to the Issuer.
Where such callbacks are necessary, they need to be executed in a manner that 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 Issu er preserves privacy and does not disclose details about the credential to the Issu er
(the mechanism described in <xref target="I-D.ietf-oauth-status-list"/> is an ex ample of an approach (the mechanism described in <xref target="I-D.ietf-oauth-status-list"/> is an ex ample of an approach
with minimal information disclosure towards the Issuer). It is that discloses minimal information towards the Issuer). It is
important to note that the timing of such requests could potentially serve as a important to note that the timing of such requests could potentially serve as a
side-channel.</t> side channel.</t>
<t>Verifier/Verifier unlinkability and presentation unlinkability can be achieve d using batch issuance: A batch <t>Verifier/Verifier unlinkability and presentation unlinkability can be achieve d using batch issuance: A batch
of credentials based on the same claims is issued to the Holder instead of just 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 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 Verifier or even for each session with a Verifier. New key binding keys and
salts MUST be used for each credential in the batch to ensure that the Verifiers salts <bcp14>MUST</bcp14> be used for each credential in the batch to ensure tha t the Verifiers
cannot link the credentials using these values. Likewise, claims carrying time cannot link the credentials using these values. Likewise, claims carrying time
information, like <tt>iat</tt>, <tt>exp</tt>, and <tt>nbf</tt>, MUST either be r andomized within a information, like <tt>iat</tt>, <tt>exp</tt>, and <tt>nbf</tt>, <bcp14>MUST</bcp 14> either be randomized within a
time period considered appropriate (e.g., randomize <tt>iat</tt> within the last 24 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 hours and calculate <tt>exp</tt> accordingly) or rounded (e.g., rounded down to the
beginning of the day).</t> beginning of the day).</t>
<t>SD-JWT only conceals the value of claims that are not revealed. <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 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 sam e particular, colluding Verifiers and Issuers can know when they have seen the sam e
credential no matter what fields have been disclosed, even when none have been d isclosed. credential no matter what fields have been disclosed, even when none have been d isclosed.
This behavior may not align with what users naturally anticipate or are guided t o This behavior may not align with what users naturally anticipate or are guided t o
expect from user interface interactions, potentially causing them to make decisi ons expect from user-interface interactions, potentially causing them to make decisi ons
they might not otherwise make. Workarounds such as batch issuance, as they might not otherwise make. Workarounds such as batch issuance, as
described above, help with keeping described above, help with keeping
Verifiers from linking different presentations, but cannot work for Issuer/Verif ier unlinkability. Verifiers from linking different presentations, but cannot work for Issuer/Verif ier unlinkability.
This issue applies to all salted hash-based approaches, This issue applies to all salted hash-based approaches,
including mDL/mDoc <xref target="ISO.18013-5"/> and SD-CWT <xref target="I-D.iet f-spice-sd-cwt"/>.</t> including mDL/mDoc <xref target="ISO.18013-5"/> and SD-CWT <xref target="I-D.iet f-spice-sd-cwt"/>.</t>
</section> </section>
<section anchor="data_storage"><name>Storage of User Data</name> <section anchor="data_storage"><name>Storage of User Data</name>
<t>Wherever user data is stored, it represents a potential <t>Wherever user data is stored, it represents a potential
target for an attacker. This target can be of particularly target for an attacker. This target can be of particularly
skipping to change at line 1810 skipping to change at line 2089
signed ID Tokens can be stored by Relying Parties. In the case of signed ID Tokens can be stored by Relying Parties. In the case of
SD-JWT, Holders have to store SD-JWTs, SD-JWT, Holders have to store SD-JWTs,
and Issuers and Verifiers may decide to do so as well.</t> 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 <t>Not surprisingly, a leak of such data risks revealing private data of users
to third parties. Signed user data, the authenticity of which to third parties. Signed user data, the authenticity of which
can be easily verified by third parties, further exacerbates the risk. can be easily verified by third parties, further exacerbates the risk.
As discussed in <xref target="key_binding_security"/>, leaked As discussed in <xref target="key_binding_security"/>, leaked
SD-JWTs may also allow attackers to impersonate Holders unless Key SD-JWTs may also allow attackers to impersonate Holders unless Key
Binding is enforced and the attacker does not have access to the Binding is enforced and the attacker does not have access to the
Holder's cryptographic keys.</t> Holder's cryptographic keys.</t>
<t>Due to these risks, and the risks described in <xref target="unlinkability"/> <t>Due to these risks, and the risks described in <xref target="unlinkability"/>
, systems implementing SD-JWT SHOULD be designed to minimize , systems implementing SD-JWT <bcp14>SHOULD</bcp14> be designed to minimize
the amount of data that is stored. All involved parties SHOULD NOT store SD-JWTs the amount of data that is stored. All involved parties <bcp14>SHOULD NOT</bcp14
longer than strictly needed, including in log files.</t> > store SD-JWTs
<t>After Issuance, Issuers SHOULD NOT store the Issuer-signed JWT or the respect longer than strictly necessary, including in log files.</t>
ive <t>After Issuance, Issuers <bcp14>SHOULD NOT</bcp14> store the Issuer-signed JWT
or the respective
Disclosures.</t> Disclosures.</t>
<t>Holders SHOULD store SD-JWTs only in <t>Holders <bcp14>SHOULD</bcp14> store SD-JWTs only in
encrypted form, and, wherever possible, use hardware-backed encryption encrypted form, and, wherever possible, use hardware-backed encryption
in particular for the private Key Binding key. Decentralized storage in particular for the private Key Binding key. Decentralized storage
of data, e.g., on user devices, SHOULD be preferred for user of data, e.g., on user devices, <bcp14>SHOULD</bcp14> be preferred for user
credentials over centralized storage. Expired SD-JWTs SHOULD be deleted credentials over centralized storage. Expired SD-JWTs <bcp14>SHOULD</bcp14> be d
eleted
as soon as possible.</t> as soon as possible.</t>
<t>After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT or the <t>After Verification, Verifiers <bcp14>SHOULD NOT</bcp14> store the Issuer-sign ed JWT or the
respective Disclosures. It may be respective Disclosures. It may be
sufficient to store the result of the verification and any user data that is sufficient to store the result of the verification and any user data that is
needed for the application.</t> needed for the application.</t>
<t>Exceptions from the rules above can be made if there are strong requirements to do <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 c an so (e.g., functional requirements or legal audit requirements), secure storage c an
be ensured, and the privacy impact has been assessed.</t> be ensured, and the privacy impact has been assessed.</t>
</section> </section>
<section anchor="confidentiality-during-transport"><name>Confidentiality during Transport</name> <section anchor="confidentiality-during-transport"><name>Confidentiality During Transport</name>
<t>If an SD-JWT or SD-JWT+KB is transmitted over an insecure <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 channel during issuance or presentation, an adversary may be able to
intercept and read the user's personal data or correlate the information with pr evious uses.</t> intercept and read the user's personal data or correlate the information with pr evious uses.</t>
<t>Usually, transport protocols for issuance and presentation of credentials <t>Usually, transport protocols for issuance and presentation of credentials
are designed to protect the confidentiality of the transmitted data, for are designed to protect the confidentiality of the transmitted data, for
example, by requiring the use of TLS.</t> example, by requiring the use of TLS.</t>
<t>This specification therefore considers the confidentiality of the data to be <t>This specification therefore considers the confidentiality of the data to be
provided by the transport protocol and does not specify any encryption provided by the transport protocol and does not specify any encryption
mechanism.</t> mechanism.</t>
<t>Implementers MUST ensure that the transport protocol provides confidentiality <t>Implementers <bcp14>MUST</bcp14> ensure that the transport protocol provides confidentiality
if the privacy of user data or correlation attacks by passive observers are a co ncern.</t> if the privacy of user data or correlation attacks by passive observers are a co ncern.</t>
<t>To encrypt an SD-JWT or SD-JWT+KB during transit over potentially insecure or <t>To encrypt an SD-JWT or SD-JWT+KB during transit over potentially insecure or
leakage-prone channels, implementers MAY use JSON Web Encryption (JWE) <xref ta leakage-prone channels, implementers <bcp14>MAY</bcp14> use JSON Web Encryption
rget="RFC7516"/>, encapsulating the SD-JWT or SD-JWT+KB as the plaintext payload (JWE) <xref target="RFC7516"/>, encapsulating the SD-JWT or SD-JWT+KB as the pl
of the JWE. aintext payload of the JWE.
Especially, when an SD-JWT is transmitted via a URL and information may be store Especially, when an SD-JWT is transmitted via a URL and information may be store
d/cached in the browser or end up in web server logs, the SD-JWT SHOULD be encry d/cached in the browser or end up in web server logs, the SD-JWT <bcp14>SHOULD</
pted using JWE.</t> bcp14> be encrypted using JWE.</t>
</section> </section>
<section anchor="decoy_digests_privacy"><name>Decoy Digests</name> <section anchor="decoy_digests_privacy"><name>Decoy Digests</name>
<t>The use of decoy digests is RECOMMENDED when the number of claims (or the exi stence of particular claims) can be a side-channel disclosing information about otherwise undisclosed claims. In particular, if a claim in an SD-JWT is present only if a certain condition is met (e.g., a membership number is only contained if the user is a member of a group), the Issuer SHOULD add decoy digests when th e condition is not met.</t> <t>The use of decoy digests is <bcp14>RECOMMENDED</bcp14> when the number of cla ims (or the existence of particular claims) can be a side channel disclosing inf ormation 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 Issuer <bcp14>SHOULD</bc p14> 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 (o r 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> <t>Decoy digests increase the size of the SD-JWT. The number of decoy digests (o r 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>
<section anchor="issuer-identifier"><name>Issuer Identifier</name> <section anchor="issuer-identifier"><name>Issuer Identifier</name>
<t>An Issuer issuing only one type of SD-JWT might have privacy implications, be cause if the Holder has an SD-JWT issued by that Issuer, its type and claim name s can be determined.</t> <t>An Issuer issuing only one type of SD-JWT might have privacy implications, be cause if the Holder has an SD-JWT issued by that Issuer, its type and claim name s can be determined.</t>
<t>For example, if a cancer research institute only issued SD-JWTs with cancer r egistry information, it is possible to deduce that the Holder owning its SD-JWT is a cancer patient.</t> <t>For example, if a cancer research institute only issued SD-JWTs with cancer r egistry information, it is possible to deduce that the Holder owning its SD-JWT is a cancer patient.</t>
<t>Moreover, the issuer identifier alone may reveal information about the user.< <t>Moreover, the Issuer identifier alone may reveal information about the user.<
/t> /t>
<t>For example, when a military organization or a drug rehabilitation center iss <t>For example, when a military organization or a drug rehabilitation center iss
ues a vaccine credential, verifiers can deduce that the holder is a military mem ues a vaccine credential, Verifiers can deduce that the holder is a military mem
ber or may have a substance use disorder.</t> ber or may have a substance use disorder.</t>
<t>To mitigate this issue, a group of issuers may elect to use a common Issuer i dentifier. A group signature scheme outside the scope of this specification may also be used, instead of an individual signature.</t> <t>To mitigate this issue, a group of issuers may elect to use a common Issuer i dentifier. A group signature scheme outside the scope of this specification may also be used, instead of an individual signature.</t>
</section> </section>
</section> </section>
<section anchor="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 th
e initial set of implementations.</t>
<t>The work on this draft was started at OAuth Security Workshop 2022 in Trondhe
im, Norway.</t>
</section>
<section anchor="iana_considerations"><name>IANA Considerations</name> <section anchor="iana_considerations"><name>IANA Considerations</name>
<section anchor="json-web-token-claims-registration"><name>JSON Web Token Claims Registration</name> <section anchor="json-web-token-claims-registration"><name>JSON Web Token Claims Registration</name>
<t>This specification requests registration of the following Claims in the <t>IANA has registered the following Claims in the
IANA "JSON Web Token Claims" registry <xref target="IANA.JWT"/> established by < "JSON Web Token Claims" registry <xref target="JWT.Claims"/> established by <xre
xref target="RFC7519"/>.</t> f target="RFC7519"/>.</t>
<ul spacing="compact"> <dl spacing="compact" newline="false">
<li>Claim Name: <tt>_sd</tt></li> <dt>Claim Name:</dt><dd><tt>_sd</tt></dd>
<li>Claim Description: Digests of Disclosures for object properties</li> <dt>Claim Description:</dt><dd>Digests of Disclosures for object properties</dd>
<li>Change Controller: IETF</li> <dt>Change Controller:</dt><dd>IETF</dd>
<li>Specification Document(s): [[ <xref target="embedding_object_properties"/> <dt>Specification Document(s):</dt><dd> <xref target="embedding_object_propertie
of this specification ]]</li> s"/> of RFC 9901</dd>
</ul> </dl>
<t><br/>
</t>
<ul spacing="compact"> <dl spacing="compact" newline="false">
<li>Claim Name: <tt>...</tt></li> <dt>Claim Name:</dt><dd><tt>...</tt></dd>
<li>Claim Description: Digest of the Disclosure for an array element</li> <dt>Claim Description:</dt><dd>Digest of the Disclosure for an array element</dd
<li>Change Controller: IETF</li> >
<li>Specification Document(s): [[ <xref target="embedding_array_elements"/> of <dt>Change Controller:</dt><dd>IETF</dd>
this specification ]]</li> <dt>Specification Document(s):</dt><dd><xref target="embedding_array_elements"/>
</ul> of RFC 9901</dd>
<t><br/> </dl>
</t>
<ul spacing="compact"> <dl spacing="compact" newline="false">
<li>Claim Name: <tt>_sd_alg</tt></li> <dt>Claim Name:</dt><dd><tt>_sd_alg</tt></dd>
<li>Claim Description: Hash algorithm used to generate Disclosure digests and di <dt>Claim Description:</dt><dd>Hash algorithm used to generate Disclosure digest
gest over presentation</li> s and digest over presentation</dd>
<li>Change Controller: IETF</li> <dt>Change Controller:</dt><dd>IETF</dd>
<li>Specification Document(s): [[ <xref target="hash_function_claim"/> of this <dt>Specification Document(s):</dt><dd><xref target="hash_function_claim"/> of R
specification ]]</li> FC 9901</dd>
</ul> </dl>
<t><br/>
</t>
<ul spacing="compact"> <dl spacing="compact" newline="false">
<li>Claim Name: <tt>sd_hash</tt></li> <dt>Claim Name:</dt><dd><tt>sd_hash</tt></dd>
<li>Claim Description: Digest of the SD-JWT to which the KB-JWT is tied</li> <dt>Claim Description:</dt><dd>Digest of the SD-JWT to which the KB-JWT is tied<
<li>Change Controller: IETF</li> /dd>
<li>Specification Document(s): [[ <xref target="kb-jwt"/> of this specification <dt>Change Controller:</dt><dd>IETF</dd>
]]</li> <dt>Specification Document(s):</dt><dd><xref target="kb-jwt"/> of RFC 9901</dd>
</ul> </dl>
</section> </section>
<section anchor="media-type-registration"><name>Media Type Registration</name> <section anchor="media-type-registration"><name>Media Type Registrations</name>
<t>This section requests registration of the following media types <xref target= <!-- [rfced] We updated the format of the media type registrations to better ali
"RFC2046"/> in gn with the format used by IANA. We also created subsections for each of the re
the "Media Types" registry <xref target="IANA.MediaTypes"/> in the manner descri gistrations. Please review Section 11.2 carefully and let us know if a) any cha
bed nges are desired for the section titles or b) if you object to the updated forma
t.
-->
<t>IANA has registered the following media types <xref target="RFC2046"/> in
the "Media Types" registry <xref target="MediaTypes"/> in the manner described
in <xref target="RFC6838"/>.</t> in <xref target="RFC6838"/>.</t>
<blockquote><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 indicate that the content is an SD-JWT:</t>
<ul spacing="compact"> <aside><t>Note: For the media type value used in the <tt>typ</tt> header in the
<li>Type name: application</li> Issuer-signed JWT
<li>Subtype name: sd-jwt</li> itself, see <xref target="explicit_typing"/>.</t>
<li>Required parameters: n/a</li> </aside>
<li>Optional parameters: n/a</li>
<li>Encoding considerations: binary; application/sd-jwt values are a series of b
ase64url-encoded values (some of which may be the empty string) separated by per
iod ('.') and tilde ('~') characters.</li>
<li>Security considerations: See the Security Considerations section of [[ this
specification ]], <xref target="RFC7519"/>, and <xref target="RFC8725"/>.</li>
<li>Interoperability considerations: n/a</li>
<li>Published specification: [[ this specification ]]</li>
<li>Applications that use this media type: Applications requiring selective disc
losure of integrity protected content.</li>
<li>Fragment identifier considerations: n/a</li>
<li><t>Additional information:</t>
<ul spacing="compact"> <section anchor="sj-jwt-content"><name>SD-JWT Content</name>
<li>Magic number(s): n/a</li>
<li>File extension(s): n/a</li>
<li>Macintosh file type code(s): n/a</li>
</ul></li>
<li>Person &amp; email address to contact for further information: Daniel Fett,
mail@danielfett.de</li>
<li>Intended usage: COMMON</li>
<li>Restrictions on usage: none</li>
<li>Author: Daniel Fett, mail@danielfett.de</li>
<li>Change Controller: IETF</li>
<li>Provisional registration? No</li>
</ul>
<t><br/>
To indicate that the content is a JWS JSON serialized SD-JWT:</t> <t>To indicate that the content is an SD-JWT:</t>
<ul spacing="compact"> <dl spacing="normal">
<li>Type name: application</li> <dt>Type name:</dt><dd>application</dd>
<li>Subtype name: sd-jwt+json</li> <dt>Subtype name:</dt><dd>sd-jwt</dd>
<li>Required parameters: n/a</li> <dt>Required parameters:</dt><dd>n/a</dd>
<li>Optional parameters: n/a</li> <dt>Optional parameters:</dt><dd>n/a</dd>
<li>Encoding considerations: binary; application/sd-jwt+json values are represen <dt>Encoding considerations:</dt><dd>binary; application/sd-jwt values are a ser
ted as a JSON Object.</li> ies of base64url-encoded values (some of which may be the empty string) separate
<li>Security considerations: See the Security Considerations section of [[ this d by period ('.') and tilde ('~') characters.</dd>
specification ]], and <xref target="RFC7515"/>.</li> <dt>Security considerations:</dt><dd>See the Security Considerations sections of
<li>Interoperability considerations: n/a</li> RFC 9901, <xref target="RFC7519"/>, and <xref target="RFC8725"/>.</dd>
<li>Published specification: [[ this specification ]]</li> <dt>Interoperability considerations:</dt><dd>n/a</dd>
<li>Applications that use this media type: Applications requiring selective disc <dt>Published specification:</dt><dd>RFC 9901</dd>
losure of content protected by ETSI JAdES compliant signatures.</li> <dt>Applications that use this media type:</dt><dd>Applications requiring select
<li>Fragment identifier considerations: n/a</li> ive disclosure of integrity-protected content.</dd>
<li><t>Additional information:</t> <dt>Fragment identifier considerations:</dt><dd>n/a</dd>
<dt>Additional information:</dt><dd>
<t><br/></t>
<dl spacing="compact">
<dt>Magic number(s):</dt><dd>n/a</dd>
<dt>File extension(s):</dt><dd>n/a</dd>
<dt>Macintosh file type code(s):</dt><dd>n/a</dd>
</dl>
</dd>
<dt>Person &amp; email address to contact for further information:</dt><dd>Danie
l Fett, mail@danielfett.de</dd>
<dt>Intended usage:</dt><dd>COMMON</dd>
<dt>Restrictions on usage:</dt><dd>none</dd>
<dt>Author:</dt><dd>Daniel Fett, mail@danielfett.de</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
</dl>
</section>
<ul spacing="compact"> <section anchor="jws-json-content"><name>JWS JSON Serialized SD-JWT Content</nam
<li>Magic number(s): n/a</li> e>
<li>File extension(s): n/a</li> <t>To indicate that the content is a JWS JSON serialized SD-JWT:</t>
<li>Macintosh file type code(s): n/a</li>
</ul></li>
<li>Person &amp; email address to contact for further information: Daniel Fett,
mail@danielfett.de</li>
<li>Intended usage: COMMON</li>
<li>Restrictions on usage: none</li>
<li>Author: Daniel Fett, mail@danielfett.de</li>
<li>Change Controller: IETF</li>
<li>Provisional registration? No</li>
</ul>
<t><br/>
To indicate that the content is a Key Binding JWT:</t> <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 JSON Object.</dd>
<dt>Security considerations:</dt><dd>See the Security Considerations sections of
RFC 9901 and <xref target="RFC7515"/>.</dd>
<dt>Interoperability considerations:</dt><dd>n/a</dd>
<dt>Published specification:</dt><dd>RFC 9901</dd>
<dt>Applications that use this media type:</dt><dd>Applications requiring select
ive disclosure of content protected by ETSI JAdES compliant signatures.</dd>
<dt>Fragment identifier considerations:</dt><dd>n/a</dd>
<dt>Additional information:</dt><dd>
<t><br/></t>
<dl spacing="compact">
<dt>Magic number(s):</dt><dd>n/a</dd>
<dt>File extension(s):</dt><dd>n/a</dd>
<dt>Macintosh file type code(s):</dt><dd>n/a</dd>
</dl></dd>
<dt>Person &amp; email address to contact for further information:</dt><dd>Danie
l Fett, mail@danielfett.de</dd>
<dt>Intended usage:</dt><dd>COMMON</dd>
<dt>Restrictions on usage:</dt><dd>none</dd>
<dt>Author:</dt><dd>Daniel Fett, mail@danielfett.de</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
</dl>
</section>
<ul spacing="compact"> <section anchor="kb-jwt-content"><name>Key Binding JWT Content</name>
<li>Type name: application</li> <t>To indicate that the content is a Key Binding JWT:</t>
<li>Subtype name: kb+jwt</li>
<li>Required parameters: n/a</li>
<li>Optional parameters: n/a</li>
<li>Encoding considerations: binary; A Key Binding JWT is a JWT; JWT values are
encoded as a series of base64url-encoded values separated by period ('.') charac
ters.</li>
<li>Security considerations: See the Security Considerations section of [[ this
specification ]], <xref target="RFC7519"/>, and <xref target="RFC8725"/>.</li>
<li>Interoperability considerations: n/a</li>
<li>Published specification: [[ this specification ]]</li>
<li>Applications that use this media type: Applications utilizing a JWT based pr
oof of possession mechanism.</li>
<li>Fragment identifier considerations: n/a</li>
<li><t>Additional information:</t>
<ul spacing="compact"> <dl spacing="normal">
<li>Magic number(s): n/a</li> <dt>Type name:</dt><dd>application</dd>
<li>File extension(s): n/a</li> <dt>Subtype name:</dt><dd>kb+jwt</dd>
<li>Macintosh file type code(s): n/a</li> <dt>Required parameters:</dt><dd>n/a</dd>
</ul></li> <dt>Optional parameters:</dt><dd>n/a</dd>
<li>Person &amp; email address to contact for further information: Daniel Fett, <dt>Encoding considerations:</dt><dd>binary; A Key Binding JWT is a JWT; JWT val
mail@danielfett.de</li> ues are encoded as a series of base64url-encoded values separated by period ('.'
<li>Intended usage: COMMON</li> ) characters.</dd>
<li>Restrictions on usage: none</li> <dt>Security considerations:</dt><dd>See the Security Considerations sections of
<li>Author: Daniel Fett, mail@danielfett.de</li> RFC 9901, <xref target="RFC7519"/>, and <xref target="RFC8725"/>.</dd>
<li>Change Controller: IETF</li> <dt>Interoperability considerations:</dt><dd>n/a</dd>
<li>Provisional registration? No</li> <dt>Published specification:</dt><dd>RFC 9901</dd>
</ul> <dt>Applications that use this media type:</dt><dd>Applications utilizing a JWT-
based proof-of-possession mechanism.</dd>
<dt>Fragment identifier considerations:</dt><dd>n/a</dd>
<dt>Additional information:</dt><dd>
<t><br/></t>
<dl spacing="compact">
<dt>Magic number(s):</dt><dd>n/a</dd>
<dt>File extension(s):</dt><dd>n/a</dd>
<dt>Macintosh file type code(s):</dt><dd>n/a</dd>
</dl></dd>
<dt>Person &amp; email address to contact for further information:</dt><dd>Danie
l Fett, mail@danielfett.de</dd>
<dt>Intended usage:</dt><dd>COMMON</dd>
<dt>Restrictions on usage:</dt><dd>none</dd>
<dt>Author:</dt><dd>Daniel Fett, mail@danielfett.de</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
</dl>
</section>
</section> </section>
<section anchor="structured-syntax-suffix-registration"><name>Structured Syntax <section anchor="structured-syntax-suffix-registration"><name>Structured Syntax
Suffix Registration</name> Suffixes Registration</name>
<t>This section requests registration of the "+sd-jwt" structured syntax suffix <t>IANA has registered "+sd-jwt" in
in the "Structured Syntax Suffixes" registry <xref target="StructuredSuffix"/> in
the "Structured Syntax Suffix" registry <xref target="IANA.StructuredSuffix"/> i
n
the manner described in <xref target="RFC6838"/>, which can be used to indicate that the manner described in <xref target="RFC6838"/>, which can be used to indicate that
the media type is encoded as an SD-JWT.</t> the media type is encoded as an SD-JWT.</t>
<ul spacing="compact"> <dl spacing="compact">
<li>Name: SD-JWT</li> <dt>Name:</dt><dd>SD-JWT</dd>
<li>+suffix: +sd-jwt</li> <dt>+suffix:</dt><dd>+sd-jwt</dd>
<li>References: [[ this specification ]]</li> <dt>References:</dt><dd>RFC 9901</dd>
<li>Encoding considerations: binary; SD-JWT values are a series of base64url-enc <dt>Encoding considerations:</dt><dd>binary; SD-JWT values are a series of base6
oded values (some of which may be the empty string) separated by period ('.') or 4url-encoded values (some of which may be the empty string) separated by period
tilde ('~') characters.</li> ('.') or tilde ('~') characters.</dd>
<li>Interoperability considerations: n/a</li> <dt>Interoperability considerations:</dt><dd>n/a</dd>
<li>Fragment identifier considerations: n/a</li> <dt>Fragment identifier considerations:</dt><dd>n/a</dd>
<li>Security considerations: See the Security Considerations section of [[ this <dt>Security considerations:</dt><dd>See the Security Considerations sections of
specification ]], <xref target="RFC7519"/>, and <xref target="RFC8725"/>.</li> RFC 9901, <xref target="RFC7519"/>, and <xref target="RFC8725"/>.</dd>
<li>Contact: Daniel Fett, mail@danielfett.de</li> <dt>Contact:</dt><dd>Daniel Fett, mail@danielfett.de</dd>
<li>Author/Change controller: IETF</li> <dt>Author/Change controller:</dt><dd>IETF</dd>
</ul> </dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <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>References</name>
<references><name>Normative 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.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-forma
l-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.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.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.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.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.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.8174.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml" />
</references> </references>
<references><name>Informative References</name> <references><name>Informative References</name>
<reference anchor="CL01" target="https://eprint.iacr.org/2001/019.pdf"> <reference anchor="CL01" target="https://eprint.iacr.org/2001/019.pdf">
<front> <front>
<title>An Efficient System for Non-Transferable Anonymous Credentials with O ptional Anonymity Revocation</title> <title>An Efficient System for Non-Transferable Anonymous Credentials with O ptional Anonymity Revocation</title>
<author fullname="Jan Camenisch" initials="J." surname="Camenisch"> <author fullname="Jan Camenisch" initials="J." surname="Camenisch">
<organization>IBM Research</organization> <organization>IBM Research</organization>
</author> </author>
<author fullname="Anna Lysyanskaya" initials="A." surname="Lysyanskaya"> <author fullname="Anna Lysyanskaya" initials="A." surname="Lysyanskaya">
<organization>MIT</organization> <organization>MIT</organization>
</author> </author>
<date year="2001"/> <date year="2001"/>
</front> </front>
<seriesInfo name="Proceedings of the International Conference on the Theory an d Application of Cryptographic Techniques (EUROCRYPT)" value="2001"/> <refcontent>Cryptology ePrint Archive, Paper 2001/019</refcontent>
</reference> </reference>
<reference anchor="EUDIW.ARF" target="https://eu-digital-identity-wallet.github. io/eudi-doc-architecture-and-reference-framework"> <reference anchor="EUDIW.ARF" target="https://eu-digital-identity-wallet.github. io/eudi-doc-architecture-and-reference-framework">
<front> <front>
<title>The European Digital Identity Wallet Architecture and Reference Frame work</title> <title>The European Digital Identity Wallet Architecture and Reference Frame work</title>
<author fullname="European Commission"/> <author>
<organization>European Commission</organization>
</author>
</front> </front>
</reference> </reference>
<!-- draft-ietf-oauth-sd-jwt-vc (I-D Exists) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-oau th-sd-jwt-vc.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-oau th-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-oau th-status-list.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-oau th-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-spi ce-sd-cwt.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spi ce-sd-cwt.xml"/>
<reference anchor="IANA.Hash.Algorithms" target="https://www.iana.org/assignment
s/named-information/named-information.xhtml"> <reference anchor="Hash.Algs" target="https://www.iana.org/assignments/named-inf
ormation">
<front> <front>
<title>Named Information Hash Algorithm</title> <title>Named Information Hash Algorithm Registry</title>
<author fullname="IANA"/> <author>
<organization>IANA</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="IANA.JWS.Algorithms" target="https://www.iana.org/assignments /jose/jose.xhtml#web-signature-encryption-algorithms"> <reference anchor="JWS.Algs" target="https://www.iana.org/assignments/jose">
<front> <front>
<title>JSON Web Signature and Encryption Algorithms</title> <title>JSON Web Signature and Encryption Algorithms</title>
<author fullname="IANA"/> <author>
<organization>IANA</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="IANA.JWT" target="https://www.iana.org/assignments/jwt"> <reference anchor="JWT.Claims" target="https://www.iana.org/assignments/jwt">
<front> <front>
<title>JSON Web Token Claims</title> <title>JSON Web Token Claims</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="IANA.MediaTypes" target="https://www.iana.org/assignments/med ia-types/media-types.xhtml"> <reference anchor="MediaTypes" target="https://www.iana.org/assignments/media-ty pes">
<front> <front>
<title>Media Types</title> <title>Media Types</title>
<author fullname="IANA"/> <author>
<organization>IANA</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="IANA.StructuredSuffix" target="https://www.iana.org/assignmen ts/media-type-structured-suffix/media-type-structured-suffix.xhtml"> <reference anchor="StructuredSuffix" target="https://www.iana.org/assignments/me dia-type-structured-suffix">
<front> <front>
<title>Structured Syntax Suffixs</title> <title>Structured Syntax Suffixes</title>
<author fullname="IANA"/> <author>
<organization>IANA</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="ISO.18013-5" target="https://www.iso.org/standard/69084.html" > <reference anchor="ISO.18013-5" target="https://www.iso.org/standard/69084.html" >
<front> <front>
<title>ISO/IEC 18013-5:2021 Personal identification — ISO-compliant driving license — Part 5: Mobile driving license (mDL) application</title> <title>Personal identification - ISO-compliant driving license — Part 5: Mob ile driving license (mDL) application</title>
<author> <author>
<organization> ISO/IEC JTC 1/SC 17 Cards and security devices for personal identification</organization> <organization>ISO/IEC</organization>
</author> </author>
<date year="2021"/> <date month="September" year="2021"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="18013-5:2021"/>
</reference> </reference>
<reference anchor="NIST.SP.800-57pt1r5" target="https://nvlpubs.nist.gov/nistpub s/SpecialPublications/NIST.SP.800-57pt1r5.pdf"> <reference anchor="NIST.SP.800-57pt1r5" target="https://nvlpubs.nist.gov/nistpub s/SpecialPublications/NIST.SP.800-57pt1r5.pdf">
<front> <front>
<title>Recommendation for key management:part 1 - general</title> <title>Recommendation for Key Management: Part 1 - General</title>
<author fullname="Elaine Barker" surname="Barker"> <author fullname="Elaine Barker" surname="Barker">
<organization>Information Technology Laboratory</organization> <organization>Information Technology Laboratory</organization>
</author> </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"/> <date year="2020" month="May"/>
</front> </front>
<seriesInfo name="NIST Special Publications (General)" value="800-57pt1r5"/> <seriesInfo name="NIST SP" value="800-57pt1r5"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
</reference> </reference>
<reference anchor="OIDC.IDA" target="https://openid.net/specs/openid-connect-4-i dentity-assurance-1_0.html"> <reference anchor="OIDC.IDA" target="https://openid.net/specs/openid-connect-4-i dentity-assurance-1_0.html">
<front> <front>
<title>OpenID Connect for Identity Assurance 1.0</title> <title>OpenID Connect for Identity Assurance 1.0</title>
<author fullname="Torsten Lodderstedt" initials="T." surname="Lodderstedt"> <author fullname="Torsten Lodderstedt" initials="T." surname="Lodderstedt">
<organization>yes.com</organization> <organization>yes.com</organization>
</author> </author>
<author fullname="Daniel Fett" initials="D." surname="Fett"> <author fullname="Daniel Fett" initials="D." surname="Fett">
<organization>yes.com</organization> <organization>yes.com</organization>
skipping to change at line 2187 skipping to change at line 2437
</author> </author>
<author fullname="Alberto Pulido" initials="A." surname="Pulido"> <author fullname="Alberto Pulido" initials="A." surname="Pulido">
<organization>Santander</organization> <organization>Santander</organization>
</author> </author>
<author fullname="Kai Lehmann" initials="K." surname="Lehmann"> <author fullname="Kai Lehmann" initials="K." surname="Lehmann">
<organization>1&amp;1 Mail &amp; Media Development &amp; Technology GmbH</ organization> <organization>1&amp;1 Mail &amp; Media Development &amp; Technology GmbH</ organization>
</author> </author>
<author fullname="Kosuke Koiwai" initials="K." surname="Koiwai"> <author fullname="Kosuke Koiwai" initials="K." surname="Koiwai">
<organization>KDDI Corporation</organization> <organization>KDDI Corporation</organization>
</author> </author>
<date year="2024" month="Jul" day="24"/> <date year="2024" month="Oct" day="1"/>
</front> </front>
</reference> </reference>
<reference anchor="OpenID.Core" target="https://openid.net/specs/openid-connect- core-1_0.html"> <reference anchor="OpenID.Core" target="https://openid.net/specs/openid-connect- core-1_0.html">
<front> <front>
<title>OpenID Connect Core 1.0 incorporating errata set 2</title> <title>OpenID Connect Core 1.0 incorporating errata set 2</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura"> <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organiz ation> <organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organiz ation>
</author> </author>
<author fullname="John Bradley" initials="J." surname="Bradley"> <author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Yubico (was at Ping Identity)">Yubico</organization> <organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
skipping to change at line 2213 skipping to change at line 2463
<organization>Google</organization> <organization>Google</organization>
</author> </author>
<author fullname="Chuck Mortimore" initials="C." surname="Mortimore"> <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
<organization abbrev="Disney (was at Salesforce)">Disney</organization> <organization abbrev="Disney (was at Salesforce)">Disney</organization>
</author> </author>
<date year="2023" month="Dec" day="15"/> <date year="2023" month="Dec" day="15"/>
</front> </front>
</reference> </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.2046.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7517.xml" /> <xi:include href="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" /> <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 /"> <reference anchor="VC_DATA_v2.0" target="https://www.w3.org/TR/vc-data-model-2.0 /">
<front> <front>
<title>Verifiable Credentials Data Model 2.0</title> <title>Verifiable Credentials Data Model 2.0</title>
<author fullname="Manu Sporny"> <author fullname="Manu Sporny" role="editor">
<organization>Digital Bazaar</organization> <organization>Digital Bazaar</organization>
</author> </author>
<author fullname="Ted Thiboeau Jr"> <author fullname="Ted Thiboeau" role="editor">
<organization>OpenLink Software</organization> <organization>OpenLink Software</organization>
</author> </author>
<author fullname="Michael B. Jones"> <author fullname="Michael B. Jones" role="editor">
<organization>Invited Expert</organization> <organization>Invited Expert</organization>
</author> </author>
<author fullname="Gabe Cohen"> <author fullname="Gabe Cohen" role="editor">
<organization>Block</organization> <organization>Block</organization>
</author> </author>
<author fullname="Ivan Herman"> <author fullname="Ivan Herman" role="editor">
<organization>W3C</organization> <organization>W3C</organization>
</author> </author>
<date year="2025" month="May"/> <date year="2025" month="May"/>
</front> </front>
<refcontent>W3C Recommendation</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="additional-examples"><name>Additional Examples</name> <section anchor="additional-examples"><name>Additional Examples</name>
<t>The following examples are not normative and are provided for <t>The following examples are not normative and are provided for
illustrative purposes only. In particular, neither the structure of the claims illustrative purposes only. In particular, neither the structure of the claims
nor the selection of selectively disclosable claims is normative.</t> nor the selection of selectively disclosable claims is normative.</t>
<t>Line breaks have been added for readability.</t> <t>Line breaks have been added for readability.</t>
<section anchor="example-simple_structured"><name>Simple Structured SD-JWT</name > <section anchor="example-simple_structured"><name>Simple Structured SD-JWT</name >
<t>In this example, in contrast to <xref target="main-example"/>, the Issuer dec <!-- [rfced] We updated this text for clarity. Please review and let us know if
ided to create a structured object for the <tt>address</tt> claim, allowing to s any updates are needed.
eparately disclose individual members of the claim.</t>
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 dec
ided to create a structured object for the <tt>address</tt> claim, allowing indi
vidual members of the claim to be disclosed separately.
</t>
<t>The following data about the user comprises the input JWT Claims Set used by the Issuer:</t> <t>The following data about the user comprises the input JWT Claims Set used by the Issuer:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"given_name": "太郎", "given_name": "太郎",
"family_name": "山田", "family_name": "山田",
"email": "\"unusual email address\"@example.jp", "email": "\"unusual email address\"@example.jp",
"phone_number": "+81-80-1234-5678", "phone_number": "+81-80-1234-5678",
"address": { "address": {
"street_address": "東京都港区芝公園４丁目２−８", "street_address": "東京都港区芝公園４丁目２−８",
"locality": "東京都", "locality": "東京都",
"region": "港区", "region": "港区",
"country": "JP" "country": "JP"
skipping to change at line 2266 skipping to change at line 2532
"address": { "address": {
"street_address": "東京都港区芝公園４丁目２−８", "street_address": "東京都港区芝公園４丁目２−８",
"locality": "東京都", "locality": "東京都",
"region": "港区", "region": "港区",
"country": "JP" "country": "JP"
}, },
"birthdate": "1940-01-01" "birthdate": "1940-01-01"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>The Issuer also decided to add decoy digests to prevent the Verifier from ded ucing the true number of claims.</t> <t>The Issuer also decided to add decoy digests to prevent the Verifier from ded ucing the true number of claims.</t>
<t>The following payload is used for the SD-JWT:</t> <t>The following payload is used for the SD-JWT:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"_sd": [ "_sd": [
"C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU", "C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU",
"Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE", "Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE",
"MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY", "MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY",
"X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g", "X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g",
"Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE", "Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE",
"fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs", "fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs",
"ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q", "ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q",
"s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U" "s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U"
], ],
skipping to change at line 2302 skipping to change at line 2570
"uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4" "uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4"
] ]
}, },
"_sd_alg": "sha-256" "_sd_alg": "sha-256"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>The digests in the SD-JWT payload reference the following Disclosures:</t> <t>The digests in the SD-JWT payload reference the following Disclosures:</t>
<t><strong>Claim <tt>sub</tt></strong>:</t> <t><strong>Claim <tt>sub</tt></strong>:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>SHA-256 Hash: <tt>X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g</tt></li> <li><t>SHA-256 Hash:</t><t><tt>X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g</tt><
<li>Disclosure:<br/> /t></li>
<tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1i</tt><br/> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzV
<tt>NTg5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ</tt></li> jMGE0OS1iNTg5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ</tt></t></li>
<li>Contents: <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "sub", "6c5c0a49-b589-431d
<tt>["2GLC42sKQveCfGfryNRN9w", "sub",</tt><br/> -bae7-219122a9ec2c"]</tt></t></li>
<tt>"6c5c0a49-b589-431d-bae7-219122a9ec2c"]</tt></li>
</ul> </ul>
<t><strong>Claim <tt>given_name</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>given_name</tt></strong>:</t>
<li>SHA-256 Hash: <tt>ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q</tt><
<tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1</tt><br/> /t></li>
<tt>OTJhXHU5MGNlIl0</tt></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWU
<li>Contents: iLCAiXHU1OTJhXHU5MGNlIl0</tt></t></li>
<tt>["eluV5Og3gSNII8EYnsxA_A", "given_name", "\u592a\u90ce"]</tt></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "given_name", "\u592a\u90c
e"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>family_name</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>family_name</tt></strong>:</t>
<li>SHA-256 Hash: <tt>C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU</tt><
<tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1</tt><br/> /t></li>
<tt>NWM3MVx1NzUzMCJd</tt></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1
<li>Contents: lIiwgIlx1NWM3MVx1NzUzMCJd</tt></t></li>
<tt>["6Ij7tM-a5iVPGboS5tmvVA", "family_name", "\u5c71\u7530"]</tt></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "family_name", "\u5c71\u75
30"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>email</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>email</tt></strong>:</t>
<li>SHA-256 Hash: <tt>Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE</tt><
<tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3Vh</tt><br/> /t></li>
<tt>bCBlbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd</tt></li> <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlw
<li>Contents: idW51c3VhbCBlbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd</tt></t></li>
<tt>["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual email</tt><br/> <li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual email
<tt>address\"@example.jp"]</tt></li> address\"@example.jp"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>phone_number</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>phone_number</tt></strong>:</t>
<li>SHA-256 Hash: <tt>s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U</tt><
<tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIr</tt><br/> /t></li>
<tt>ODEtODAtMTIzNC01Njc4Il0</tt></li> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJ
<li>Contents: lciIsICIrODEtODAtMTIzNC01Njc4Il0</tt></t></li>
<tt>["Qg_O64zqAxe412a108iroA", "phone_number",</tt><br/> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "phone_number", "+81-80-12
<tt>"+81-80-1234-5678"]</tt></li> 34-5678"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>street_address</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>street_address</tt></strong>:</t>
<li>SHA-256 Hash: <tt>6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E</tt><
<tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwg</tt><br/> /t></li>
<tt>Ilx1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1</tt><br/> <li><t>Disclosure:</t><t><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGR
<tt>NTcxMlx1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd</tt></li> yZXNzIiwgIlx1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1NTcxMlx1ZmY
<li>Contents: xNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd</tt></t></li>
<tt>["AJx-095VPrpTtN4QMOqROA", "street_address", "\u6771\u4eac\u</tt><br/> <li><t>Contents:</t><t><tt>["AJx-095VPrpTtN4QMOqROA", "street_address", "\u6771\
<tt>90fd\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u</tt><br/> u4eac\u90fd\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u2212\uff18"]<
<tt>2212\uff18"]</tt></li> /tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>locality</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>locality</tt></strong>:</t>
<li>SHA-256 Hash: <tt>rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA</tt><
<tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3</tt><br/> /t></li>
<tt>MVx1NGVhY1x1OTBmZCJd</tt></li> <li><t>Disclosure:</t><t><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5Iiw
<li>Contents: gIlx1Njc3MVx1NGVhY1x1OTBmZCJd</tt></t></li>
<tt>["Pc33JM2LchcU_lHggv_ufQ", "locality", "\u6771\u4eac\u90fd"]</tt></li> <li><t>Contents:</t><t><tt>["Pc33JM2LchcU_lHggv_ufQ", "locality", "\u6771\u4eac\
u90fd"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>region</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>region</tt></strong>:</t>
<li>SHA-256 Hash: <tt>PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k</tt><
<tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZc</tt><br/> /t></li>
<tt>dTUzM2EiXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJ
<li>Contents: cdTZlMmZcdTUzM2EiXQ</tt></t></li>
<tt>["G02NSrQfjFXQ7Io09syajA", "region", "\u6e2f\u533a"]</tt></li> <li><t>Contents:</t><t><tt>["G02NSrQfjFXQ7Io09syajA", "region", "\u6e2f\u533a"]<
/tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>country</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>country</tt></strong>:</t>
<li>SHA-256 Hash: <tt>uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4</tt><
<tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCA
<tt>["lklxF5jMYlGTPUovMNIvCA", "country", "JP"]</tt></li> iSlAiXQ</tt></t></li>
<li><t>Contents:</t><t><tt>["lklxF5jMYlGTPUovMNIvCA", "country", "JP"]</tt></t><
/li>
</ul> </ul>
<t><strong>Claim <tt>birthdate</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>birthdate</tt></strong>:</t>
<li>SHA-256 Hash: <tt>MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY</tt><
<tt>WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQw</tt><br/> /t></li>
<tt>LTAxLTAxIl0</tt></li> <li><t>Disclosure:</t><t><tt>WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSI
<li>Contents: sICIxOTQwLTAxLTAxIl0</tt></t></li>
<tt>["yytVbdAPGcgl2rI4C9GSog", "birthdate", "1940-01-01"]</tt></li> <li><t>Contents:</t><t><tt>["yytVbdAPGcgl2rI4C9GSog", "birthdate", "1940-01-01"]
</tt></t></li>
</ul> </ul>
<t>The following decoy digests are added:</t>
<ul spacing="compact"> <t>The following decoy digests are added:</t>
<ul spacing="normal">
<li><tt>AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg</tt></li> <li><tt>AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg</tt></li>
<li><tt>cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ</tt></li> <li><tt>cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ</tt></li>
<li><tt>glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4</tt></li> <li><tt>glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4</tt></li>
<li><tt>b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek</tt></li> <li><tt>b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek</tt></li>
<li><tt>fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs</tt></li> <li><tt>fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs</tt></li>
<li><tt>Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE</tt></li> <li><tt>Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE</tt></li>
</ul> </ul>
<t>The following is a presentation of the SD-JWT that discloses only <tt>region< /tt> <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> and <tt>country</tt> of the <tt>address</tt> property:</t>
<sourcecode type="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qt <sourcecode type="txt"><![CDATA[
and0In0.eyJfc2QiOiBb eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
IkM5aW5wNllvUmFFWFI0Mjd6WUpQN1FyazFXSF84YmR3T0FfWVVyVW5HUVUiLCAiS3Vl IkM5aW5wNllvUmFFWFI0Mjd6WUpQN1FyazFXSF84YmR3T0FfWVVyVW5HUVUiLCAiS3Vl
dDF5QWEwSElRdlluT1ZkNTloY1ZpTzlVZzZKMmtTZnFZUkJlb3d2RSIsICJNTWxkT0ZG dDF5QWEwSElRdlluT1ZkNTloY1ZpTzlVZzZKMmtTZnFZUkJlb3d2RSIsICJNTWxkT0ZG
ekIyZDB1bWxtcFRJYUdlcmhXZFVfUHBZZkx2S2hoX2ZfOWFZIiwgIlg2WkFZT0lJMnZQ ekIyZDB1bWxtcFRJYUdlcmhXZFVfUHBZZkx2S2hoX2ZfOWFZIiwgIlg2WkFZT0lJMnZQ
TjQwVjd4RXhad1Z3ejd5Um1MTmNWd3Q1REw4Ukx2NGciLCAiWTM0em1JbzBRTExPdGRN TjQwVjd4RXhad1Z3ejd5Um1MTmNWd3Q1REw4Ukx2NGciLCAiWTM0em1JbzBRTExPdGRN
cFhHd2pCZ0x2cjE3eUVoaFlUMEZHb2ZSLWFJRSIsICJmeUdwMFdUd3dQdjJKRFFsbjFs cFhHd2pCZ0x2cjE3eUVoaFlUMEZHb2ZSLWFJRSIsICJmeUdwMFdUd3dQdjJKRFFsbjFs
U2lhZW9iWnNNV0ExMGJRNTk4OS05RFRzIiwgIm9tbUZBaWNWVDhMR0hDQjB1eXd4N2ZZ U2lhZW9iWnNNV0ExMGJRNTk4OS05RFRzIiwgIm9tbUZBaWNWVDhMR0hDQjB1eXd4N2ZZ
dW8zTUhZS08xNWN6LVJaRVlNNVEiLCAiczBCS1lzTFd4UVFlVTh0VmxsdE03TUtzSVJU dW8zTUhZS08xNWN6LVJaRVlNNVEiLCAiczBCS1lzTFd4UVFlVTh0VmxsdE03TUtzSVJU
ckVJYTFQa0ptcXhCQmY1VSJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu ckVJYTFQa0ptcXhCQmY1VSJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAiYWRkcmVz Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAiYWRkcmVz
cyI6IHsiX3NkIjogWyI2YVVoelloWjdTSjFrVm1hZ1FBTzN1MkVUTjJDQzFhSGhlWnBL cyI6IHsiX3NkIjogWyI2YVVoelloWjdTSjFrVm1hZ1FBTzN1MkVUTjJDQzFhSGhlWnBL
skipping to change at line 2444 skipping to change at line 2679
ZWptc0JNb0d3dU5YaDlxQUFGQVRBY2k0MG9pZEVlVnNBIiwgInVOSG9XWWhYc1poVkpD ZWptc0JNb0d3dU5YaDlxQUFGQVRBY2k0MG9pZEVlVnNBIiwgInVOSG9XWWhYc1poVkpD
TkUyRHF5LXpxdDd0NjlnSkt5NVFhRnY3R3JNWDQiXX0sICJfc2RfYWxnIjogInNoYS0y TkUyRHF5LXpxdDd0NjlnSkt5NVFhRnY3R3JNWDQiXX0sICJfc2RfYWxnIjogInNoYS0y
NTYifQ.EOZa2YqK8j4i7cqBDkfPcTMaFsgPwcx3aYJkFoMfvV46LxL-PPqrWsIyNukB4 NTYifQ.EOZa2YqK8j4i7cqBDkfPcTMaFsgPwcx3aYJkFoMfvV46LxL-PPqrWsIyNukB4
x8Y2LT31eIHDc4Wg4XNzaqu4w~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2 x8Y2LT31eIHDc4Wg4XNzaqu4w~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2
lvbiIsICJcdTZlMmZcdTUzM2EiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImN lvbiIsICJcdTZlMmZcdTUzM2EiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImN
vdW50cnkiLCAiSlAiXQ~ vdW50cnkiLCAiSlAiXQ~
]]> ]]>
</sourcecode> </sourcecode>
<t>After validation, the Verifier will have the following Processed SD-JWT Paylo ad available for further handling:</t> <t>After validation, the Verifier will have the following Processed SD-JWT Paylo ad available for further handling:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"iss": "https://issuer.example.com", "iss": "https://issuer.example.com",
"iat": 1683000000, "iat": 1683000000,
"exp": 1883000000, "exp": 1883000000,
"address": { "address": {
"region": "港区", "region": "港区",
"country": "JP" "country": "JP"
} }
} }
]]> ]]>
</sourcecode> </sourcecode>
</section> </section>
<section anchor="example-complex-structured-sd-jwt"><name>Complex Structured SD- JWT</name> <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 <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.I DA"/> are used.</t> structures defined in OpenID Connect for Identity Assurance <xref target="OIDC.I DA"/> are used.</t>
<t>The Issuer is using the following user data as the input JWT Claims Set:</t> <t>The Issuer is using the following user data as the input JWT Claims Set:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"verified_claims": { "verified_claims": {
"verification": { "verification": {
"trust_framework": "de_aml", "trust_framework": "de_aml",
"time": "2012-04-23T18:25Z", "time": "2012-04-23T18:25Z",
"verification_process": "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7", "verification_process": "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7",
"evidence": [ "evidence": [
{ {
"type": "document", "type": "document",
"method": "pipp", "method": "pipp",
"time": "2012-04-22T11:30Z", "time": "2012-04-22T11:30Z",
skipping to change at line 2513 skipping to change at line 2750
} }
}, },
"birth_middle_name": "Timotheus", "birth_middle_name": "Timotheus",
"salutation": "Dr.", "salutation": "Dr.",
"msisdn": "49123456789" "msisdn": "49123456789"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>The following payload is used for the SD-JWT:</t> <t>The following payload is used for the SD-JWT:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"_sd": [ "_sd": [
"-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw", "-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw",
"IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg", "IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg",
"otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI" "otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI"
], ],
"iss": "https://issuer.example.com", "iss": "https://issuer.example.com",
"iat": 1683000000, "iat": 1683000000,
"exp": 1883000000, "exp": 1883000000,
"verified_claims": { "verified_claims": {
"verification": { "verification": {
skipping to change at line 2551 skipping to change at line 2789
"_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ", "_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ",
"hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE" "hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE"
] ]
} }
}, },
"_sd_alg": "sha-256" "_sd_alg": "sha-256"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>The digests in the SD-JWT payload reference the following Disclosures:</t> <t>The digests in the SD-JWT payload reference the following Disclosures:</t>
<t><strong>Claim <tt>time</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>time</tt></strong>:</t>
<li>SHA-256 Hash: <tt>vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw</tt><
<tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0y</tt><br/> /t></li>
<tt>M1QxODoyNVoiXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjA
<li>Contents: xMi0wNC0yM1QxODoyNVoiXQ</tt></t></li>
<tt>["2GLC42sKQveCfGfryNRN9w", "time", "2012-04-23T18:25Z"]</tt></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "time", "2012-04-23T18:25Z
"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>verification_process</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>verification_process</tt></strong>:</t>
<li>SHA-256 Hash: <tt>7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc</tt><
<tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9j</tt><br/> /t></li>
<tt>ZXNzIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGl
<li>Contents: vbl9wcm9jZXNzIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ</tt></t></li
<tt>["eluV5Og3gSNII8EYnsxA_A", "verification_process",</tt><br/> >
<tt>"f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"]</tt></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "verification_process", "f
24c6f-6d3f-4ec5-973e-b0d8506f3bc7"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>type</tt></strong>:</t> <t><strong>Claim <tt>type</tt></strong>:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>SHA-256 Hash: <tt>G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk</tt></li> <li><t>SHA-256 Hash:</t><t><tt>G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk</tt><
<li>Disclosure:<br/> /t></li>
<tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQi</tt><br/> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9
<tt>XQ</tt></li> jdW1lbnQiXQ</tt></t></li>
<li>Contents: <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "type", "document"]</tt></
<tt>["6Ij7tM-a5iVPGboS5tmvVA", "type", "document"]</tt></li> t></li>
</ul> </ul>
<t><strong>Claim <tt>method</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>method</tt></strong>:</t>
<li>SHA-256 Hash: <tt>WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ</tt><
<tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJ
<tt>["eI8ZWm9QnKPpNPeNenHdhQ", "method", "pipp"]</tt></li> waXBwIl0</tt></t></li>
<li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "method", "pipp"]</tt></t>
</li>
</ul> </ul>
<t><strong>Claim <tt>time</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>time</tt></strong>:</t>
<li>SHA-256 Hash: <tt>9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI</tt><
<tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0y</tt><br/> /t></li>
<tt>MlQxMTozMFoiXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjA
<li>Contents: xMi0wNC0yMlQxMTozMFoiXQ</tt></t></li>
<tt>["Qg_O64zqAxe412a108iroA", "time", "2012-04-22T11:30Z"]</tt></li> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "time", "2012-04-22T11:30Z
"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>document</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>document</tt></strong>:</t>
<li>SHA-256 Hash: <tt>IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4</tt><
<tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBl</tt><br/> /t></li>
<tt>IjogImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1</tt><br/> <li><t>Disclosure:</t><t><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50Iiw
<tt>cmciLCAiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0Iiwg</tt><br/> geyJ0eXBlIjogImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1cmciLCAiY29
<tt>ImRhdGVfb2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4</tt><br/> 1bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0IiwgImRhdGVfb2ZfaXNzdWFuY2UiOiAiMjA
<tt>cGlyeSI6ICIyMDIwLTAzLTIyIn1d</tt></li> xMC0wMy0yMyIsICJkYXRlX29mX2V4cGlyeSI6ICIyMDIwLTAzLTIyIn1d</tt></t></li>
<li>Contents: <li><t>Contents:</t><t><tt>["AJx-095VPrpTtN4QMOqROA", "document", {"type": "idca
<tt>["AJx-095VPrpTtN4QMOqROA", "document", {"type": "idcard",</tt><br/> rd", "issuer": {"name": "Stadt Augsburg", "country": "DE"}, "number": "53554554"
<tt>"issuer": {"name": "Stadt Augsburg", "country": "DE"},</tt><br/> , "date_of_issuance": "2010-03-23", "date_of_expiry": "2020-03-22"}]</tt></t></l
<tt>"number": "53554554", "date_of_issuance": "2010-03-23",</tt><br/> i>
<tt>"date_of_expiry": "2020-03-22"}]</tt></li>
</ul> </ul>
<t><strong>Array Entry</strong>:</t>
<ul spacing="compact"> <t><strong>Array Entry</strong>:</t>
<li>SHA-256 Hash: <tt>tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k</tt><
<tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1</tt><br/> /t></li>
<tt>RDdQSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhP</tt><br/> <li><t>Disclosure:</t><t><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl
<tt>QU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdG</tt><br/> 3cGpWUFd1RDdQSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZ
<tt>cldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldw</tt><br/> RTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdGcldVQjYzUmNacTl5dmdaMFhQYzdHb3d
<tt>eFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d</tt></li> oM08ya3FYZUJJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJ
<li>Contents: FVlEiXX1d</tt></t></li>
<tt>["Pc33JM2LchcU_lHggv_ufQ", {"_sd":</tt><br/> <li><t>Contents:</t><t><tt>["Pc33JM2LchcU_lHggv_ufQ", {"_sd": ["9wpjVPWuD7PK0nsQ
<tt>["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI",</tt><br/> DL8B06lmdgV3LVybhHydQpTNyLI", "G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk", "Ih
<tt>"G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk",</tt><br/> wFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4", "WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8o
<tt>"IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4",</tt><br/> HNr1bEVQ"]}]</tt></t></li>
<tt>"WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]</tt></li>
</ul> </ul>
<t><strong>Claim <tt>given_name</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>given_name</tt></strong>:</t>
<li>SHA-256 Hash: <tt>S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo</tt><
<tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4</tt><br/> /t></li>
<tt>Il0</tt></li> <li><t>Disclosure:</t><t><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWU
<li>Contents: iLCAiTWF4Il0</tt></t></li>
<tt>["G02NSrQfjFXQ7Io09syajA", "given_name", "Max"]</tt></li> <li><t>Contents:</t><t><tt>["G02NSrQfjFXQ7Io09syajA", "given_name", "Max"]</tt><
/t></li>
</ul> </ul>
<t><strong>Claim <tt>family_name</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>family_name</tt></strong>:</t>
<li>SHA-256 Hash: <tt>Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk</tt><
<tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1c</tt><br/> /t></li>
<tt>dTAwZmNsbGVyIl0</tt></li> <li><t>Disclosure:</t><t><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1
<li>Contents: lIiwgIk1cdTAwZmNsbGVyIl0</tt></t></li>
<tt>["lklxF5jMYlGTPUovMNIvCA", "family_name", "M\u00fcller"]</tt></li> <li><t>Contents:</t><t><tt>["lklxF5jMYlGTPUovMNIvCA", "family_name", "M\u00fclle
r"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>nationalities</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>nationalities</tt></strong>:</t>
<li>SHA-256 Hash: <tt>hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE</tt><
<tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBb</tt><br/> /t></li>
<tt>IkRFIl1d</tt></li> <li><t>Disclosure:</t><t><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXR
<li>Contents: pZXMiLCBbIkRFIl1d</tt></t></li>
<tt>["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]</tt></li> <li><t>Contents:</t><t><tt>["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]</
tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>birthdate</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>birthdate</tt></strong>:</t>
<li>SHA-256 Hash: <tt>WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk</tt><
<tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2</tt><br/> /t></li>
<tt>LTAxLTI4Il0</tt></li> <li><t>Disclosure:</t><t><tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSI
<li>Contents: sICIxOTU2LTAxLTI4Il0</tt></t></li>
<tt>["5bPs1IquZNa0hkaFzzzZNw", "birthdate", "1956-01-28"]</tt></li> <li><t>Contents:</t><t><tt>["5bPs1IquZNa0hkaFzzzZNw", "birthdate", "1956-01-28"]
</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>place_of_birth</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>place_of_birth</tt></strong>:</t>
<li>SHA-256 Hash: <tt>RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo</tt><
<tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwg</tt><br/> /t></li>
<tt>eyJjb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1</tt><br/> <li><t>Disclosure:</t><t><tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2J
<tt>MDBlNmphcmtsYXVzdHVyIn1d</tt></li> pcnRoIiwgeyJjb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1MDBlNmphcmt
<li>Contents: sYXVzdHVyIn1d</tt></t></li>
<tt>["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", {"country":</tt><br/> <li><t>Contents:</t><t><tt>["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", {"countr
<tt>"IS", "locality": "\u00deykkvab\u00e6jarklaustur"}]</tt></li> y": "IS", "locality": "\u00deykkvab\u00e6jarklaustur"}]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>address</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>address</tt></strong>:</t>
<li>SHA-256 Hash: <tt>_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ</tt><
<tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2Fs</tt><br/> /t></li>
<tt>aXR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNv</tt><br/> <li><t>Disclosure:</t><t><tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB
<tt>dW50cnkiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1</tt><br/> 7ImxvY2FsaXR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiOiA
<tt>MDBkZmUgMjIifV0</tt></li> iREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0</tt></t></li>
<li>Contents: <li><t>Contents:</t><t><tt>["y1sVU5wdfJahVdgwPgS7RQ", "address", {"locality": "M
<tt>["y1sVU5wdfJahVdgwPgS7RQ", "address", {"locality":</tt><br/> axstadt", "postal_code": "12344", "country": "DE", "street_address": "Weidenstra
<tt>"Maxstadt", "postal_code": "12344", "country": "DE",</tt><br/> \u00dfe 22"}]</tt></t></li>
<tt>"street_address": "Weidenstra\u00dfe 22"}]</tt></li>
</ul> </ul>
<t><strong>Claim <tt>birth_middle_name</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>birth_middle_name</tt></strong>:</t>
<li>SHA-256 Hash: <tt>otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI</tt><
<tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1l</tt><br/> /t></li>
<tt>IiwgIlRpbW90aGV1cyJd</tt></li> <li><t>Disclosure:</t><t><tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGR
<li>Contents: sZV9uYW1lIiwgIlRpbW90aGV1cyJd</tt></t></li>
<tt>["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name", "Timotheus"]</tt></li> <li><t>Contents:</t><t><tt>["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name", "Timo
theus"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>salutation</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>salutation</tt></strong>:</t>
<li>SHA-256 Hash: <tt>-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw</tt><
<tt>WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIu</tt><br/> /t></li>
<tt>Il0</tt></li> <li><t>Disclosure:</t><t><tt>WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24
<li>Contents: iLCAiRHIuIl0</tt></t></li>
<tt>["C9GSoujviJquEgYfojCb1A", "salutation", "Dr."]</tt></li> <li><t>Contents:</t><t><tt>["C9GSoujviJquEgYfojCb1A", "salutation", "Dr."]</tt><
/t></li>
</ul> </ul>
<t><strong>Claim <tt>msisdn</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>msisdn</tt></strong>:</t>
<li>SHA-256 Hash: <tt>IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg</tt><
<tt>WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1</tt><br/> /t></li>
<tt>Njc4OSJd</tt></li> <li><t>Disclosure:</t><t><tt>WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI
<li>Contents: 0OTEyMzQ1Njc4OSJd</tt></t></li>
<tt>["kx5kF17V-x0JmwUx9vgvtw", "msisdn", "49123456789"]</tt></li> <li><t>Contents:</t><t><tt>["kx5kF17V-x0JmwUx9vgvtw", "msisdn", "49123456789"]</
tt></t></li>
</ul> </ul>
<t>The following is a presentation of the SD-JWT:</t> <t>The following is a presentation of the SD-JWT:</t>
<sourcecode type="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qt <sourcecode type="txt"><![CDATA[
and0In0.eyJfc2QiOiBb eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
Ii1hU3puSWQ5bVdNOG9jdVFvbENsbHN4VmdncTEtdkhXNE90bmhVdFZtV3ciLCAiSUti Ii1hU3puSWQ5bVdNOG9jdVFvbENsbHN4VmdncTEtdkhXNE90bmhVdFZtV3ciLCAiSUti
cllObjN2QTdXRUZyeXN2YmRCSmpERFVfRXZRSXIwVzE4dlRScFVTZyIsICJvdGt4dVQx cllObjN2QTdXRUZyeXN2YmRCSmpERFVfRXZRSXIwVzE4dlRScFVTZyIsICJvdGt4dVQx
NG5CaXd6TkozTVBhT2l0T2w5cFZuWE9hRUhhbF94a3lOZktJIl0sICJpc3MiOiAiaHR0 NG5CaXd6TkozTVBhT2l0T2w5cFZuWE9hRUhhbF94a3lOZktJIl0sICJpc3MiOiAiaHR0
cHM6Ly9pc3N1ZXIuZXhhbXBsZS5jb20iLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6 cHM6Ly9pc3N1ZXIuZXhhbXBsZS5jb20iLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6
IDE4ODMwMDAwMDAsICJ2ZXJpZmllZF9jbGFpbXMiOiB7InZlcmlmaWNhdGlvbiI6IHsi IDE4ODMwMDAwMDAsICJ2ZXJpZmllZF9jbGFpbXMiOiB7InZlcmlmaWNhdGlvbiI6IHsi
X3NkIjogWyI3aDRVRTlxU2N2REtvZFhWQ3VvS2ZLQkpwVkJmWE1GX1RtQUdWYVplM1Nj X3NkIjogWyI3aDRVRTlxU2N2REtvZFhWQ3VvS2ZLQkpwVkJmWE1GX1RtQUdWYVplM1Nj
IiwgInZUd2UzcmFISUZZZ0ZBM3hhVUQyYU14Rno1b0RvOGlCdTA1cUtsT2c5THciXSwg IiwgInZUd2UzcmFISUZZZ0ZBM3hhVUQyYU14Rno1b0RvOGlCdTA1cUtsT2c5THciXSwg
InRydXN0X2ZyYW1ld29yayI6ICJkZV9hbWwiLCAiZXZpZGVuY2UiOiBbeyIuLi4iOiAi InRydXN0X2ZyYW1ld29yayI6ICJkZV9hbWwiLCAiZXZpZGVuY2UiOiBbeyIuLi4iOiAi
dFlKMFREdWN5WlpDUk1iUk9HNHFSTzV2a1BTRlJ4RmhVRUxjMThDU2wzayJ9XX0sICJj dFlKMFREdWN5WlpDUk1iUk9HNHFSTzV2a1BTRlJ4RmhVRUxjMThDU2wzayJ9XX0sICJj
bGFpbXMiOiB7Il9zZCI6IFsiUmlPaUNuNl93NVpIYWFka1FNcmNRSmYwSnRlNVJ3dXJS bGFpbXMiOiB7Il9zZCI6IFsiUmlPaUNuNl93NVpIYWFka1FNcmNRSmYwSnRlNVJ3dXJS
skipping to change at line 2765 skipping to change at line 2938
JFVlEiXX1d~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwI JFVlEiXX1d~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwI
l0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0~W l0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0~W
yJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTAwZmNsb yJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTAwZmNsb
GVyIl0~WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2Fsa GVyIl0~WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2Fsa
XR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiO XR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiO
iAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0~ iAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0~
]]> ]]>
</sourcecode> </sourcecode>
<t>The Verifier will have this Processed SD-JWT Payload available after validati on:</t> <t>The Verifier will have this Processed SD-JWT Payload available after validati on:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"iss": "https://issuer.example.com", "iss": "https://issuer.example.com",
"iat": 1683000000, "iat": 1683000000,
"exp": 1883000000, "exp": 1883000000,
"verified_claims": { "verified_claims": {
"verification": { "verification": {
"trust_framework": "de_aml", "trust_framework": "de_aml",
"evidence": [ "evidence": [
{ {
"method": "pipp" "method": "pipp"
} }
skipping to change at line 2795 skipping to change at line 2969
"country": "DE", "country": "DE",
"street_address": "Weidenstraße 22" "street_address": "Weidenstraße 22"
} }
} }
} }
} }
]]> ]]>
</sourcecode> </sourcecode>
</section> </section>
<section anchor="sd-jwt-based-verifiable-credentials-sd-jwt-vc"><name>SD-JWT-bas ed Verifiable Credentials (SD-JWT VC)</name> <section anchor="sd-jwt-based-verifiable-credentials-sd-jwt-vc"><name>SD-JWT-Bas ed Verifiable Credentials (SD-JWT VC)</name>
<t>This example shows how the artifacts defined in this specification could be <t>This example shows how the artifacts defined in this specification could be
used in the context of SD-JWT-based Verifiable used in the context of SD-JWT-based Verifiable
Credentials (SD-JWT VC) <xref target="I-D.ietf-oauth-sd-jwt-vc"/> to represent t he concept of Credentials (SD-JWT VC) <xref target="I-D.ietf-oauth-sd-jwt-vc"/> to represent t he concept of
a Person Identification Data (PID) as defined in the "PID Rulebook" in <xref tar get="EUDIW.ARF"/>. This example uses fictional data of a Person Identification Data (PID) as defined in the "PID Rulebook" in <xref tar get="EUDIW.ARF"/>. This example uses fictional data of
a German citizen.</t> a German citizen.</t>
<t>Key Binding is applied <t>Key Binding is applied
using the Holder's public key passed in a <tt>cnf</tt> claim in the SD-JWT.</t> 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> <t>The following citizen data is the input JWT Claims Set:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"vct": "urn:eudi:pid:de:1", "vct": "urn:eudi:pid:de:1",
"iss": "https://pid-issuer.bund.de.example", "iss": "https://pid-issuer.bund.de.example",
"given_name": "Erika", "given_name": "Erika",
"family_name": "Mustermann", "family_name": "Mustermann",
"birthdate": "1963-08-12", "birthdate": "1963-08-12",
"address": { "address": {
"street_address": "Heidestraße 17", "street_address": "Heidestraße 17",
"locality": "Köln", "locality": "Köln",
"postal_code": "51147", "postal_code": "51147",
"country": "DE" "country": "DE"
skipping to change at line 2845 skipping to change at line 3020
"age_birth_year": 1963, "age_birth_year": 1963,
"issuance_date": "2020-03-11", "issuance_date": "2020-03-11",
"expiry_date": "2030-03-12", "expiry_date": "2030-03-12",
"issuing_authority": "DE", "issuing_authority": "DE",
"issuing_country": "DE" "issuing_country": "DE"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>The following is the issued SD-JWT:</t> <t>The following is the issued SD-JWT:</t>
<sourcecode type="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9 <sourcecode type="txt"><![CDATA[
.eyJfc2QiOiBbIjBIWm1 eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1
uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21 uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21
VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJ VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJ
XclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0F XclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0F
rYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB rYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB
5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWk 5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWk
wQnFoV3FaM3dxRDRqRi1xREdrIiwgIkkwMGZjRlVvRFhDdWNwNXl5MnVqcVBzc0RWR2F wQnFoV3FaM3dxRDRqRi1xREdrIiwgIkkwMGZjRlVvRFhDdWNwNXl5MnVqcVBzc0RWR2F
XTmlVbGlOel9hd0QwZ2MiLCAiS2pBWGdBQTlONVdIRUR0UkloNHU1TW4xWnNXaXhoaFd XTmlVbGlOel9hd0QwZ2MiLCAiS2pBWGdBQTlONVdIRUR0UkloNHU1TW4xWnNXaXhoaFd
BaVgtQTRRaXdnQSIsICJMYWk2SVU2ZDdHUWFnWFI3QXZHVHJuWGdTbGQzejhFSWdfZnY BaVgtQTRRaXdnQSIsICJMYWk2SVU2ZDdHUWFnWFI3QXZHVHJuWGdTbGQzejhFSWdfZnY
zZk9aMVdnIiwgIkxlemphYlJxaVpPWHpFWW1WWmY4Uk1pOXhBa2QzX00xTFo4VTdFNHM zZk9aMVdnIiwgIkxlemphYlJxaVpPWHpFWW1WWmY4Uk1pOXhBa2QzX00xTFo4VTdFNHM
zdTQiLCAiUlR6M3FUbUZOSGJwV3JyT01aUzQxRjQ3NGtGcVJ2M3ZJUHF0aDZQVWhsTSI zdTQiLCAiUlR6M3FUbUZOSGJwV3JyT01aUzQxRjQ3NGtGcVJ2M3ZJUHF0aDZQVWhsTSI
skipping to change at line 2908 skipping to change at line 3084
IiwgImFnZV9pbl95ZWFycyIsIDYyXQ~WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgI IiwgImFnZV9pbl95ZWFycyIsIDYyXQ~WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgI
mFnZV9iaXJ0aF95ZWFyIiwgMTk2M10~WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgI mFnZV9iaXJ0aF95ZWFyIiwgMTk2M10~WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgI
mlzc3VhbmNlX2RhdGUiLCAiMjAyMC0wMy0xMSJd~WyI0S3lSMzJvSVp0LXprV3ZGcWJV mlzc3VhbmNlX2RhdGUiLCAiMjAyMC0wMy0xMSJd~WyI0S3lSMzJvSVp0LXprV3ZGcWJV
TEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzAtMDMtMTIiXQ~WyJjaEJDc3loeWgtSjg2S TEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzAtMDMtMTIiXQ~WyJjaEJDc3loeWgtSjg2S
S1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5IiwgIkRFIl0~WyJmbE5QMW5jTXo5T S1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5IiwgIkRFIl0~WyJmbE5QMW5jTXo5T
GctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJERSJd~ GctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJERSJd~
]]> ]]>
</sourcecode> </sourcecode>
<t>The following payload is used for the SD-JWT:</t> <t>The following payload is used for the SD-JWT:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"_sd": [ "_sd": [
"0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg", "0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg",
"1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow", "1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow",
"2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8", "2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8",
"6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os", "6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os",
"78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM", "78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM",
"90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk", "90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk",
"I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc", "I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc",
"KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA", "KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA",
"Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg", "Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg",
skipping to change at line 2940 skipping to change at line 3117
"_sd_alg": "sha-256", "_sd_alg": "sha-256",
"cnf": { "cnf": {
"jwk": { "jwk": {
"kty": "EC", "kty": "EC",
"crv": "P-256", "crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
} }
} }
} }
]]> ]]></sourcecode>
</sourcecode>
<t>The digests in the SD-JWT payload reference the following Disclosures:</t> <t>The digests in the SD-JWT payload reference the following Disclosures:</t>
<t><strong>Claim <tt>given_name</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>given_name</tt></strong>:</t>
<li>SHA-256 Hash: <tt>0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg</tt><
<tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJp</tt><br/> /t></li>
<tt>a2EiXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWU
<li>Contents: iLCAiRXJpa2EiXQ</tt></t></li>
<tt>["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]</tt></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]</tt
></t></li>
</ul> </ul>
<t><strong>Claim <tt>family_name</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>family_name</tt></strong>:</t>
<li>SHA-256 Hash: <tt>I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc</tt><
<tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11</tt><br/> /t></li>
<tt>c3Rlcm1hbm4iXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1
<li>Contents: lIiwgIk11c3Rlcm1hbm4iXQ</tt></t></li>
<tt>["eluV5Og3gSNII8EYnsxA_A", "family_name", "Mustermann"]</tt></li> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "family_name", "Mustermann
"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>birthdate</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>birthdate</tt></strong>:</t>
<li>SHA-256 Hash: <tt>Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg</tt><
<tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYz</tt><br/> /t></li>
<tt>LTA4LTEyIl0</tt></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSI
<li>Contents: sICIxOTYzLTA4LTEyIl0</tt></t></li>
<tt>["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1963-08-12"]</tt></li> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1963-08-12"]
</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>street_address</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>street_address</tt></strong>:</t>
<li>SHA-256 Hash: <tt>ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8</tt><
<tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwg</tt><br/> /t></li>
<tt>IkhlaWRlc3RyYVx1MDBkZmUgMTciXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInN0cmVldF9hZGR
<li>Contents: yZXNzIiwgIkhlaWRlc3RyYVx1MDBkZmUgMTciXQ</tt></t></li>
<tt>["eI8ZWm9QnKPpNPeNenHdhQ", "street_address",</tt><br/> <li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "street_address", "Heidest
<tt>"Heidestra\u00dfe 17"]</tt></li> ra\u00dfe 17"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>locality</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>locality</tt></strong>:</t>
<li>SHA-256 Hash: <tt>D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k</tt><
<tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAw</tt><br/> /t></li>
<tt>ZjZsbiJd</tt></li> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5Iiw
<li>Contents: gIktcdTAwZjZsbiJd</tt></t></li>
<tt>["Qg_O64zqAxe412a108iroA", "locality", "K\u00f6ln"]</tt></li> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "locality", "K\u00f6ln"]</
tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>postal_code</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>postal_code</tt></strong>:</t>
<li>SHA-256 Hash: <tt>xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I</tt><
<tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUx</tt><br/> /t></li>
<tt>MTQ3Il0</tt></li> <li><t>Disclosure:</t><t><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2R
<li>Contents: lIiwgIjUxMTQ3Il0</tt></t></li>
<tt>["AJx-095VPrpTtN4QMOqROA", "postal_code", "51147"]</tt></li> <li><t>Contents:</t><t><tt>["AJx-095VPrpTtN4QMOqROA", "postal_code", "51147"]</t
t></t></li>
</ul> </ul>
<t><strong>Claim <tt>country</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>country</tt></strong>:</t>
<li>SHA-256 Hash: <tt>eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0</tt><
<tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCA
<tt>["Pc33JM2LchcU_lHggv_ufQ", "country", "DE"]</tt></li> iREUiXQ</tt></t></li>
<li><t>Contents:</t><t><tt>["Pc33JM2LchcU_lHggv_ufQ", "country", "DE"]</tt></t><
/li>
</ul> </ul>
<t><strong>Claim <tt>address</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>address</tt></strong>:</t>
<li>SHA-256 Hash: <tt>RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM</tt><
<tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6</tt><br/> /t></li>
<tt>IFsiQUxaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3</tt><br/> <li><t>Disclosure:</t><t><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB
<tt>OCIsICJEX19XX3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNf</tt><br/> 7Il9zZCI6IFsiQUxaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3OCIsICJEX19
<tt>dzlrIiwgImVCcENYVTFKNWRoSDJnNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZ</tt><br/> XX3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNfdzlrIiwgImVCcENYVTFKNWRoSDJnNHQ
<tt>b1BobzAiLCAieE9QeTktZ0pBTEs2VWJXS0ZMUjg1Y09CeVVEM0FiTndGZzNJ</tt><br/> 4UVlOVzVFeFM5QXhVVmJsVW9kb0xZb1BobzAiLCAieE9QeTktZ0pBTEs2VWJXS0ZMUjg1Y09CeVVEM0F
<tt>M1lmUUVfSSJdfV0</tt></li> iTndGZzNJM1lmUUVfSSJdfV0</tt></t></li>
<li>Contents: <li><t>Contents:</t><t><tt>["G02NSrQfjFXQ7Io09syajA", "address", {"_sd": ["ALZER
<tt>["G02NSrQfjFXQ7Io09syajA", "address", {"_sd":</tt><br/> sSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8", "D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwI
<tt>["ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8",</tt><br/> s_w9k", "eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0", "xOPy9-gJALK6UbWKFLR85cOB
<tt>"D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k",</tt><br/> yUD3AbNwFg3I3YfQE_I"]}]</tt></t></li>
<tt>"eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0",</tt><br/>
<tt>"xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I"]}]</tt></li>
</ul> </ul>
<t><strong>Claim <tt>nationalities</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>nationalities</tt></strong>:</t>
<li>SHA-256 Hash: <tt>y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU</tt><
<tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBb</tt><br/> /t></li>
<tt>IkRFIl1d</tt></li> <li><t>Disclosure:</t><t><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXR
<li>Contents: pZXMiLCBbIkRFIl1d</tt></t></li>
<tt>["lklxF5jMYlGTPUovMNIvCA", "nationalities", ["DE"]]</tt></li> <li><t>Contents:</t><t><tt>["lklxF5jMYlGTPUovMNIvCA", "nationalities", ["DE"]]</
tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>sex</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>sex</tt></strong>:</t>
<li>SHA-256 Hash: <tt>90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk</tt><
<tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgInNleCIsIDJd</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgInNleCIsIDJd</t
<tt>["nPuoQnkRFq3BIeAm7AnXFA", "sex", 2]</tt></li> t></t></li>
<li><t>Contents:</t><t><tt>["nPuoQnkRFq3BIeAm7AnXFA", "sex", 2]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>birth_family_name</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>birth_family_name</tt></strong>:</t>
<li>SHA-256 Hash: <tt>KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA</tt><
<tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX2ZhbWlseV9uYW1l</tt><br/> /t></li>
<tt>IiwgIkdhYmxlciJd</tt></li> <li><t>Disclosure:</t><t><tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX2ZhbWl
<li>Contents: seV9uYW1lIiwgIkdhYmxlciJd</tt></t></li>
<tt>["5bPs1IquZNa0hkaFzzzZNw", "birth_family_name", "Gabler"]</tt></li> <li><t>Contents:</t><t><tt>["5bPs1IquZNa0hkaFzzzZNw", "birth_family_name", "Gabl
er"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>locality</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>locality</tt></strong>:</t>
<li>SHA-256 Hash: <tt>KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE</tt><
<tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImxvY2FsaXR5IiwgIkJlcmxp</tt><br/> /t></li>
<tt>biJd</tt></li> <li><t>Disclosure:</t><t><tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImxvY2FsaXR5Iiw
<li>Contents: gIkJlcmxpbiJd</tt></t></li>
<tt>["5a2W0_NrlEZzfqmk_7Pq-w", "locality", "Berlin"]</tt></li> <li><t>Contents:</t><t><tt>["5a2W0_NrlEZzfqmk_7Pq-w", "locality", "Berlin"]</tt>
</t></li>
</ul> </ul>
<t><strong>Claim <tt>country</tt></strong>:</t> <t><strong>Claim <tt>country</tt></strong>:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>SHA-256 Hash: <tt>YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ</tt></li> <li><t>SHA-256 Hash:</t><t><tt>YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ</tt><
<li>Disclosure:<br/> /t></li>
<tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImNvdW50cnkiLCAiREUiXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImNvdW50cnkiLCA
<li>Contents: iREUiXQ</tt></t></li>
<tt>["y1sVU5wdfJahVdgwPgS7RQ", "country", "DE"]</tt></li> <li><t>Contents:</t><t><tt>["y1sVU5wdfJahVdgwPgS7RQ", "country", "DE"]</tt></t><
/li>
</ul> </ul>
<t><strong>Claim <tt>place_of_birth</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>place_of_birth</tt></strong>:</t>
<li>SHA-256 Hash: <tt>1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow</tt><
<tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwg</tt><br/> /t></li>
<tt>eyJfc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BN</tt><br/> <li><t>Disclosure:</t><t><tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2J
<tt>alphR2t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVa</tt><br/> pcnRoIiwgeyJfc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BNalphR2t4QUU
<tt>Y2xGSFhmLVVTUSJdfV0</tt></li> iLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVaY2xGSFhmLVVTUSJdfV0</tt></t></l
<li>Contents: i>
<tt>["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd":</tt><br/> <li><t>Contents:</t><t><tt>["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd":
<tt>["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE",</tt><br/> ["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE", "YbsT0S76VqXCVsd1jUSlwKPDgmALeB1
<tt>"YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ"]}]</tt></li> uZclFHXf-USQ"]}]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>12</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>12</tt></strong>:</t>
<li>SHA-256 Hash: <tt>gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU</tt><
<tt>WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0
<tt>["C9GSoujviJquEgYfojCb1A", "12", true]</tt></li> </tt></t></li>
<li><t>Contents:</t><t><tt>["C9GSoujviJquEgYfojCb1A", "12", true]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>14</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>14</tt></strong>:</t>
<li>SHA-256 Hash: <tt>y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI</tt><
<tt>WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0
<tt>["kx5kF17V-x0JmwUx9vgvtw", "14", true]</tt></li> </tt></t></li>
<li><t>Contents:</t><t><tt>["kx5kF17V-x0JmwUx9vgvtw", "14", true]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>16</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>16</tt></strong>:</t>
<li>SHA-256 Hash: <tt>hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI</tt><
<tt>WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0
<tt>["H3o1uswP760Fi2yeGdVCEQ", "16", true]</tt></li> </tt></t></li>
<li><t>Contents:</t><t><tt>["H3o1uswP760Fi2yeGdVCEQ", "16", true]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>18</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>18</tt></strong>:</t>
<li>SHA-256 Hash: <tt>CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg</tt><
<tt>WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0
<tt>["OBKlTVlvLg-AdwqYGbP8ZA", "18", true]</tt></li> </tt></t></li>
<li><t>Contents:</t><t><tt>["OBKlTVlvLg-AdwqYGbP8ZA", "18", true]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>21</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>21</tt></strong>:</t>
<li>SHA-256 Hash: <tt>1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk</tt><
<tt>WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1ZV0</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1ZV0
<tt>["M0Jb57t41ubrkSuyrDT3xA", "21", true]</tt></li> </tt></t></li>
<li><t>Contents:</t><t><tt>["M0Jb57t41ubrkSuyrDT3xA", "21", true]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>65</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>65</tt></strong>:</t>
<li>SHA-256 Hash: <tt>a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg</tt><
<tt>WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2V
<tt>["DsmtKNgpV4dAHpjrcaosAw", "65", false]</tt></li> d</tt></t></li>
<li><t>Contents:</t><t><tt>["DsmtKNgpV4dAHpjrcaosAw", "65", false]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>age_equal_or_over</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>age_equal_or_over</tt></strong>:</t>
<li>SHA-256 Hash: <tt>2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8</tt><
<tt>WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVy</tt><br/> /t></li>
<tt>IiwgeyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4</tt><br/> <li><t>Disclosure:</t><t><tt>WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9
<tt>SFhBMHI1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lO</tt><br/> vcl9vdmVyIiwgeyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J
<tt>QTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96</tt><br/> 3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3pSYW9ock1EZyIsICJhNDQtZzJ
<tt>ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4</tt><br/> HcjhfM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd
<tt>bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNl</tt><br/> 4Y3FPbGY4bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlkaHJ
<tt>SVFBYUlkaHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFx</tt><br/> xVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21NZU8wS3FhekdJIl1
<tt>alFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ</tt></li> 9XQ</tt></t></li>
<li>Contents: <li><t>Contents:</t><t><tt>["eK5o5pHfgupPpltj1qhAJw", "age_equal_or_over", {"_sd
<tt>["eK5o5pHfgupPpltj1qhAJw", "age_equal_or_over", {"_sd":</tt><br/> ": ["1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk", "CVKnly5P90yJs3EwtxQiOtUczaXC
<tt>["1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk",</tt><br/> YNA4IczRaohrMDg", "a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg", "gkvy0FuvBBvj0h
<tt>"CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg",</tt><br/> s2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU", "hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI", "
<tt>"a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg",</tt><br/> y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI"]}]</tt></t></li>
<tt>"gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU",</tt><br/>
<tt>"hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI",</tt><br/>
<tt>"y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI"]}]</tt></li>
</ul> </ul>
<t><strong>Claim <tt>age_in_years</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>age_in_years</tt></strong>:</t>
<li>SHA-256 Hash: <tt>WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE</tt><
<tt>WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3IiwgImFnZV9pbl95ZWFycyIsIDYy</tt><br/> /t></li>
<tt>XQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3IiwgImFnZV9pbl95ZWF
<li>Contents: ycyIsIDYyXQ</tt></t></li>
<tt>["j7ADdb0UVb0Li0ciPcP0ew", "age_in_years", 62]</tt></li> <li><t>Contents:</t><t><tt>["j7ADdb0UVb0Li0ciPcP0ew", "age_in_years", 62]</tt></
t></li>
</ul> </ul>
<t><strong>Claim <tt>age_birth_year</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>age_birth_year</tt></strong>:</t>
<li>SHA-256 Hash: <tt>LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4</tt><
<tt>WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgImFnZV9iaXJ0aF95ZWFyIiwg</tt><br/> /t></li>
<tt>MTk2M10</tt></li> <li><t>Disclosure:</t><t><tt>WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgImFnZV9iaXJ0aF9
<li>Contents: 5ZWFyIiwgMTk2M10</tt></t></li>
<tt>["WpxJrFuX8uSi2p4ht09jvw", "age_birth_year", 1963]</tt></li> <li><t>Contents:</t><t><tt>["WpxJrFuX8uSi2p4ht09jvw", "age_birth_year", 1963]</t
t></t></li>
</ul> </ul>
<t><strong>Claim <tt>issuance_date</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>issuance_date</tt></strong>:</t>
<li>SHA-256 Hash: <tt>W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8</tt><
<tt>WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgImlzc3VhbmNlX2RhdGUiLCAi</tt><br/> /t></li>
<tt>MjAyMC0wMy0xMSJd</tt></li> <li><t>Disclosure:</t><t><tt>WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgImlzc3VhbmNlX2R
<li>Contents: hdGUiLCAiMjAyMC0wMy0xMSJd</tt></t></li>
<tt>["atSmFACYMbJVKD05o3JgtQ", "issuance_date", "2020-03-11"]</tt></li> <li><t>Contents:</t><t><tt>["atSmFACYMbJVKD05o3JgtQ", "issuance_date", "2020-03-
11"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>expiry_date</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>expiry_date</tt></strong>:</t>
<li>SHA-256 Hash: <tt>78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM</tt><
<tt>WyI0S3lSMzJvSVp0LXprV3ZGcWJVTEtnIiwgImV4cGlyeV9kYXRlIiwgIjIw</tt><br/> /t></li>
<tt>MzAtMDMtMTIiXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyI0S3lSMzJvSVp0LXprV3ZGcWJVTEtnIiwgImV4cGlyeV9kYXR
<li>Contents: lIiwgIjIwMzAtMDMtMTIiXQ</tt></t></li>
<tt>["4KyR32oIZt-zkWvFqbULKg", "expiry_date", "2030-03-12"]</tt></li> <li><t>Contents:</t><t><tt>["4KyR32oIZt-zkWvFqbULKg", "expiry_date", "2030-03-12
"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>issuing_authority</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>issuing_authority</tt></strong>:</t>
<li>SHA-256 Hash: <tt>6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os</tt><
<tt>WyJjaEJDc3loeWgtSjg2SS1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5</tt><br/> /t></li>
<tt>IiwgIkRFIl0</tt></li> <li><t>Disclosure:</t><t><tt>WyJjaEJDc3loeWgtSjg2SS1hd1FEaUNRIiwgImlzc3VpbmdfYXV
<li>Contents: 0aG9yaXR5IiwgIkRFIl0</tt></t></li>
<tt>["chBCsyhyh-J86I-awQDiCQ", "issuing_authority", "DE"]</tt></li> <li><t>Contents:</t><t><tt>["chBCsyhyh-J86I-awQDiCQ", "issuing_authority", "DE"]
</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>issuing_country</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>issuing_country</tt></strong>:</t>
<li>SHA-256 Hash: <tt>_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs</tt><
<tt>WyJmbE5QMW5jTXo5TGctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIs</tt><br/> /t></li>
<tt>ICJERSJd</tt></li> <li><t>Disclosure:</t><t><tt>WyJmbE5QMW5jTXo5TGctYzlxTUl6XzlnIiwgImlzc3VpbmdfY29
<li>Contents: 1bnRyeSIsICJERSJd</tt></t></li>
<tt>["flNP1ncMz9Lg-c9qMIz_9g", "issuing_country", "DE"]</tt></li> <li><t>Contents:</t><t><tt>["flNP1ncMz9Lg-c9qMIz_9g", "issuing_country", "DE"]</
tt></t></li>
</ul> </ul>
<t>The following is an example of an SD-JWT+KB that discloses only nationality a nd the fact that the person is over 18 years old:</t> <t>The following is an example of an SD-JWT+KB that discloses only nationality a nd the fact that the person is over 18 years old:</t>
<sourcecode type="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9 <sourcecode type="txt"><![CDATA[
.eyJfc2QiOiBbIjBIWm1 eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1
uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21 uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21
VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJ VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJ
XclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0F XclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0F
rYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB rYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB
5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWk 5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWk
wQnFoV3FaM3dxRDRqRi1xREdrIiwgIkkwMGZjRlVvRFhDdWNwNXl5MnVqcVBzc0RWR2F wQnFoV3FaM3dxRDRqRi1xREdrIiwgIkkwMGZjRlVvRFhDdWNwNXl5MnVqcVBzc0RWR2F
XTmlVbGlOel9hd0QwZ2MiLCAiS2pBWGdBQTlONVdIRUR0UkloNHU1TW4xWnNXaXhoaFd XTmlVbGlOel9hd0QwZ2MiLCAiS2pBWGdBQTlONVdIRUR0UkloNHU1TW4xWnNXaXhoaFd
BaVgtQTRRaXdnQSIsICJMYWk2SVU2ZDdHUWFnWFI3QXZHVHJuWGdTbGQzejhFSWdfZnY BaVgtQTRRaXdnQSIsICJMYWk2SVU2ZDdHUWFnWFI3QXZHVHJuWGdTbGQzejhFSWdfZnY
zZk9aMVdnIiwgIkxlemphYlJxaVpPWHpFWW1WWmY4Uk1pOXhBa2QzX00xTFo4VTdFNHM zZk9aMVdnIiwgIkxlemphYlJxaVpPWHpFWW1WWmY4Uk1pOXhBa2QzX00xTFo4VTdFNHM
zdTQiLCAiUlR6M3FUbUZOSGJwV3JyT01aUzQxRjQ3NGtGcVJ2M3ZJUHF0aDZQVWhsTSI zdTQiLCAiUlR6M3FUbUZOSGJwV3JyT01aUzQxRjQ3NGtGcVJ2M3ZJUHF0aDZQVWhsTSI
skipping to change at line 3270 skipping to change at line 3353
V0~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFI V0~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFI
l1d~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM l1d~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM
0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgIml 0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgIml
hdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlBqTVlmTTA3VmJKZE14TElsdXZSTmI hdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlBqTVlmTTA3VmJKZE14TElsdXZSTmI
4OEpGbGpTWDRuLUc0M1VjX0JTUk0ifQ.f3TeS_1BWEG78EbIJRh5wgv8nYumk7euzu6x 4OEpGbGpTWDRuLUc0M1VjX0JTUk0ifQ.f3TeS_1BWEG78EbIJRh5wgv8nYumk7euzu6x
gbgpNB4pbQQqgRPWK-vQjlhhgU1EFGZ9LFakFX_0mgul1G_3mw gbgpNB4pbQQqgRPWK-vQjlhhgU1EFGZ9LFakFX_0mgul1G_3mw
]]> ]]>
</sourcecode> </sourcecode>
<t>This is the payload of the corresponding Key Binding JWT:</t> <t>This is the payload of the corresponding Key Binding JWT:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"nonce": "1234567890", "nonce": "1234567890",
"aud": "https://verifier.example.org", "aud": "https://verifier.example.org",
"iat": 1748537244, "iat": 1748537244,
"sd_hash": "PjMYfM07VbJdMxLIluvRNb88JFljSX4n-G43Uc_BSRM" "sd_hash": "PjMYfM07VbJdMxLIluvRNb88JFljSX4n-G43Uc_BSRM"
} }
]]> ]]>
</sourcecode> </sourcecode>
<t>After validation, the Verifier will have the following Processed SD-JWT Paylo ad available for further handling:</t> <t>After validation, the Verifier will have the following Processed SD-JWT Paylo ad available for further handling:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"iss": "https://pid-issuer.bund.de.example", "iss": "https://pid-issuer.bund.de.example",
"iat": 1683000000, "iat": 1683000000,
"exp": 1883000000, "exp": 1883000000,
"vct": "urn:eudi:pid:de:1", "vct": "urn:eudi:pid:de:1",
"cnf": { "cnf": {
"jwk": { "jwk": {
"kty": "EC", "kty": "EC",
"crv": "P-256", "crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
} }
}, },
"age_equal_or_over": { "age_equal_or_over": {
"18": true "18": true
}, },
"nationalities": [ "nationalities": [
"DE" "DE"
] ]
} }
]]> ]]></sourcecode>
</sourcecode>
</section> </section>
<section anchor="w3c-verifiable-credentials-data-model-v2-0"><name>W3C Verifiabl e Credentials Data Model v2.0</name> <section anchor="w3c-verifiable-credentials-data-model-v2-0"><name>W3C Verifiabl e Credentials Data Model v2.0</name>
<t>This non-normative example illustrates how the artifacts defined in this spec ification <t>This non-normative example illustrates how the artifacts defined in this spec ification
could be used to express a W3C Verifiable Credentials Data Model v2.0 <xref targ et="VC_DATA_v2.0"/> payload.</t> could be used to express a W3C Verifiable Credentials Data Model v2.0 payload <x ref target="VC_DATA_v2.0"/>.</t>
<t>Key Binding is applied <t>Key Binding is applied
using the Holder's public key passed in a <tt>cnf</tt> claim in the SD-JWT.</t> 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> <t>The following is the input JWT Claims Set:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"@context": [ "@context": [
"https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/v1",
"https://w3id.org/vaccination/v1" "https://w3id.org/vaccination/v1"
], ],
"type": [ "type": [
"VerifiableCredential", "VerifiableCredential",
"VaccinationCertificate" "VaccinationCertificate"
], ],
"issuer": "https://example.com/issuer", "issuer": "https://example.com/issuer",
"issuanceDate": "2023-02-09T11:01:59Z", "issuanceDate": "2023-02-09T11:01:59Z",
skipping to change at line 3349 skipping to change at line 3434
"birthDate": "1961-08-17", "birthDate": "1961-08-17",
"givenName": "Marion", "givenName": "Marion",
"familyName": "Mustermann" "familyName": "Mustermann"
}, },
"type": "VaccinationEvent", "type": "VaccinationEvent",
"administeringCentre": "Praxis Sommergarten", "administeringCentre": "Praxis Sommergarten",
"batchNumber": "1626382736", "batchNumber": "1626382736",
"healthProfessional": "883110000015376" "healthProfessional": "883110000015376"
} }
} }
]]> ]]></sourcecode>
</sourcecode>
<t>The following is the issued SD-JWT:</t> <t>The following is the issued SD-JWT:</t>
<sourcecode type="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qt <sourcecode type="txt"><![CDATA[
and0In0.eyJAY29udGV4 eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4
dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0 dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0
cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJs cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJs
ZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjog ZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjog
Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIz Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIz
LTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDEx LTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDEx
OjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl OjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl
IiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl IiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl
IiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhi IiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhi
Wlk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3 Wlk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3
NGdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5 NGdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5
skipping to change at line 3401 skipping to change at line 3486
gImdlbmRlciIsICJGZW1hbGUiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJp gImdlbmRlciIsICJGZW1hbGUiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJp
cnRoRGF0ZSIsICIxOTYxLTA4LTE3Il0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwg cnRoRGF0ZSIsICIxOTYxLTA4LTE3Il0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwg
ImdpdmVuTmFtZSIsICJNYXJpb24iXQ~WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgI ImdpdmVuTmFtZSIsICJNYXJpb24iXQ~WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgI
mZhbWlseU5hbWUiLCAiTXVzdGVybWFubiJd~WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13 mZhbWlseU5hbWUiLCAiTXVzdGVybWFubiJd~WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13
IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd~WyJ IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd~WyJ
5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzODI3MzY 5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzODI3MzY
iXQ~WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCIs iXQ~WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCIs
ICI4ODMxMTAwMDAwMTUzNzYiXQ~ ICI4ODMxMTAwMDAwMTUzNzYiXQ~
]]> ]]>
</sourcecode> </sourcecode>
<t>The following payload is used for the SD-JWT:</t> <t>The following payload is used for the SD-JWT:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"@context": [ "@context": [
"https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/v1",
"https://w3id.org/vaccination/v1" "https://w3id.org/vaccination/v1"
], ],
"type": [ "type": [
"VerifiableCredential", "VerifiableCredential",
"VaccinationCertificate" "VaccinationCertificate"
], ],
"issuer": "https://example.com/issuer", "issuer": "https://example.com/issuer",
"issuanceDate": "2023-02-09T11:01:59Z", "issuanceDate": "2023-02-09T11:01:59Z",
skipping to change at line 3456 skipping to change at line 3543
"_sd_alg": "sha-256", "_sd_alg": "sha-256",
"cnf": { "cnf": {
"jwk": { "jwk": {
"kty": "EC", "kty": "EC",
"crv": "P-256", "crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
} }
} }
} }
]]> ]]></sourcecode>
</sourcecode>
<t>The digests in the SD-JWT payload reference the following Disclosures:</t> <t>The digests in the SD-JWT payload reference the following Disclosures:</t>
<t><strong>Claim <tt>atcCode</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>atcCode</tt></strong>:</t>
<li>SHA-256 Hash: <tt>1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI</tt><
<tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3Qlgw</tt><br/> /t></li>
<tt>MyJd</tt></li> <li><t>Disclosure:</t><t><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCA
<li>Contents: iSjA3QlgwMyJd</tt></t></li>
<tt>["2GLC42sKQveCfGfryNRN9w", "atcCode", "J07BX03"]</tt></li> <li><t>Contents:</t><t><tt>["2GLC42sKQveCfGfryNRN9w", "atcCode", "J07BX03"]</tt>
</t></li>
</ul> </ul>
<t><strong>Claim <tt>medicinalProductName</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>medicinalProductName</tt></strong>:</t>
<li>SHA-256 Hash: <tt>Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo</tt><
<tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3RO</tt><br/> /t></li>
<tt>YW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd</tt></li> <li><t>Disclosure:</t><t><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFB
<li>Contents: yb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd</tt></t></li>
<tt>["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName", "COVID-19</tt><br/> <li><t>Contents:</t><t><tt>["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName", "C
<tt>Vaccine Moderna"]</tt></li> OVID-19 Vaccine Moderna"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>marketingAuthorizationHolder</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>marketingAuthorizationHolder</tt></strong>:</t>
<li>SHA-256 Hash: <tt>Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE</tt><
<tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6</tt><br/> /t></li>
<tt>YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0</tt></li> <li><t>Disclosure:</t><t><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F
<li>Contents: 1dGhvcml6YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0</tt></t></li>
<tt>["6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHolder",</tt><br/> <li><t>Contents:</t><t><tt>["6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHol
<tt>"Moderna Biotech"]</tt></li> der", "Moderna Biotech"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>nextVaccinationDate</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>nextVaccinationDate</tt></strong>:</t>
<li>SHA-256 Hash: <tt>R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4</tt><
<tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRh</tt><br/> /t></li>
<tt>dGUiLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5
<li>Contents: hdGlvbkRhdGUiLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ</tt></t></li>
<tt>["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate",</tt><br/> <li><t>Contents:</t><t><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate", "20
<tt>"2021-08-16T13:40:12Z"]</tt></li> 21-08-16T13:40:12Z"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>countryOfVaccination</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>countryOfVaccination</tt></strong>:</t>
<li>SHA-256 Hash: <tt>JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg</tt><
<tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0</tt><br/> /t></li>
<tt>aW9uIiwgIkdFIl0</tt></li> <li><t>Disclosure:</t><t><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZ
<li>Contents: hY2NpbmF0aW9uIiwgIkdFIl0</tt></t></li>
<tt>["Qg_O64zqAxe412a108iroA", "countryOfVaccination", "GE"]</tt></li> <li><t>Contents:</t><t><tt>["Qg_O64zqAxe412a108iroA", "countryOfVaccination", "G
E"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>dateOfVaccination</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>dateOfVaccination</tt></strong>:</t>
<li>SHA-256 Hash: <tt>zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0</tt><
<tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9u</tt><br/> /t></li>
<tt>IiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0</tt></li> <li><t>Disclosure:</t><t><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2N
<li>Contents: pbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0</tt></t></li>
<tt>["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination",</tt><br/> <li><t>Contents:</t><t><tt>["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination", "2021
<tt>"2021-06-23T13:40:12Z"]</tt></li> -06-23T13:40:12Z"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>order</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>order</tt></strong>:</t>
<li>SHA-256 Hash: <tt>b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g</tt><
<tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd</tt></li> /t></li>
<li>Contents: <li><t>Disclosure:</t><t><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjM
<tt>["Pc33JM2LchcU_lHggv_ufQ", "order", "3/3"]</tt></li> vMyJd</tt></t></li>
<li><t>Contents:</t><t><tt>["Pc33JM2LchcU_lHggv_ufQ", "order", "3/3"]</tt></t></
li>
</ul> </ul>
<t><strong>Claim <tt>gender</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>gender</tt></strong>:</t>
<li>SHA-256 Hash: <tt>3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI</tt><
<tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUi</tt><br/> /t></li>
<tt>XQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJ
<li>Contents: GZW1hbGUiXQ</tt></t></li>
<tt>["G02NSrQfjFXQ7Io09syajA", "gender", "Female"]</tt></li> <li><t>Contents:</t><t><tt>["G02NSrQfjFXQ7Io09syajA", "gender", "Female"]</tt></
t></li>
</ul> </ul>
<t><strong>Claim <tt>birthDate</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>birthDate</tt></strong>:</t>
<li>SHA-256 Hash: <tt>Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU</tt><
<tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYx</tt><br/> /t></li>
<tt>LTA4LTE3Il0</tt></li> <li><t>Disclosure:</t><t><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSI
<li>Contents: sICIxOTYxLTA4LTE3Il0</tt></t></li>
<tt>["lklxF5jMYlGTPUovMNIvCA", "birthDate", "1961-08-17"]</tt></li> <li><t>Contents:</t><t><tt>["lklxF5jMYlGTPUovMNIvCA", "birthDate", "1961-08-17"]
</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>givenName</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>givenName</tt></strong>:</t>
<li>SHA-256 Hash: <tt>lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw</tt><
<tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJp</tt><br/> /t></li>
<tt>b24iXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSI
<li>Contents: sICJNYXJpb24iXQ</tt></t></li>
<tt>["nPuoQnkRFq3BIeAm7AnXFA", "givenName", "Marion"]</tt></li> <li><t>Contents:</t><t><tt>["nPuoQnkRFq3BIeAm7AnXFA", "givenName", "Marion"]</tt
></t></li>
</ul> </ul>
<t><strong>Claim <tt>familyName</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>familyName</tt></strong>:</t>
<li>SHA-256 Hash: <tt>1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA</tt><
<tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVz</tt><br/> /t></li>
<tt>dGVybWFubiJd</tt></li> <li><t>Disclosure:</t><t><tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWU
<li>Contents: iLCAiTXVzdGVybWFubiJd</tt></t></li>
<tt>["5bPs1IquZNa0hkaFzzzZNw", "familyName", "Mustermann"]</tt></li> <li><t>Contents:</t><t><tt>["5bPs1IquZNa0hkaFzzzZNw", "familyName", "Mustermann"
]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>administeringCentre</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>administeringCentre</tt></strong>:</t>
<li>SHA-256 Hash: <tt>TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg</tt><
<tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50</tt><br/> /t></li>
<tt>cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd</tt></li> <li><t>Disclosure:</t><t><tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJ
<li>Contents: pbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd</tt></t></li>
<tt>["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre", "Praxis</tt><br/> <li><t>Contents:</t><t><tt>["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre", "Pr
<tt>Sommergarten"]</tt></li> axis Sommergarten"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>batchNumber</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>batchNumber</tt></strong>:</t>
<li>SHA-256 Hash: <tt>V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM</tt><
<tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2</tt><br/> /t></li>
<tt>MjYzODI3MzYiXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmV
<li>Contents: yIiwgIjE2MjYzODI3MzYiXQ</tt></t></li>
<tt>["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber", "1626382736"]</tt></li> <li><t>Contents:</t><t><tt>["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber", "1626382736
"]</tt></t></li>
</ul> </ul>
<t><strong>Claim <tt>healthProfessional</tt></strong>:</t>
<ul spacing="compact"> <t><strong>Claim <tt>healthProfessional</tt></strong>:</t>
<li>SHA-256 Hash: <tt>1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww</tt></li> <ul spacing="normal">
<li>Disclosure:<br/> <li><t>SHA-256 Hash:</t><t><tt>1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww</tt><
<tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25h</tt><br/> /t></li>
<tt>bCIsICI4ODMxMTAwMDAwMTUzNzYiXQ</tt></li> <li><t>Disclosure:</t><t><tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Z
<li>Contents: lc3Npb25hbCIsICI4ODMxMTAwMDAwMTUzNzYiXQ</tt></t></li>
<tt>["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional",</tt><br/> <li><t>Contents:</t><t><tt>["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional", "883
<tt>"883110000015376"]</tt></li> 110000015376"]</tt></t></li>
</ul> </ul>
<t>This is an example of an SD-JWT+KB that discloses only <tt>type</tt>, <tt>med icinalProductName</tt>, <tt>atcCode</tt> of the vaccine, <tt>type</tt> of the <t t>recipient</tt>, <tt>type</tt>, <tt>order</tt> and <tt>dateOfVaccination</tt>:< /t>
<sourcecode type="txt"><![CDATA[eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qt <t>This is an example of an SD-JWT+KB that discloses only <tt>type</tt>, <tt>med
and0In0.eyJAY29udGV4 icinalProductName</tt>, <tt>atcCode</tt> of the vaccine, <tt>type</tt> of the <t
t>recipient</tt>, <tt>type</tt>, <tt>order</tt>, and <tt>dateOfVaccination</tt>:
</t>
<sourcecode type="txt"><![CDATA[
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4
dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0 dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0
cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJs cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJs
ZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjog ZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjog
Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIz Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIz
LTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDEx LTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDEx
OjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl OjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl
IiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl IiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl
IiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhi IiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhi
Wlk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3 Wlk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3
NGdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5 NGdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5
skipping to change at line 3645 skipping to change at line 3687
3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwg 3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwg
ImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyIyR0xD ImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyIyR0xD
NDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9 NDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9
nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE
5IFZhY2NpbmUgTW9kZXJuYSJd~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dC 5IFZhY2NpbmUgTW9kZXJuYSJd~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dC
J9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyL J9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyL
mV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIklvV1VIO mV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIklvV1VIO
TFsbGYzWEVybDQyYlEzc3hfNTNWMW8xdWpDejA4aERxSEs3RGsifQ.n0vzyIwCFMDVau TFsbGYzWEVybDQyYlEzc3hfNTNWMW8xdWpDejA4aERxSEs3RGsifQ.n0vzyIwCFMDVau
EaeJIWEKZZchxXMpXTQewHgAkARbOSZxB09IbXXtHfpoGqO_BtNFN2lShJEIQBGyc-Xp EaeJIWEKZZchxXMpXTQewHgAkARbOSZxB09IbXXtHfpoGqO_BtNFN2lShJEIQBGyc-Xp
HigA HigA
]]> ]]></sourcecode>
</sourcecode>
<t>After the validation, the Verifier will have the following Processed SD-JWT P ayload available for further handling:</t> <t>After the validation, the Verifier will have the following Processed SD-JWT P ayload available for further handling:</t>
<sourcecode type="json"><![CDATA[{ <sourcecode type="json"><![CDATA[
{
"@context": [ "@context": [
"https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/v1",
"https://w3id.org/vaccination/v1" "https://w3id.org/vaccination/v1"
], ],
"type": [ "type": [
"VerifiableCredential", "VerifiableCredential",
"VaccinationCertificate" "VaccinationCertificate"
], ],
"issuer": "https://example.com/issuer", "issuer": "https://example.com/issuer",
"issuanceDate": "2023-02-09T11:01:59Z", "issuanceDate": "2023-02-09T11:01:59Z",
skipping to change at line 3685 skipping to change at line 3727
}, },
"cnf": { "cnf": {
"jwk": { "jwk": {
"kty": "EC", "kty": "EC",
"crv": "P-256", "crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
} }
} }
} }
]]> ]]></sourcecode>
</sourcecode>
</section> </section>
<section anchor="elliptic-curve-key-used-in-the-examples"><name>Elliptic Curve K ey Used in the Examples</name> <section anchor="elliptic-curve-key-used-in-the-examples"><name>Elliptic Curve K ey Used in the Examples</name>
<t>The following Elliptic Curve public key, represented in JWK format, can be us ed to validate the Issuer signatures in the above examples:</t> <t>The following Elliptic Curve public key, represented in JWK format, can be us ed to validate the Issuer signatures in the above examples:</t>
<artwork><![CDATA[{ <artwork><![CDATA[
{
"kty": "EC", "kty": "EC",
"crv": "P-256", "crv": "P-256",
"x": "b28d4MwZMjw8-00CG4xfnn9SLMVMM19SlqZpVb_uNtQ", "x": "b28d4MwZMjw8-00CG4xfnn9SLMVMM19SlqZpVb_uNtQ",
"y": "Xv5zWwuoaTgdS6hV43yI6gBwTnjukmFQQnJ_kCxzqk8" "y": "Xv5zWwuoaTgdS6hV43yI6gBwTnjukmFQQnJ_kCxzqk8"
} }
]]> ]]></artwork>
</artwork>
<t>The public key used to validate a Key Binding JWT can be found in the example s as the content of the <tt>cnf</tt> claim.</t> <t>The public key used to validate a Key Binding JWT can be found in the example s as the content of the <tt>cnf</tt> claim.</t>
</section> </section>
</section> </section>
<section anchor="disclosure_format_considerations"><name>Disclosure Format Consi derations</name> <section anchor="disclosure_format_considerations"><name>Disclosure Format Consi derations</name>
<t>As described in <xref target="creating_disclosures"/>, the Disclosure structu re is JSON containing salt and the <t>As described in <xref target="creating_disclosures"/>, the Disclosure structu re is JSON containing a salt and the
cleartext content of a claim, which is base64url encoded. The encoded value is t he input used to calculate cleartext content of a claim, which is base64url encoded. The encoded value is t he input used to calculate
a digest for the respective claim. The inclusion of digest value in the signed J WT ensures the integrity of a digest for the respective claim. The inclusion of digest value in the signed J WT ensures the integrity of
the claim value. Using encoded content as the input to the integrity mechanism i s conceptually similar to the the claim value. Using encoded content as the input to the integrity mechanism i s conceptually similar to the
approach in JWS and particularly useful when the content, like JSON, can have di fferent representations but is semantically equivalent, thus avoiding canonicali zation. Some further discussion of the considerations around this design decisio n follows.</t> approach in JWS and particularly useful when the content, like JSON, can have di fferent representations but is semantically equivalent, thus avoiding canonicali zation. Some further discussion of the considerations around this design decisio n follows.</t>
<t>When receiving an SD-JWT, a Verifier must <t>When receiving an SD-JWT, a Verifier must
be able to re-compute digests of the disclosed claim values and, given be able to recompute digests of the disclosed claim values and, given
the same input values, obtain the same digest values as signed by the the same input values, obtain the same digest values as signed by the
Issuer.</t> Issuer.</t>
<t>Usually, JSON-based formats transport claim values as simple properties of a JSON object such as this:</t> <t>Usually, JSON-based formats transport claim values as simple properties of a JSON object such as this:</t>
<artwork><![CDATA[... <artwork><![CDATA[...
"family_name": "Möbius", "family_name": "Möbius",
"address": { "address": {
"street_address": "Schulstr. 12", "street_address": "Schulstr. 12",
"locality": "Schulpforta" "locality": "Schulpforta"
} }
skipping to change at line 3725 skipping to change at line 3767
<artwork><![CDATA[... <artwork><![CDATA[...
"family_name": "Möbius", "family_name": "Möbius",
"address": { "address": {
"street_address": "Schulstr. 12", "street_address": "Schulstr. 12",
"locality": "Schulpforta" "locality": "Schulpforta"
} }
... ...
]]> ]]>
</artwork> </artwork>
<t>However, a problem arises when computation over the data needs to be performe d and verified, like signing or computing digests. Common signature schemes requ ire the same byte string as input to the <t>However, a problem arises when computation over the data needs to be performe d and verified, like signing or computing digests. Common signature schemes requ ire the same byte string as input to the
signature verification as was used for creating the signature. In the digest app roach outlined above, the same problem exists: for the Issuer and the signature verification as was used for creating the signature. In the digest app roach 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> 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> <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", "family_name": "M\u00f6bius",
"address": { "address": {
"street_address": "Schulstr. 12", "street_address": "Schulstr. 12",
"locality": "Schulpforta" "locality": "Schulpforta"
} }
... ...
]]> ]]>
</artwork> </artwork>
<t>or as</t> <t>or as</t>
<artwork><![CDATA[... <artwork><![CDATA[
...
"family_name": "Möbius", "family_name": "Möbius",
"address": {"locality":"Schulpforta", "street_address":"Schulstr. 12"} "address": {"locality":"Schulpforta", "street_address":"Schulstr. 12"}
... ...
]]> ]]>
</artwork> </artwork>
<t>The two representations of the value in <tt>family_name</tt> are very differe
nt on the byte-level, but yield <t>The two representations of the value in <tt>family_name</tt> are very differe
equivalent objects. Same for the representations of <tt>address</tt>, varying in nt on the byte level, but they yield
white space and order of elements in the object.</t> equivalent objects. The same is true for the representations of <tt>address</tt>
, which vary in white space and order of elements in the object.</t>
<t>The variations in white space, ordering of object properties, and <t>The variations in white space, ordering of object properties, and
encoding of Unicode characters are all allowed by the JSON encoding of Unicode characters are all allowed by the JSON
specification, including further variations, e.g., concerning specification, including further variations, e.g., concerning
floating-point numbers, as described in <xref target="RFC8785"/>. Variations can be floating-point numbers, as described in <xref target="RFC8785"/>. Variations can be
introduced whenever JSON data is serialized or deserialized and unless introduced whenever JSON data is serialized or deserialized and unless
dealt with, will lead to different digests and the inability to verify dealt with, will lead to different digests and the inability to verify
signatures.</t> signatures.</t>
<t>There are generally two approaches to deal with this problem:</t> <t>There are generally two approaches to deal with this problem:</t>
<ol spacing="compact"> <ol spacing="normal">
<li>Canonicalization: The data is transferred in JSON format, potentially <li>Canonicalization: The data is transferred in JSON format, potentially
introducing variations in its representation, but is transformed into a introducing variations in its representation, but is transformed into a
canonical form before computing a digest. Both the Issuer and the Verifier canonical form before computing a digest. Both the Issuer and the Verifier
must use the same canonicalization algorithm to arrive at the same byte must use the same canonicalization algorithm to arrive at the same byte
string for computing a digest.</li> string for computing a digest.</li>
<li>Source string hardening: Instead of transferring data in a format that <li>Source string hardening: Instead of transferring data in a format that
may introduce variations, a representation of the data is serialized. may introduce variations, a representation of the data is serialized.
This representation is then used as the hashing input at the Verifier, This representation is then used as the hashing input at the Verifier,
but also transferred to the Verifier and used for the same digest 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 calculation there. This means that the Verifier can easily compute and check the
digest of the byte string before finally deserializing and digest of the byte string before finally deserializing and
accessing the data.</li> accessing the data.</li>
</ol> </ol>
<t>Mixed approaches are conceivable, i.e., transferring both the original JSON d ata <t>Mixed approaches are conceivable, i.e., transferring both the original JSON d ata
plus a string suitable for computing a digest, but such approaches can easily le ad to and a string suitable for computing a digest, but such approaches can easily lea d to
undetected inconsistencies resulting in time-of-check-time-of-use type security undetected inconsistencies resulting in time-of-check-time-of-use type security
vulnerabilities.</t> vulnerabilities.</t>
<t>In this specification, the source string hardening approach is used, as <t>In this specification, the source string hardening approach is used, as
it allows for simple and reliable interoperability without the it allows for simple and reliable interoperability without the
requirement for a canonicalization library. To harden the source string, requirement for a canonicalization library. To harden the source string,
any serialization format that supports the necessary data types could any serialization format that supports the necessary data types could
be used in theory, like protobuf, msgpack, or pickle. In this be used in theory, like protobuf, msgpack, or pickle. In this
specification, JSON is used and plaintext contents of each Disclosure are encode d using base64url-encoding specification, JSON is used and plaintext contents of each Disclosure are encode d using base64url encoding
for transport. This approach means that SD-JWTs can be implemented purely based 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> 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 <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 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 string are implicitly tolerated by the Verifier, as the digest is computed over a
predefined byte string and not over a JSON object.</t> predefined byte string and not over a JSON object.</t>
<t>It is important to note that the Disclosures are neither intended nor <t>It is important to note that the Disclosures are neither intended nor
suitable for direct consumption by suitable for direct consumption by
an application that needs to access the disclosed claim values after the verific ation by the Verifier. The an application that needs to access the disclosed claim values after the verific ation by the Verifier. The
Disclosures are only intended to be used by a Verifier to check Disclosures are only intended to be used by a Verifier to check
the digests over the source strings and to extract the original JSON the digests over the source strings and to extract the original JSON
data. The original JSON data is then used by the application. See data. The original JSON data is then used by the application. See
<xref target="verifier_verification"/> for details.</t> <xref target="verifier_verification"/> for details.</t>
</section> </section>
<section anchor="document-history"><name>Document History</name> <section numbered="false" anchor="Acknowledgements"><name>Acknowledgements</name
<t>[[ To be removed from the final specification ]]</t> >
<t>-22</t> <t>We would like to thank <contact fullname="Alen Horvat"/>, <contact
fullname="Alex Hodder"/>, <contact fullname="Anders Rundgren"/>, <contact
<ul spacing="compact"> fullname="Arjan Geluk"/>, <contact fullname="Chad Parry"/>, <contact
<li>fix text that was out of sync with the associated example</li> fullname="Christian Bormann"/>, <contact fullname="Christian Paquin"/>,
</ul> <contact fullname="Dale Bowie"/>, <contact fullname="Dan Moore"/>, <contact
<t>-21</t> fullname="David Bakker"/>, <contact fullname="David Waite"/>, <contact
fullname="Deb Cooley"/>, <contact fullname="Dick Hardt"/>, <contact
<ul spacing="compact"> fullname="Fabian Hauck"/>, <contact fullname="Filip Skokan"/>, <contact
<li>A few more minor IESG balloting updates</li> fullname="Giuseppe De Marco"/>, <contact fullname="Jacob Ward"/>, <contact
</ul> fullname="Jeffrey Yasskin"/>, <contact fullname="John Preuß Mattsson"/>, <contac
<t>-20</t> t
fullname="Joseph Heenan"/>, <contact fullname="Justin Richer"/>, <contact
<ul spacing="compact"> fullname="Kushal Das"/>, <contact fullname="Martin Thomson"/>, <contact
<li>IESG balloting updates</li> fullname="Matthew Miller"/>, <contact fullname="Michael Fraser"/>, <contact
</ul> fullname="Michael B.&nbsp;Jones"/>, <contact fullname="Mike Prorock"/>, <contact
<t>-19</t> fullname="Nat Sakimura"/>, <contact fullname="Neil Madden"/>, <contact
fullname="Oliver Terbu"/>, <contact fullname="Orie Steele"/>, <contact
<ul spacing="compact"> fullname="Paul Bastian"/>, <contact fullname="Peter Altmann"/>, <contact
<li>Attempt to improve some language around exactly what bytes get base64url enc fullname="Pieter Kasselman"/>, <contact fullname="Richard Barnes"/>, <contact
oded</li> fullname="Rohan Mahy"/>, <contact fullname="Roman Danyliw"/>, <contact
<li>Update the ABNF to something that is cleaner and more idiomatic</li> fullname="Ryosuke Abe"/>, <contact fullname="Sami Rosendahl"/>, <contact fullnam
<li>updates from AD's review of comments</li> e="Shawn Butterfield"/>, <contact fullname="Shawn Emery"/>, <contact
</ul> fullname="Simon Schulz"/>, <contact fullname="Takahiko Kawasaki"/>, <contact ful
<t>-18</t> lname="Tobias Looker"/>, <contact fullname="Torsten Lodderstedt"/>,
<contact fullname="Vittorio Bertocci"/>, <contact fullname="Watson Ladd"/>,
<ul spacing="compact"> and <contact fullname="Yaron Sheffer"/> for their contributions (some of which
<li>Update PID example to align with the latest ARF and update the ARF reference were substantial) to this draft and to the initial set of implementations.
</li>
<li>Editorial updates from SECDIR IETF LC review</li>
<li>Terminology improvements around the phrase "non-selectively disclosable clai
ms" and "not disclosable"</li>
<li>Suggest against using extra claims/headers in the KB-JWT without a good reas
on</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 updates to text introduced in -15</li>
<li>Changes based on feedback received after the end of the second 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 evaluation of formal 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>Note that the Hash Function Claim value is case-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 tar
get="sd_jwt_verification"/> on Verifying the SD-JWT</li>
<li>Moved considerations around unlinkability to the top of the Privacy Consider
ations section</li>
<li>Remove the brief discussion of publishing private key(s) to attempt to reduc
e 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 c
ollusion)</li>
<li>Tightened the exposition</li>
</ul>
<t>-10</t>
<ul spacing="compact"> <!-- [rfced] Acknowledgements: As it appears that "John Mattsson" is
<li>Add a section clarifying recursive disclosures and their interdependencies</ "John Preuß Mattsson", we updated his name in this list, per his
li> preference. (His last name is "Preuß Mattsson".) Please let us know
<li>Editorial updates/fixes</li> if this is a different "John Mattsson".
</ul>
<t>-09</t>
<ul spacing="compact"> Also, we saw that names were mostly ordered by first name and then by
<li>Distinguished SD-JWT from SD-JWT+KB</li> last name. We made adjustments between "Shawn Emery" in the original
<li>Provide ABNF for the SD-JWT, SD-JWT+KB, and various constituent parts</li> and "Takahiko Kawasaki" accordingly. Please let us know any concerns.
<li>New structure for JSON-serialized SD-JWTs/KB-JWTs to better align with JAdES
.</li>
<li>Attempt to better explain how salt in the Disclosure makes guessing the prei
mage 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"> Original:
<li>Make RFCs 0020 and 7515 normative references</li> ...
<li>Be a bit more prescriptive in suggesting RFC7800 cnf/jwk be used to convey t Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das,
he Key Binding key</li> ...
<li>Editorial changes aimed at improved clarity</li> Mahy, Roman Danyliw, Ryosuke Abe, Sami Rosendahl, Shawn Emery, Shawn
<li>Improve unlinkability considerations, mention that different KB keys must be Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten
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 that the VCDM and SD-JWT VC examples are only illustrative
and do not define anything</li>
</ul>
<t>-07</t>
<ul spacing="compact"> Currently:
<li>Reference RFC4086 in security considerations about salt entropy</li> ...
<li>Update change controller for the Structured Syntax Suffix registration from Yasskin, John Preuß Mattsson, Joseph Heenan, Justin Richer, Kushal
IESG to IETF per IANA suggestion</li> ...
<li>Strengthen security considerations around claims controlling the validity of Barnes, Rohan Mahy, Roman Danyliw, Ryosuke Abe, Sami Rosendahl, Shawn
the SD-JWT not being selectively disclosable</li> Butterfield, Shawn Emery, Simon Schulz, Takahiko Kawasaki, Tobias
<li>Expand/rework considerations on the choice of hash algorithm</li> ... -->
<li>Clarify validation around no duplicate digests in the payload (directly or r
ecursively) and no unused disclosures at the end 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"> </t>
<li>Added hash of Issuer-signed part and Disclosures in KB-JWT</li> <t>The work on this document was started at the OAuth Security Workshop 2022 in
<li>Fix minor issues in some examples</li> Trondheim,
<li>Added IANA media type registration request for the JSON Serialization</li> Norway.</t>
<li>More precise wording around storing artifacts with sensitive data</li> </section>
<li>The claim name <tt>_sd</tt> or <tt>...</tt> must not be used in a disclosure </back>
.</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 allow for the disc
losures to be conveyed elsewhere</li>
<li>Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serial
ized SD-JWTs</li>
</ul>
<t>-05</t>
<ul spacing="compact"> <!-- [rfced] Please let us know if any changes are needed for the
<li>Consolidate processing rules for Holder and Verifier</li> following:
<li>Add support for selective disclosure of array elements.</li>
<li>Consolidate SD-JWT terminology and format</li>
<li>Use the term Key Binding rather than Holder Binding</li>
<li>Defined the structure of the Key Binding JWT</li>
<li>Added a JWS JSON Serialization</li>
<li>Added initial IANA media type and structured suffix registration requests</l
i>
<li>Added recommendation for explicit typing of SD-JWTs</li>
<li>Added considerations around forwarding credentials</li>
<li>Removed Example 2b and merged the demo of decoy digests into Example 2a</li>
<li>Improved example for allowed variations in Disclosures</li>
<li>Added some text to the Abstract and Introduction to be more inclusive of JWS
with JSON</li>
<li>Added some security considerations text about the scope of the Key Binding J
WT</li>
<li>Aligned examples structure and used the term input JWT Claims Set</li>
<li>Replaced the general SD-JWT VC example with one based on Person Identificati
on Data (PID) from the European Digital Identity Wallet Architecture and Referen
ce Framework</li>
<li>Added/clarified some privacy considerations in Confidentiality during Transp
ort</li>
<li>No longer recommending a claim name for enveloped SD-JWTs</li>
<li>Mention prospective future PQ algs for JWS</li>
<li>Include the public key in the draft, which can be used to verify the issuer
signature examples</li>
<li>Clarify that <tt>_sd_alg</tt> can only be at the top level of the SD-JWT pay
load</li>
<li>Externalized the SD-JWT library that generates examples</li>
<li>Attempt to improve description of security properties</li>
</ul>
<t>-04</t>
<ul spacing="compact"> a) The following terms appear to be used inconsistently in this
<li>Improve description of processing of disclosures</li> document. Please let us know which form is preferred.
</ul>
<t>-03</t>
<ul spacing="compact"> Selective Disclosure for JWTs (SD-JWT) /
<li>Clarify that other specifications may define enveloping multiple Combined Fo Selectively Disclosable JWT (SD-JWT)
rmats 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 issuance and presentation<
/li>
<li>Added overview of the Security Considerations section</li>
<li>Enhanced examples in the Privacy Considerations section</li>
<li>Allow for recursive disclosures</li>
<li>Discussion on holder binding and privacy of stored credentials</li>
<li>Add some context about SD-JWT being general-purpose despite being a product
of the OAuth WG</li>
<li>More explicitly say that SD-JWTs have to be signed asymmetrically (no MAC an
d no <tt>none</tt>)</li>
<li>Make sha-256 the default hash algorithm, if the hash alg claim is omitted</l
i>
<li>Use ES256 instead of RS256 in examples</li>
<li>Rename and move the c14n challenges section to an appendix</li>
<li>A bit more in security considerations for Choice of a Hash Algorithm (1st &a
mp; 2nd preimage resistant and not majorly truncated)</li>
<li>Remove the notational figures from the Concepts section</li>
<li>Change salt to always be a string (rather than any JSON type)</li>
<li>Fix the Document History (which had a premature list for -03)</li>
</ul>
<t>-02</t>
<ul spacing="compact"> b) holder (4 instances) / Holder
<li>Disclosures are now delivered not as a JWT but as separate base64url-encoded
JSON objects.</li>
<li>In the SD-JWT, digests are collected under a <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 implement
ed, if required, with a separate JWT.</li>
<li>Examples updated and modified to properly explain the specifics of the new S
D-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"> also allowing the holder to reveal each of those nationalities
<li>introduced blinded claim names</li> With this set of disclosures, the holder could include the disclosure
<li>explained why JSON-encoding of values is needed</li> the holder would also need to include the disclosure with hash
<li>explained merging algorithm ("processing model")</li> holder is a military member or may have a substance use disorder.
<li>generalized hash alg to digest derivation alg which also enables HMAC to cal
culate 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-Disclosu
res)</li>
<li>SD-JWT-Release (SD-JWT-R) renamed to Holder-Selected Disclosures (HS-Disclos
ures)</li>
<li><tt>sd_disclosure</tt> in II-Disclosures renamed to <tt>sd_ii_disclosures</t
t></li>
<li><tt>sd_disclosure</tt> in HS-Disclosures renamed to <tt>sd_hs_disclosures</t
t></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"> c) key binding (2 instances) / Key Binding
<li>Upload as draft-ietf-oauth-selective-disclosure-jwt-00</li>
</ul>
<t>[[ pre Working Group Adoption: ]]</t>
<t>-02</t>
<ul spacing="compact"> 206: cryptographic key binding that can be presented to and verified
<li>Added acknowledgements</li> 2437: Verifier or even for each session with a Verifier. New key binding
<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"> d) disclosure (35 instances) / Disclosure (251 instances)
<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"> <!-- [rfced] Please review the "Inclusive Language" portion of the online
<li>Renamed to SD-JWT (focus on JWT instead of JWS since signature is optional)< Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
/li> and let us know if any changes are needed. Updates of this nature typically
<li>Make Holder Binding optional</li> result in more precise language, which is helpful for readers.
<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> Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</rfc> </rfc>
 End of changes. 518 change blocks. 
1913 lines changed or deleted 2080 lines changed or added

This html diff was produced by rfcdiff 1.48.