rfc9901.original		rfc9901.txt
	Web Authorization Protocol D. Fett		Internet Engineering Task Force (IETF) D. Fett
	Internet-Draft Authlete		Request for Comments: 9901 Authlete
	Intended status: Standards Track K. Yasuda		Category: Standards Track K. Yasuda
	Expires: 30 November 2025 Keio University		ISSN: 2070-1721 Keio University
	B. Campbell		B. Campbell
	Ping Identity		Ping Identity
	29 May 2025		November 2025
	Selective Disclosure for JWTs (SD-JWT)		Selective Disclosure for JSON Web Tokens (SD-JWTs)
	draft-ietf-oauth-selective-disclosure-jwt-22
	Abstract		Abstract
	This specification defines a mechanism for the selective disclosure		This specification defines a mechanism for the selective disclosure
	of individual elements of a JSON data structure used as the payload		of individual elements of a JSON data structure used as the payload
	of a JSON Web Signature (JWS). The primary use case is the selective		of a JSON Web Signature (JWS). The primary use case is the selective
	disclosure of JSON Web Token (JWT) claims.		disclosure of JSON Web Token (JWT) claims.
	Discussion Venues
	This note is to be removed before publishing as an RFC.
	Discussion of this document takes place on the Web Authorization
	Protocol Working Group mailing list (oauth@ietf.org), which is
	archived at https://mailarchive.ietf.org/arch/browse/oauth/.
	Source for this draft and an issue tracker can be found at
	https://github.com/oauth-wg/oauth-selective-disclosure-jwt.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 30 November 2025.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9901.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2025 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction
	1.1. Feature Summary . . . . . . . . . . . . . . . . . . . . . 5		1.1. Feature Summary
	1.2. Conventions and Terminology . . . . . . . . . . . . . . . 5		1.2. Conventions and Terminology
	2. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Flow Diagram
	3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Concepts
	3.1. SD-JWT and Disclosures . . . . . . . . . . . . . . . . . 7		3.1. SD-JWT and Disclosures
	3.2. Disclosing to a Verifier . . . . . . . . . . . . . . . . 8		3.2. Disclosing to a Verifier
	3.3. Optional Key Binding . . . . . . . . . . . . . . . . . . 8		3.3. Optional Key Binding
	3.4. Verification . . . . . . . . . . . . . . . . . . . . . . 8		3.4. Verification
	4. SD-JWT and SD-JWT+KB Data Formats . . . . . . . . . . . . . . 9		4. SD-JWT and SD-JWT+KB Data Formats
	4.1. Issuer-signed JWT . . . . . . . . . . . . . . . . . . . . 10		4.1. Issuer-Signed JWT
	4.1.1. Hash Function Claim . . . . . . . . . . . . . . . . . 11		4.1.1. Hash Function Claim
	4.1.2. Key Binding . . . . . . . . . . . . . . . . . . . . . 12		4.1.2. Key Binding
	4.2. Disclosures . . . . . . . . . . . . . . . . . . . . . . . 12		4.2. Disclosures
	4.2.1. Disclosures for Object Properties . . . . . . . . . . 13		4.2.1. Disclosures for Object Properties
	4.2.2. Disclosures for Array Elements . . . . . . . . . . . 14		4.2.2. Disclosures for Array Elements
	4.2.3. Hashing Disclosures . . . . . . . . . . . . . . . . . 15		4.2.3. Hashing Disclosures
	4.2.4. Embedding Disclosure Digests in SD-JWTs . . . . . . . 15		4.2.4. Embedding Disclosure Digests in SD-JWTs
	4.2.5. Decoy Digests . . . . . . . . . . . . . . . . . . . . 17		4.2.5. Decoy Digests
	4.2.6. Recursive Disclosures . . . . . . . . . . . . . . . . 17		4.2.6. Recursive Disclosures
	4.3. Key Binding JWT . . . . . . . . . . . . . . . . . . . . . 19		4.3. Key Binding JWT
	4.3.1. Binding to an SD-JWT . . . . . . . . . . . . . . . . 20		4.3.1. Binding to an SD-JWT
	4.3.2. Validating the Key Binding JWT . . . . . . . . . . . 20		4.3.2. Validating the Key Binding JWT
	5. Example SD-JWT . . . . . . . . . . . . . . . . . . . . . . . 20		5. Example SD-JWT
	5.1. Issuance . . . . . . . . . . . . . . . . . . . . . . . . 21		5.1. Issuance
	5.2. Presentation . . . . . . . . . . . . . . . . . . . . . . 25		5.2. Presentation
	6. Considerations on Nested Data in SD-JWTs . . . . . . . . . . 27		6. Considerations on Nested Data in SD-JWTs
	6.1. Example: Flat SD-JWT . . . . . . . . . . . . . . . . . . 28		6.1. Example: Flat SD-JWT
	6.2. Example: Structured SD-JWT . . . . . . . . . . . . . . . 29		6.2. Example: Structured SD-JWT
	6.3. Example: SD-JWT with Recursive Disclosures . . . . . . . 30		6.3. Example: SD-JWT with Recursive Disclosures
	7. Verification and Processing . . . . . . . . . . . . . . . . . 32		7. Verification and Processing
	7.1. Verification of the SD-JWT . . . . . . . . . . . . . . . 32		7.1. Verification of the SD-JWT
	7.2. Processing by the Holder . . . . . . . . . . . . . . . . 34		7.2. Processing by the Holder
	7.3. Verification by the Verifier . . . . . . . . . . . . . . 35		7.3. Verification by the Verifier
	8. JWS JSON Serialization . . . . . . . . . . . . . . . . . . . 36		8. JWS JSON Serialization
	8.1. New Unprotected Header Parameters . . . . . . . . . . . . 36		8.1. New Unprotected Header Parameters
	8.2. Flattened JSON Serialization . . . . . . . . . . . . . . 36		8.2. Flattened JSON Serialization
	8.3. General JSON Serialization . . . . . . . . . . . . . . . 38		8.3. General JSON Serialization
	8.4. Verification of the JWS JSON Serialized SD-JWT . . . . . 40		8.4. Verification of the JWS JSON Serialized SD-JWT
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 40		9. Security Considerations
	9.1. Mandatory Signing of the Issuer-signed JWT . . . . . . . 40		9.1. Mandatory Signing of the Issuer-Signed JWT
	9.2. Manipulation of Disclosures . . . . . . . . . . . . . . . 41		9.2. Manipulation of Disclosures
	9.3. Entropy of the Salt . . . . . . . . . . . . . . . . . . . 41		9.3. Entropy of the Salt
	9.4. Choice of a Hash Algorithm . . . . . . . . . . . . . . . 42		9.4. Choice of a Hash Algorithm
	9.5. Key Binding . . . . . . . . . . . . . . . . . . . . . . . 42		9.5. Key Binding
	9.6. Concealing Claim Names . . . . . . . . . . . . . . . . . 43		9.6. Concealing Claim Names
	9.7. Selectively-Disclosable Validity Claims . . . . . . . . . 44		9.7. Selectively Disclosable Validity Claims
	9.8. Distribution and Rotation of Issuer Signature Verification		9.8. Distribution and Rotation of Issuer Signature Verification
	Key . . . . . . . . . . . . . . . . . . . . . . . . . . 44		Key
	9.9. Forwarding Credentials . . . . . . . . . . . . . . . . . 45		9.9. Forwarding Credentials
	9.10. Integrity of SD-JWTs and SD-JWT+KBs . . . . . . . . . . . 45		9.10. Integrity of SD-JWTs and SD-JWT+KBs
	9.11. Explicit Typing . . . . . . . . . . . . . . . . . . . . . 45		9.11. Explicit Typing
	9.12. Key Pair Generation and Lifecycle Management . . . . . . 46		9.12. Key Pair Generation and Lifecycle Management
	10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 46		10. Privacy Considerations
	10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 46		10.1. Unlinkability
	10.2. Storage of User Data . . . . . . . . . . . . . . . . . . 49		10.2. Storage of User Data
	10.3. Confidentiality during Transport . . . . . . . . . . . . 49		10.3. Confidentiality During Transport
	10.4. Decoy Digests . . . . . . . . . . . . . . . . . . . . . 50		10.4. Decoy Digests
	10.5. Issuer Identifier . . . . . . . . . . . . . . . . . . . 50		10.5. Issuer Identifier
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51		11. IANA Considerations
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51		11.1. JSON Web Token Claims Registration
	12.1. JSON Web Token Claims Registration . . . . . . . . . . . 51		11.2. Media Type Registrations
	12.2. Media Type Registration . . . . . . . . . . . . . . . . 52		11.2.1. SD-JWT Content
	12.3. Structured Syntax Suffix Registration . . . . . . . . . 54		11.2.2. JWS JSON Serialized SD-JWT Content
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 54		11.2.3. Key Binding JWT Content
	13.1. Normative References . . . . . . . . . . . . . . . . . . 54		11.3. Structured Syntax Suffixes Registration
	13.2. Informative References . . . . . . . . . . . . . . . . . 55		12. References
	Appendix A. Additional Examples . . . . . . . . . . . . . . . . 58		12.1. Normative References
	A.1. Simple Structured SD-JWT . . . . . . . . . . . . . . . . 58		12.2. Informative References
	A.2. Complex Structured SD-JWT . . . . . . . . . . . . . . . . 62		Appendix A. Additional Examples
	A.3. SD-JWT-based Verifiable Credentials (SD-JWT VC) . . . . . 69		A.1. Simple Structured SD-JWT
	A.4. W3C Verifiable Credentials Data Model v2.0 . . . . . . . 79		A.2. Complex Structured SD-JWT
	A.5. Elliptic Curve Key Used in the Examples . . . . . . . . . 87		A.3. SD-JWT-Based Verifiable Credentials (SD-JWT VC)
	Appendix B. Disclosure Format Considerations . . . . . . . . . . 88		A.4. W3C Verifiable Credentials Data Model v2.0
	Appendix C. Document History . . . . . . . . . . . . . . . . . . 90		A.5. Elliptic Curve Key Used in the Examples
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96		Appendix B. Disclosure Format Considerations
			Acknowledgements
			Authors' Addresses
	1. Introduction		1. Introduction
	JSON data for exchange between systems is often secured against		The exchange of JSON data between systems is often secured against
	modification using JSON Web Signatures (JWS) [RFC7515]. A popular		modification using JSON Web Signatures (JWSs) [RFC7515]. A popular
	application of JWS is JSON Web Token (JWT) [RFC7519], a format that		application of JWS is the JSON Web Token (JWT) [RFC7519], a format
	is often used to represent a user's identity. An ID Token as defined		that is often used to represent a user's identity. An ID Token as
	in OpenID Connect [OpenID.Core], for example, is a JWT containing the		defined in OpenID Connect [OpenID.Core], for example, is a JWT
	user's claims created by the server for consumption by a relying		containing the user's claims created by the server for consumption by
	party. In cases where the JWT is sent immediately from the server to		a relying party. In cases where the JWT is sent immediately from the
	the relying party, as in OpenID Connect, the server can select at the		server to the relying party, as in OpenID Connect, the server can
	time of issuance which user claims to include in the JWT, minimizing		select at the time of issuance which user claims to include in the
	the information shared with the relying party who validates the JWT.		JWT, minimizing the information shared with the relying party who
			validates the JWT.
	Another model is emerging that fully decouples the issuance of a JWT		Another model is emerging that fully decouples the issuance of a JWT
	from its presentation. In this model, a JWT containing many claims		from its presentation. In this model, a JWT containing many claims
	is issued to an intermediate party, who holds the JWT (the Holder).		is issued to an intermediate party, who holds the JWT (the Holder).
	The Holder can then present the JWT to different verifying parties		The Holder can then present the JWT to different verifying parties
	(Verifiers), that each may only require a subset of the claims in the		(Verifiers) that each may only require a subset of the claims in the
	JWT. For example, the JWT may contain claims representing both an		JWT. For example, the JWT may contain claims representing both an
	address and a birthdate. The Holder may elect to disclose only the		address and a birthdate. The Holder may elect to disclose only the
	address to one Verifier, and only the birthdate to a different		address to one Verifier, and only the birthdate to a different
	Verifier.		Verifier.
	Privacy principles of minimal disclosure in conjunction with this		Privacy principles of minimal disclosure in conjunction with this
	model demand a mechanism enabling selective disclosure of data		model demand a mechanism enabling selective disclosure of data
	elements while ensuring that Verifiers can still check the		elements while ensuring that Verifiers can still check the
	authenticity of the data provided. This specification, Selective		authenticity of the data provided. This specification defines such a
	Disclosure for JSON Web Tokens (SD-JWT), defines such a mechanism for		mechanism for JSON payloads of JWSs, with JWTs as the primary use
	JSON payloads of JSON Web Signatures (JWS), with JWTs as the primary		case.
	use case.
	SD-JWT is based on an approach called "salted hashes": For any data		SD-JWT is based on an approach called "salted hashes": For any data
	element that should be selectively disclosable, the Issuer of the SD-		element that should be selectively disclosable, the Issuer of the SD-
	JWT does not include the cleartext of the data in the JSON payload of		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.		the JWS structure; instead, a digest of the data takes its place.
	For presentation to a Verifier, the Holder sends the signed payload		For presentation to a Verifier, the Holder sends the signed payload
	along with the cleartext of those claims it wants to disclose. The		along with the cleartext of those claims it wants to disclose. The
	Verifier can then compute the digest of the cleartext data and		Verifier can then compute the digest of the cleartext data and
	confirm it is included in the signed payload. To ensure that		confirm it is included in the signed payload. To ensure that
	Verifiers cannot guess cleartext values of non-disclosed data		Verifiers cannot guess cleartext values of non-disclosed data
	elements, an additional salt value is used when creating the digest		elements, an additional salt value is used when creating the digest
	and sent along with the cleartext when disclosing it.		and sent along with the cleartext when disclosing it.
	To prevent attacks in which an SD-JWT is presented to a Verifier		To prevent attacks in which an SD-JWT is presented to a Verifier
	without the Holder's consent, this specification additionally defines		without the Holder's consent, this specification additionally defines
	a mechanism for binding the SD-JWT to a key under the control of the		a mechanism for binding the SD-JWT to a key under the control of the
	Holder (Key Binding). When Key Binding is enforced, a Holder has to		Holder (Key Binding). When Key Binding is enforced, a Holder has to
	prove possession of a private key belonging to a public key contained		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		in the SD-JWT itself. It usually does so by signing over a data
	structure containing transaction-specific data, herein defined as the		structure containing transaction-specific data, herein defined as the
	Key Binding JWT. An SD-JWT with a Key Binding JWT is called SD-		Key Binding JWT. An SD-JWT with a Key Binding JWT is called "SD-
	JWT+KB in this specification.		JWT+KB" in this specification.
	1.1. Feature Summary		1.1. Feature Summary
	This specification defines two primary data formats:		This specification defines two primary data formats:
	1. SD-JWT is a composite structure, consisting of a JWS plus		1. SD-JWT is a composite structure, consisting of a JWS plus
	optional disclosures, enabling selective disclosure of portions		optional disclosures, enabling selective disclosure of portions
	of the JWS payload. It comprises the following:		of the JWS payload. It comprises the following:
	* A format for enabling selective disclosure in nested JSON data		* A format for enabling selective disclosure in nested JSON data
	structures, supporting selectively disclosable object		structures, supporting selectively disclosable object
	properties (name/value pairs) and array elements		properties (name/value pairs) and array elements.
	* A format for encoding the selectively disclosable data items
			* A format for encoding the selectively disclosable data items.
	* A format extending the JWS Compact Serialization, allowing for		* A format extending the JWS Compact Serialization, allowing for
	the combined transport of the Issuer-signed JSON data		the combined transport of the Issuer-signed JSON data
	structure and the disclosable data items		structure and the disclosable data items.
	* An alternate format extending the JWS JSON Serialization, also		* An alternate format extending the JWS JSON Serialization, also
	allowing for transport of the Issuer-signed JSON data		allowing for transport of the Issuer-signed JSON data
	structure and disclosure data		structure and disclosure data.
	2. SD-JWT+KB is a composite structure of an SD-JWT and a		2. SD-JWT+KB is a composite structure of an SD-JWT and a
	cryptographic key binding that can be presented to and verified		cryptographic key binding that can be presented to and verified
	by the Verifier. It comprises the following:		by the Verifier. It comprises the following:
	* A mechanism for associating an SD-JWT with a key pair		* A mechanism for associating an SD-JWT with a key pair.
	* A format for a Key Binding JWT (KB-JWT) that allows proof of		* A format for a Key Binding JWT (KB-JWT) that allows proof of
	possession of the private key of the associated key pair		possession of the private key of the associated key pair.
	* A format extending the SD-JWT format for the combined		* A format extending the SD-JWT format for the combined
	transport of the SD-JWT and the KB-JWT		transport of the SD-JWT and the KB-JWT.
	1.2. Conventions and Terminology		1.2. Conventions and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	*Base64url* denotes the URL-safe base64 encoding without padding		*Base64url* denotes the URL-safe base64 encoding without padding
	defined in Section 2 of [RFC7515].		defined in Section 2 of [RFC7515].
	Throughout the document the term "claims" refers generally to both		Throughout this document, the term "claims" refers generally to
	object properties (name/value pairs) as well as array elements.		object properties (name/value pairs) as well as array elements.
	Selective Disclosure: Process of a Holder disclosing to a Verifier a		Selective Disclosure:
	subset of claims contained in a JWT issued by an Issuer.		Process of a Holder disclosing to a Verifier a subset of claims
	Selectively Disclosable JWT (SD-JWT): A composite structure,		contained in a JWT issued by an Issuer.
	consisting of an Issuer-signed JWT (JWS, [RFC7515]) and zero or
	more Disclosures, which supports selective disclosure as defined		Selectively Disclosable JWT (SD-JWT):
	in this document. It can contain both regular claims and digests		A composite structure, consisting of an Issuer-signed JWT (JWS;
	of selectively-disclosable claims.		see [RFC7515]) and zero or more Disclosures, which supports
	Disclosure: A base64url-encoded string of a JSON array that contains		selective disclosure as defined in this document. It can contain
	a salt, a claim name (present when the claim is a name/value pair		both regular claims and digests of selectively disclosable claims.
	and absent when the claim is an array element), and a claim value.
	The Disclosure is used to calculate a digest for the respective		Disclosure:
	claim. The term Disclosure refers to the whole base64url-encoded		A base64url-encoded string of a JSON array that contains a salt, a
	string.		claim name (present when the claim is a name/value pair and absent
	Key Binding: Ability of the Holder to prove possession of an SD-JWT		when the claim is an array element), and a claim value. The
	by proving control over a private key during the presentation.		Disclosure is used to calculate a digest for the respective claim.
	When utilizing Key Binding, an SD-JWT contains the public key		The term Disclosure refers to the whole base64url-encoded string.
			Key Binding:
			Ability of the Holder to prove possession of an SD-JWT by proving
			control over a private key during the presentation. When
			utilizing Key Binding, an SD-JWT contains the public key
	corresponding to the private key controlled by the Holder (or a		corresponding to the private key controlled by the Holder (or a
	reference to this public key).		reference to this public key).
	Key Binding JWT (KB-JWT): A Key Binding JWT is said to "be tied to"
	a particular SD-JWT when its payload is signed using the key		Key Binding JWT (KB-JWT):
	included in the SD-JWT payload, and the KB-JWT contains a hash of		A Key Binding JWT is said to "be tied to" a particular SD-JWT when
	the SD-JWT in its sd_hash claim. Its format is defined in		its payload is signed using the key included in the SD-JWT
	Section 4.3.		payload, and the KB-JWT contains a hash of the SD-JWT in its
	Selectively Disclosable JWT with Key Binding (SD-JWT+KB): A		sd_hash claim. Its format is defined in Section 4.3.
	composite structure, comprising an SD-JWT and a Key Binding JWT
			Selectively Disclosable JWT with Key Binding (SD-JWT+KB):
			A composite structure, comprising an SD-JWT and a Key Binding JWT
	tied to that SD-JWT.		tied to that SD-JWT.
	Processed SD-JWT Payload The JSON object resulting from verification
	and processing of the Issuer-signed SD-JWT, with digest		Processed SD-JWT Payload:
	placeholders replaced by the corresponding values from the		The JSON object resulting from verification and processing of the
	Disclosures.		Issuer-signed SD-JWT, with digest placeholders replaced by the
	Issuer: An entity that creates SD-JWTs.		corresponding values from the Disclosures.
	Holder: An entity that received SD-JWTs from the Issuer and has
	control over them. In the context of this document, the term may		Issuer:
	refer to the actual user, the supporting hardware and software in		An entity that creates SD-JWTs.
	their possession, or both.
	Verifier: An entity that requests, checks, and extracts the claims		Holder:
	from an SD-JWT with its respective Disclosures.		An entity that received SD-JWTs from the Issuer and has control
			over them. In the context of this document, the term may refer to
			the actual user, the supporting hardware and software in their
			possession, or both.
			Verifier:
			An entity that requests, checks, and extracts the claims from an
			SD-JWT with its respective Disclosures.
	2. Flow Diagram		2. Flow Diagram
	+------------+		+------------+
	| |		| |
	| Issuer |		| Issuer |
	| |		| |
	+------------+		+------------+
	|		|
	Issues SD-JWT		Issues SD-JWT
	including all Disclosures		including all Disclosures
	|		|
	v		v
	skipping to change at page 7, line 45 ¶		skipping to change at line 325 ¶
	This section describes SD-JWTs with their respective Disclosures and		This section describes SD-JWTs with their respective Disclosures and
	Key Binding at a conceptual level, abstracting from the data formats		Key Binding at a conceptual level, abstracting from the data formats
	described in Section 4.		described in Section 4.
	3.1. SD-JWT and Disclosures		3.1. SD-JWT and Disclosures
	An SD-JWT, at its core, is a digitally signed JSON document		An SD-JWT, at its core, is a digitally signed JSON document
	containing digests over the selectively disclosable claims with the		containing digests over the selectively disclosable claims with the
	Disclosures outside the document. Disclosures can be omitted without		Disclosures outside the document. Disclosures can be omitted without
	breaking the signature, and modifying them can be detected.		breaking the signature, and modifications to them can be detected.
	Selectively disclosable claims can be individual object properties		Selectively disclosable claims can be individual object properties
	(name/value pairs) or array elements.		(name/value pairs) or array elements.
	Each digest value ensures the integrity of, and maps to, the		Each digest value ensures the integrity of, and maps to, the
	respective Disclosure. Digest values are calculated using a hash		respective Disclosure. Digest values are calculated using a hash
	function over the Disclosures, each of which contains a		function over the Disclosures, each of which contains a
	cryptographically secure random salt, the claim name (only when the		cryptographically secure random salt, the claim name (only when the
	claim is an object property), and the claim value. The Disclosures		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		are sent to the Holder with the SD-JWT in the format defined in
	Section 4. When presenting an SD-JWT to a Verifier, the Holder only		Section 4. When presenting an SD-JWT to a Verifier, the Holder only
	skipping to change at page 8, line 26 ¶		skipping to change at line 354 ¶
	To disclose to a Verifier a subset of the SD-JWT claim values, a		To disclose to a Verifier a subset of the SD-JWT claim values, a
	Holder sends only the Disclosures of those selectively released		Holder sends only the Disclosures of those selectively released
	claims to the Verifier as part of the SD-JWT.		claims to the Verifier as part of the SD-JWT.
	3.3. Optional Key Binding		3.3. Optional Key Binding
	Key Binding is an optional feature. When Key Binding is required by		Key Binding is an optional feature. When Key Binding is required by
	the use case, the SD-JWT MUST contain information about the key		the use case, the SD-JWT MUST contain information about the key
	material controlled by the Holder.		material controlled by the Holder.
	| Note: How the public key is included in SD-JWT is described in		| Note: How the public key is included in SD-JWT is described in
	| Section 4.1.2.		| Section 4.1.2.
	When a Verifier requires Key Binding, the Holder presents an SD-		When a Verifier requires Key Binding, the Holder presents an SD-
	JWT+KB, consisting of an SD-JWT as well as a Key Binding JWT tied to		JWT+KB, consisting of an SD-JWT as well as a Key Binding JWT tied to
	that SD-JWT. The Key Binding JWT encodes a signature by the Holder's		that SD-JWT. The Key Binding JWT encodes a signature by the Holder's
	private key over		private key over
	* a hash of the SD-JWT,		* a hash of the SD-JWT,
	* a nonce to ensure the freshness of the signature, and		* a nonce to ensure the freshness of the signature, and
	* an audience value to indicate the intended Verifier for the		* an audience value to indicate the intended Verifier for the
	document.		document.
	Details of the format of Key Binding JWTs are described in		Details of the format of Key Binding JWTs are described in
	Section 4.3.		Section 4.3.
	3.4. Verification		3.4. Verification
	At a high level, the Verifier		At a high level, the Verifier
	skipping to change at page 9, line 15 ¶		skipping to change at line 395 ¶
	* calculates the digests over the Holder-Selected Disclosures and		* calculates the digests over the Holder-Selected Disclosures and
	verifies that each digest is contained in the SD-JWT.		verifies that each digest is contained in the SD-JWT.
	The detailed algorithm is described in Section 7.3.		The detailed algorithm is described in Section 7.3.
	4. SD-JWT and SD-JWT+KB Data Formats		4. SD-JWT and SD-JWT+KB Data Formats
	An SD-JWT is composed of		An SD-JWT is composed of
	* an Issuer-signed JWT, and		* an Issuer-signed JWT, and
	* zero or more Disclosures.		* zero or more Disclosures.
	An SD-JWT+KB is composed of		An SD-JWT+KB is composed of
	* an SD-JWT (i.e., an Issuer-signed JWT and zero or more		* an SD-JWT (i.e., an Issuer-signed JWT and zero or more
	Disclosures), and		Disclosures), and
	* a Key Binding JWT.		* a Key Binding JWT.
	The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained		The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained
	in Section 4.1, Section 4.2, and Section 4.3 respectively.		in Sections 4.1, 4.2, and 4.3, respectively.
	The compact serialized format for the SD-JWT is the concatenation of		The compact serialized format for the SD-JWT is the concatenation of
	each part delineated with a single tilde ('~') character as follows:		each part delineated with a single tilde ('~') character as follows:
	<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~		<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~
	The order of the concatenated parts MUST be the Issuer-signed JWT, a		The order of the concatenated parts MUST be the Issuer-signed JWT, a
	tilde character, zero or more Disclosures each followed by a tilde		tilde character, zero or more Disclosures each followed by a tilde
	character, and lastly the optional Key Binding JWT. In the case that		character, and lastly the optional Key Binding JWT. In the case that
	there is no Key Binding JWT, the last element MUST be an empty string		there is no Key Binding JWT, the last element MUST be an empty string
	skipping to change at page 10, line 48 ¶		skipping to change at line 479 ¶
	ALPHA = %x41-5A / %x61-7A ; A-Z / a-z		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
	4.1. Issuer-signed JWT		4.1. Issuer-Signed JWT
	An SD-JWT has a JWT component that MUST be signed using the Issuer's		An SD-JWT has a JWT component that MUST be signed using the Issuer's
	private key. It MUST NOT use the none algorithm.		private key. It MUST NOT use the none algorithm.
	The payload of an SD-JWT is a JSON object according to the following		The payload of an SD-JWT is a JSON object according to the following
	rules:		rules:
	1. The payload MAY contain the _sd_alg key described in		1. The payload MAY contain the _sd_alg key described in
	Section 4.1.1.		Section 4.1.1.
	2. The payload MAY contain one or more digests of Disclosures to		2. The payload MAY contain one or more digests of Disclosures to
	enable selective disclosure of the respective claims, created and		enable selective disclosure of the respective claims, created and
	formatted as described in Section 4.2.		formatted as described in Section 4.2.
	3. The payload MAY contain one or more decoy digests to obscure the		3. The payload MAY contain one or more decoy digests to obscure the
	actual number of claims in the SD-JWT, created and formatted as		actual number of claims in the SD-JWT, created and formatted as
	described in Section 4.2.5.		described in Section 4.2.5.
	4. The payload MAY contain one or more permanently disclosed claims.		4. The payload MAY contain one or more permanently disclosed claims.
	5. The payload MAY contain the Holder's public key(s) or		5. The payload MAY contain the Holder's public key(s) or
	reference(s) thereto, as explained in Section 4.1.2.		reference(s) thereto, as explained in Section 4.1.2.
	6. The payload MAY contain further claims such as iss, iat, etc. as		6. The payload MAY contain further claims such as iss, iat, etc. as
	defined or required by the application using SD-JWTs.		defined or required by the application using SD-JWTs.
	7. The payload MUST NOT contain the claims _sd or ... except for the		7. The payload MUST NOT contain the claims _sd or ... except for the
	purpose of conveying digests as described in Section 4.2.4.1 and		purpose of conveying digests as described in Sections 4.2.4.1 and
	Section 4.2.4.2 respectively below.		4.2.4.2, respectively.
	The same digest value MUST NOT appear more than once in the SD-JWT.		The same digest value MUST NOT appear more than once in the SD-JWT.
	Application and profiles of SD-JWT SHOULD be explicitly typed. See		Application and profiles of SD-JWT SHOULD be explicitly typed. See
	Section 9.11 for more details.		Section 9.11 for more details.
	It is the Issuer who decides which claims are selectively disclosable		It is the Issuer who decides which claims are selectively disclosable
	by the Holder and which are not. Claims MAY be included as plaintext		by the Holder and which are not. Claims MAY be included as plaintext
	as well, e.g., if hiding the particular claims from the Verifier is		as well, e.g., if hiding the particular claims from the Verifier is
	not required in the intended use case. See Section 9.7 for		not required in the intended use case. See Section 9.7 for
	skipping to change at page 12, line 7 ¶		skipping to change at line 536 ¶
	The claim _sd_alg indicates the hash algorithm used by the Issuer to		The claim _sd_alg indicates the hash algorithm used by the Issuer to
	generate the digests as described in Section 4.2. When used, this		generate the digests as described in Section 4.2. When used, this
	claim MUST appear at the top level of the SD-JWT payload. It MUST		claim MUST appear at the top level of the SD-JWT payload. It MUST
	NOT be used in any object nested within the payload. If the _sd_alg		NOT be used in any object nested within the payload. If the _sd_alg
	claim is not present at the top level, a default value of sha-256		claim is not present at the top level, a default value of sha-256
	MUST be used.		MUST be used.
	This claim value is a case-sensitive string with the hash algorithm		This claim value is a case-sensitive string with the hash algorithm
	identifier. The hash algorithm identifier MUST be a hash algorithm		identifier. The hash algorithm identifier MUST be a hash algorithm
	value from the "Hash Name String" column in the IANA "Named		value from the "Hash Name String" column in the "Named Information
	Information Hash Algorithm" registry [IANA.Hash.Algorithms] or a		Hash Algorithm Registry" [Hash.Algs] or a value defined in another
	value defined in another specification and/or profile of this		specification and/or profile of this specification.
	specification.
	To promote interoperability, implementations MUST support the sha-256		To promote interoperability, implementations MUST support the sha-256
	hash algorithm.		hash algorithm.
	See Section 9 for requirements regarding entropy of the salt, minimum		See Section 9 for requirements regarding entropy of the salt, minimum
	length of the salt, and choice of a hash algorithm.		length of the salt, and choice of a hash algorithm.
	4.1.2. Key Binding		4.1.2. Key Binding
	If the Issuer wants to enable Key Binding, it includes a public key		If the Issuer wants to enable Key Binding, it includes a public key
	associated with the Holder, or a reference thereto, using the cnf		associated with the Holder, or a reference thereto, using the cnf
	claim as defined in [RFC7800]. The jwk confirmation method, as		claim as defined in [RFC7800]. The jwk confirmation method, as
	defined in Section 3.2 of [RFC7800], is suggested for doing so,		defined in Section 3.2 of [RFC7800], is suggested for doing so,
	however, other confirmation methods can be used.		however, other confirmation methods can be used.
	| Note that, as was stated in [RFC7800], if an application needs to		| Note that, as was stated in [RFC7800], if an application needs
	| represent multiple proof-of-possession keys in the same SD-JWT,		| to represent multiple proof-of-possession keys in the same SD-
	| one way to achieve this is to use other claim names, in addition		| JWT, one way to achieve this is to use other claim names, in
	| to cnf, to hold the additional proof-of-possession key		| addition to cnf, to hold the additional proof-of-possession key
	| information.		| information.
	It is out of the scope of this document to describe how the Holder		It is outside the scope of this document to describe how the Holder
	key pair is established. For example, the Holder MAY create a key		key pair is established. For example, the Holder MAY create a key
	pair and provide a public key to the Issuer, the Issuer MAY create		pair and provide a public key to the Issuer, the Issuer MAY create
	the key pair for the Holder, or Holder and Issuer MAY use pre-		the key pair for the Holder, or Holder and Issuer MAY use pre-
	established key material.		established key material.
	| Note: The examples throughout this document use the cnf claim with		| Note: The examples throughout this document use the cnf claim
	| the jwk member to include the raw public key by value in SD-JWT.		| with the jwk member to include the raw public key by value in
			| SD-JWT.
	4.2. Disclosures		4.2. Disclosures
	Disclosures are created differently depending on whether a claim is		Disclosures are created differently depending on whether a claim is
	an object property (name/value pair) or an array element.		an object property (name/value pair) or an array element.
	* For a claim that is an object property, the Issuer creates a		* For a claim that is an object property, the Issuer creates a
	Disclosure as described in Section 4.2.1.		Disclosure as described in Section 4.2.1.
	* For a claim that is an array element, the Issuer creates a		* For a claim that is an array element, the Issuer creates a
	Disclosure as described in Section 4.2.2.		Disclosure as described in Section 4.2.2.
	4.2.1. Disclosures for Object Properties		4.2.1. Disclosures for Object Properties
	For each claim that is an object property and that is to be made		For each claim that is an object property and that is to be made
	selectively disclosable, the Issuer MUST create a Disclosure as		selectively disclosable, the Issuer MUST create a Disclosure as
	follows:		follows:
	* Create a JSON array of three elements in this order:		* Create a JSON array of three elements in the following order:
	1. A salt value. MUST be a string. See Section 9.3 for security		1. A salt value. MUST be a string. See Section 9.3 for security
	considerations. To achieve the recommended entropy of the		considerations. To achieve the recommended entropy of the
	salt, the Issuer can base64url-encode 128 bits of		salt, the Issuer can base64url-encode 128 bits of
	cryptographically secure random data, producing a string. The		cryptographically secure random data, producing a string. The
	salt value MUST be unique for each claim that is to be		salt value MUST be unique for each claim that is to be
	selectively disclosed. The Issuer MUST NOT reveal the salt		selectively disclosed. The Issuer MUST NOT reveal the salt
	value to any party other than the Holder.		value to any party other than the Holder.
	2. The claim name, or key, as it would be used in a regular JWT		2. The claim name, or key, as it would be used in a regular JWT
	payload. It MUST be a string and MUST NOT be _sd, ..., or a		payload. It MUST be a string and MUST NOT be _sd, ..., or a
	claim name existing in the object as a permanently disclosed		claim name existing in the object as a permanently disclosed
	claim.		claim.
	3. The claim value, as it would be used in a regular JWT payload.		3. 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,		The value can be of any type that is allowed in JSON,
	including numbers, strings, booleans, arrays, null, and		including numbers, strings, booleans, arrays, null, and
	objects.		objects.
	* base64url-encode the UTF-8 byte sequence of the JSON array. This		* base64url-encode the UTF-8 byte sequence of the JSON array. This
	string is the Disclosure.		string is the Disclosure.
	| Note: The order was decided based on readability considerations:		| Note: The order was decided based on readability
	| salts have a constant length within the SD-JWT, claim names would		| considerations: Salts have a constant length within the SD-JWT,
	| be around the same length all the time, and claim values would		| claim names would be around the same length all the time, and
	| vary in size, potentially being large objects.		| claim values would vary in size, potentially being large
			| objects.
	The following example illustrates the steps described above.		The following example illustrates the steps described above.
	The array is created as follows:		The array is created as follows:
	["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]		["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]
	The resulting Disclosure is: WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJm		The resultant Disclosure is:
	YW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0
			WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzI
			l0
	Note that variations in whitespace, encoding of Unicode characters,		Note that variations in whitespace, encoding of Unicode characters,
	ordering of object properties, etc., are allowed in the JSON		ordering of object properties, etc., are allowed in the JSON
	representation and no canonicalization needs to be performed before		representation and no canonicalization needs to be performed before
	base64url-encoding because the digest is calculated over the		base64url encoding because the digest is calculated over the
	base64url-encoded value itself. For example, the following strings		base64url-encoded value itself. For example, the following strings
	are all valid and encode the same claim value "Möbius":		are all valid and encode the same claim value "Möbius":
	* A different way to encode the unicode umlaut:		* A different way to encode the unicode umlaut:
	WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNX
	HUwMGY2Yml1cyJd		WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNXHUwMG
			Y2Yml1cyJd
	* No white space:		* No white space:
	WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Y
	ml1cyJd		WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Yml1cy
			Jd
	* Newline characters between elements:		* Newline characters between elements:
	WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiT
	cO2Yml1cyIKXQ		WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiTcO2Ym
			l1cyIKXQ
	However, the digest is calculated over the respective base64url-		However, the digest is calculated over the respective base64url-
	encoded value itself, which effectively signs the variation chosen by		encoded value itself, which effectively signs the variation chosen by
	the Issuer and makes it immutable in the context of the particular		the Issuer and makes it immutable in the context of the particular
	SD-JWT.		SD-JWT.
	See Appendix B for some further considerations on the Disclosure		See Appendix B for some further considerations on the Disclosure
	format approach.		format approach.
	4.2.2. Disclosures for Array Elements		4.2.2. Disclosures for Array Elements
	skipping to change at page 14, line 30 ¶		skipping to change at line 664 ¶
	See Appendix B for some further considerations on the Disclosure		See Appendix B for some further considerations on the Disclosure
	format approach.		format approach.
	4.2.2. Disclosures for Array Elements		4.2.2. Disclosures for Array Elements
	For each claim that is an array element and that is to be made		For each claim that is an array element and that is to be made
	selectively disclosable, the Issuer MUST create a Disclosure as		selectively disclosable, the Issuer MUST create a Disclosure as
	follows:		follows:
	* The array MUST contain two elements in this order:		* The array MUST contain two elements in this order:
	1. The salt value as described in Section 4.2.1.		1. The salt value as described in Section 4.2.1.
	2. The array element that is to be hidden. This value can be of		2. The array element that is to be hidden. This value can be of
	any type that is allowed in JSON, including numbers, strings,		any type that is allowed in JSON, including numbers, strings,
	booleans, arrays, and objects.		booleans, arrays, and objects.
	The Disclosure string is created by base64url-encoding the UTF-8 byte		The Disclosure string is created by base64url-encoding the UTF-8 byte
	sequence of the resulting JSON array as described in Section 4.2.1.		sequence of the resultant JSON array as described in Section 4.2.1.
	The same considerations regarding variations in the result of the		The same considerations regarding variations in the result of the
	JSON encoding apply.		JSON encoding apply.
	For example, a Disclosure for the second element of the nationalities		For example, a Disclosure for the second element of the nationalities
	array in the following JWT Claims Set:		array in the following JWT Claims Set:
	{		{
	"nationalities": ["DE", "FR", "US"]		"nationalities": ["DE", "FR", "US"]
	}		}
	could be created by first creating the following array:		could be created by first creating the following array:
	["lklxF5jMYlGTPUovMNIvCA", "FR"]		["lklxF5jMYlGTPUovMNIvCA", "FR"]
	The resulting Disclosure would be:		The resultant Disclosure would be:
	WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0		WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0
	| Note that the size of an array alone can potentially reveal
	| unintended information. The use of decoys, as described in		| Note that the size of an array alone can potentially reveal
	| Section 4.2.5, to consistently pad the size of an array can help		| unintended information. The use of decoys, as described in
	| obscure the actual number of elements present in any particular		| Section 4.2.5, to consistently pad the size of an array can
	| instance.		| help obscure the actual number of elements present in any
			| particular instance.
	4.2.3. Hashing Disclosures		4.2.3. Hashing Disclosures
	For embedding references to the Disclosures in the SD-JWT, each		For embedding references to the Disclosures in the SD-JWT, each
	Disclosure is hashed using the hash algorithm specified in the		Disclosure is hashed using the hash algorithm specified in the
	_sd_alg claim described in Section 4.1.1, or SHA-256 if no algorithm		_sd_alg claim described in Section 4.1.1, or SHA-256 if no algorithm
	is specified. The resulting digest is then included in the SD-JWT		is specified. The resultant digest is then included in the SD-JWT
	payload instead of the original claim value, as described next.		payload instead of the original claim value, as described next.
	The digest MUST be taken over the US-ASCII bytes of the base64url-		The digest MUST be taken over the US-ASCII bytes of the base64url-
	encoded value that is the Disclosure. This follows the convention in		encoded value that is the Disclosure. This follows the convention in
	JWS [RFC7515] and JWE [RFC7516]. The bytes of the digest MUST then		JWS [RFC7515] and JWE [RFC7516]. The bytes of the digest MUST then
	be base64url-encoded.		be base64url encoded.
	It is important to note that:		It is important to note that:
	* The input to the hash function MUST be the base64url-encoded		* The input to the hash function MUST be the base64url-encoded
	Disclosure, not the bytes encoded by the base64url string.		Disclosure, not the bytes encoded by the base64url string.
	* The bytes of the output of the hash function MUST be base64url-
			* The bytes of the output of the hash function MUST be base64url
	encoded, and are not the bytes making up the (sometimes used) hex		encoded, and are not the bytes making up the (sometimes used) hex
	representation of the bytes of the digest.		representation of the bytes of the digest.
	For example, the base64url-encoded SHA-256 digest of the Disclosure W		For example, the base64url-encoded SHA-256 digest of the Disclosure W
	yJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl		yJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl
	0 for the family_name claim from Section 4.2.1 above is		0 for the family_name claim from Section 4.2.1 above is
	X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0.		X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0.
	4.2.4. Embedding Disclosure Digests in SD-JWTs		4.2.4. Embedding Disclosure Digests in SD-JWTs
	skipping to change at page 16, line 48 ¶		skipping to change at line 780 ¶
	the same position as the original claim value in the array. For each		the same position as the original claim value in the array. For each
	digest, an object of the form {"...": "<digest>"} is added to the		digest, an object of the form {"...": "<digest>"} is added to the
	array. The key MUST always be the string ... (three dots). The		array. The key MUST always be the string ... (three dots). The
	value MUST be the digest of the Disclosure created as described in		value MUST be the digest of the Disclosure created as described in
	Section 4.2.3. There MUST NOT be any other keys in the object. Note		Section 4.2.3. There MUST NOT be any other keys in the object. Note
	that the string ... was chosen because the ellipsis character,		that the string ... was chosen because the ellipsis character,
	typically entered as three period characters, is commonly used in		typically entered as three period characters, is commonly used in
	places where content is omitted from the present context.		places where content is omitted from the present context.
	For example, using the digest of the array element Disclosure created		For example, using the digest of the array element Disclosure created
	above in Section 4.2.2, the Issuer could create the following SD-JWT		in Section 4.2.2, the Issuer could create the following SD-JWT
	payload to make the second element of the nationalities array		payload to make the second element of the nationalities array
	selectively disclosable:		selectively disclosable:
	{		{
	"nationalities":		"nationalities":
	["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}, "US"]		["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}, "US"]
	}		}
	As described in Section 7.3, Verifiers ignore all selectively		As described in Section 7.3, Verifiers ignore all selectively
	disclosable array elements for which they did not receive a		disclosable array elements for which they did not receive a
	Disclosure. In the example above, the verification process would		Disclosure. In the example above, the verification process would
	output an array with only two elements, ["DE", "US"], unless the		output an array with only two elements, ["DE", "US"], unless the
	matching Disclosure for the second element is received, in which case		matching Disclosure for the second element is received, in which case
	the output would be a three element array, ["DE", "FR", "US"].		the output would be a three-element array, ["DE", "FR", "US"].
	4.2.5. Decoy Digests		4.2.5. Decoy Digests
	An Issuer MAY add additional digests to the SD-JWT payload that are		An Issuer MAY add additional digests to the SD-JWT payload that are
	not associated with any claim. The purpose of such "decoy" digests		not associated with any claim. The purpose of such "decoy" digests
	is to make it more difficult for an adversarial Verifier to see the		is to make it more difficult for an adversarial Verifier to see the
	original number of claims or array elements contained in the SD-JWT.		original number of claims or array elements contained in the SD-JWT.
	Decoy digests MAY be added both to the _sd array for objects as well		Decoy digests MAY be added both to the _sd array for objects as well
	as in arrays.		as in arrays.
	It is RECOMMENDED to create the decoy digests by hashing over a		It is RECOMMENDED to create the decoy digests by hashing over a
	cryptographically secure random number. The bytes of the digest MUST		cryptographically secure random number. The bytes of the digest MUST
	then be base64url-encoded as above. The same digest function as for		then be base64url encoded as above. The same digest function as for
	the Disclosures MUST be used.		the Disclosures MUST be used.
	For decoy digests, no Disclosure is sent to the Holder, i.e., the		For decoy digests, no Disclosure is sent to the Holder, i.e., the
	Holder will see digests that do not correspond to any Disclosure.		Holder will see digests that do not correspond to any Disclosure.
	See Section 10.4 for additional privacy considerations.		See Section 10.4 for additional privacy considerations.
	To ensure readability and replicability, the examples in this		To ensure readability and replicability, the examples in this
	specification do not contain decoy digests unless explicitly stated.		specification do not contain decoy digests unless explicitly stated.
	For an example with decoy digests, see Appendix A.1.		For an example with decoy digests, see Appendix A.1.
	skipping to change at page 18, line 4 ¶		skipping to change at line 829 ¶
	The algorithms above are compatible with "recursive disclosures", in		The algorithms above are compatible with "recursive disclosures", in
	which one selectively disclosed field reveals the existence of more		which one selectively disclosed field reveals the existence of more
	selectively disclosable fields. For example, consider the following		selectively disclosable fields. For example, consider the following
	JSON structure:		JSON structure:
	{		{
	"family_name": "Möbius",		"family_name": "Möbius",
	"nationalities": ["DE", "FR", "UK"]		"nationalities": ["DE", "FR", "UK"]
	}		}
	When the Holder has multiple nationalities, the issuer may wish to
			When the Holder has multiple nationalities, the Issuer may wish to
	conceal the presence of any statement regarding nationalities while		conceal the presence of any statement regarding nationalities while
	also allowing the holder to reveal each of those nationalities		also allowing the holder to reveal each of those nationalities
	individually. This can be accomplished by first making the entries		individually. This can be accomplished by first making the entries
	within the "nationalities" array selectively disclosable, and then		within the "nationalities" array selectively disclosable, and then
	making the whole "nationalities" field selectively disclosable.		making the whole "nationalities" field selectively disclosable.
	The following shows each of the entries within the "nationalities"		The following shows each of the entries within the "nationalities"
	array being made selectively disclosable:		array being made selectively disclosable:
	{		{
	skipping to change at page 19, line 31 ¶		skipping to change at line 905 ¶
	4.3. Key Binding JWT		4.3. Key Binding JWT
	This section defines the Key Binding JWT, which encodes a signature		This section defines the Key Binding JWT, which encodes a signature
	over an SD-JWT by the Holder's private key.		over an SD-JWT by the Holder's private key.
	The Key Binding JWT MUST be a JWT according to [RFC7519], and it MUST		The Key Binding JWT MUST be a JWT according to [RFC7519], and it MUST
	contain the following elements:		contain the following elements:
	* in the JOSE header,		* in the JOSE header,
	- typ: REQUIRED. MUST be kb+jwt, which explicitly types the Key		- typ: REQUIRED. MUST be kb+jwt, which explicitly types the Key
	Binding JWT as recommended in Section 3.11 of [RFC8725].		Binding JWT as recommended in Section 3.11 of [RFC8725].
	- alg: REQUIRED. A digital signature algorithm identifier such		- alg: REQUIRED. A digital signature algorithm identifier such
	as per IANA "JSON Web Signature and Encryption Algorithms"		as per the IANA "JSON Web Signature and Encryption Algorithms"
	registry. It MUST NOT be none.		registry. It MUST NOT be none.
	* in the JWT payload,		* in the JWT payload,
	- iat: REQUIRED. The value of this claim MUST be the time at		- iat: REQUIRED. The value of this claim MUST be the time at
	which the Key Binding JWT was issued using the syntax defined		which the Key Binding JWT was issued using the syntax defined
	in [RFC7519].		in [RFC7519].
	- aud: REQUIRED. The value MUST be a single string that		- aud: REQUIRED. The value MUST be a single string that
	identifies the intended receiver of the Key Binding JWT. How		identifies the intended receiver of the Key Binding JWT. How
	the value is represented is up to the protocol used and out of		the value is represented is up to the protocol used and is out
	scope of this specification.		of scope for this specification.
	- nonce: REQUIRED. Ensures the freshness of the signature or its		- nonce: REQUIRED. Ensures the freshness of the signature or its
	binding to the given transaction. The value type of this claim		binding to the given transaction. The value type of this claim
	MUST be a string. How this value is obtained is up to the		MUST be a string. How this value is obtained is up to the
	protocol used and out of scope of this specification.		protocol used and is out of scope for this specification.
	- sd_hash: REQUIRED. The base64url-encoded hash value over the		- sd_hash: REQUIRED. The base64url-encoded hash value over the
	Issuer-signed JWT and the selected Disclosures as defined		Issuer-signed JWT and the selected Disclosures as defined
	below.		below.
	The general extensibility model of JWT means that additional claims		The general extensibility model of JWT means that additional claims
	and header parameters can be added to the Key Binding JWT. However,		and header parameters can be added to the Key Binding JWT. However,
	unless there is a compelling reason, this SHOULD be avoided, as it		unless there is a compelling reason, this SHOULD be avoided, as it
	may harm interoperability and burden conceptual integrity.		may harm interoperability and burden conceptual integrity.
	4.3.1. Binding to an SD-JWT		4.3.1. Binding to an SD-JWT
	The hash value in the sd_hash claim binds the KB-JWT to the specific		The hash value in the sd_hash claim binds the KB-JWT to the specific
	SD-JWT. The sd_hash value MUST be taken over the US-ASCII bytes of		SD-JWT. The sd_hash value MUST be taken over the US-ASCII bytes of
	the encoded SD-JWT, i.e., the Issuer-signed JWT, a tilde character,		the encoded SD-JWT, i.e., the Issuer-signed JWT, a tilde character,
	and zero or more Disclosures selected for presentation to the		and zero or more Disclosures selected for presentation to the
	Verifier, each followed by a tilde character:		Verifier, each followed by a tilde character:
	<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~		<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~
	The bytes of the digest MUST then be base64url-encoded.		The bytes of the digest MUST then be base64url encoded.
	The same hash algorithm as for the Disclosures MUST be used (defined		The same hash algorithm as for the Disclosures MUST be used (defined
	by the _sd_alg element in the Issuer-signed JWT or the default value,		by the _sd_alg element in the Issuer-signed JWT or the default value,
	as defined in Section 4.1.1).		as defined in Section 4.1.1).
	4.3.2. Validating the Key Binding JWT		4.3.2. Validating the Key Binding JWT
	Whether to require Key Binding is up to the Verifier's policy, based		Whether to require Key Binding is up to the Verifier's policy, based
	on the set of trust requirements such as trust frameworks it belongs		on the set of trust requirements (such as trust frameworks) it
	to. See Section 9.5 for security considerations.		belongs to. See Section 9.5 for security considerations.
	If the Verifier requires Key Binding, the Verifier MUST ensure that		If the Verifier requires Key Binding, the Verifier MUST ensure that
	the key with which it validates the signature on the Key Binding JWT		the key with which it validates the signature on the Key Binding JWT
	is the key specified in the SD-JWT as the Holder's public key. For		is the key specified in the SD-JWT as the Holder's public key. For
	example, if the SD-JWT contains a cnf value with a jwk member, the		example, if the SD-JWT contains a cnf value with a jwk member, the
	Verifier would parse the provided JWK and use it to verify the Key		Verifier would parse the provided JWK and use it to verify the Key
	Binding JWT.		Binding JWT.
	Details of the Validation process are defined in Section 7.3.		Details of the validation process are defined in Section 7.3.
	5. Example SD-JWT		5. Example SD-JWT
	In this example, a simple SD-JWT is demonstrated. This example is		In this example, a simple SD-JWT is demonstrated. This example is
	split into issuance and presentation.		split into issuance and presentation.
	| Note: Throughout the examples in this document, line breaks had to		| Note: Throughout the examples in this document, line breaks
	| be added to JSON strings and base64-encoded strings to adhere to		| were added to JSON strings and base64-encoded strings to adhere
	| the 72-character limit for lines in RFCs and for readability.		| to the line-length limit in RFCs and for readability. JSON
	| JSON does not allow line breaks within strings.		| does not allow line breaks within strings.
	5.1. Issuance		5.1. Issuance
	The following data about the user comprises the input JWT Claims Set		The following data about the user comprises the input JWT Claims Set
	used by the Issuer:		used by the Issuer:
	{		{
	"sub": "user_42",		"sub": "user_42",
	"given_name": "John",		"given_name": "John",
	"family_name": "Doe",		"family_name": "Doe",
	skipping to change at page 22, line 44 ¶		skipping to change at line 1061 ¶
	"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"		"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
	}		}
	}		}
	}		}
	The respective Disclosures, created by the Issuer, are listed below.		The respective Disclosures, created by the Issuer, are listed below.
	In the text below and in other locations in this specification, the		In the text below and in other locations in this specification, the
	label "SHA-256 Hash:" is used as a shorthand for the label		label "SHA-256 Hash:" is used as a shorthand for the label
	"Base64url-Encoded SHA-256 Hash:".		"Base64url-Encoded SHA-256 Hash:".
	*Claim given_name*:		* Claim given_name:
	* SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4		- SHA-256 Hash:
	* Disclosure:
	WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o		jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4
	biJd
	* Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]		- Disclosure:
			WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJ
			d
			- Contents:
			["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]
	*Claim family_name*:		*Claim family_name*:
	* SHA-256 Hash: TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo		* SHA-256 Hash:
			TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo
	* Disclosure:		* Disclosure:
	WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRv
	ZSJd		WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJd
	* Contents: ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]
			* Contents:
			["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]
	*Claim email*:		*Claim email*:
	* SHA-256 Hash: JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE		* SHA-256 Hash:
			JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE
	* Disclosure:		* Disclosure:
	WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VA
	ZXhhbXBsZS5jb20iXQ		WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VAZXhhbX
	* Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "email",		BsZS5jb20iXQ
	"johndoe@example.com"]
			* Contents:
			["6Ij7tM-a5iVPGboS5tmvVA", "email", "johndoe@example.com"]
	*Claim phone_number*:		*Claim phone_number*:
	* SHA-256 Hash: PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI		* SHA-256 Hash:
			PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI
	* Disclosure:		* Disclosure:
	WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIr
	MS0yMDItNTU1LTAxMDEiXQ		WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0yMD
	* Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number",		ItNTU1LTAxMDEiXQ
	"+1-202-555-0101"]
			* Contents:
			["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number", "+1-202-555-0101"]
	*Claim phone_number_verified*:		*Claim phone_number_verified*:
	* SHA-256 Hash: XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM		* SHA-256 Hash:
			XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM
	* Disclosure:		* Disclosure:
	WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJp
	ZmllZCIsIHRydWVd		WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmllZC
	* Contents: ["Qg_O64zqAxe412a108iroA", "phone_number_verified",		IsIHRydWVd
	true]
			* Contents:
			["Qg_O64zqAxe412a108iroA", "phone_number_verified", true]
	*Claim address*:		*Claim address*:
	* SHA-256 Hash: XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE		* SHA-256 Hash:
			XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE
	* Disclosure:		* Disclosure:
	WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVl
	dF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRv		WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZG
	d24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0		RyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVn
	* Contents: ["AJx-095VPrpTtN4QMOqROA", "address", {"street_address":		aW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0
	"123 Main St", "locality": "Anytown", "region": "Anystate",
	"country": "US"}]		* Contents:
			["AJx-095VPrpTtN4QMOqROA", "address", {"street_address": "123 Main
			St", "locality": "Anytown", "region": "Anystate", "country":
			"US"}]
	*Claim birthdate*:		*Claim birthdate*:
	* SHA-256 Hash: gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM		* SHA-256 Hash:
			gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM
	* Disclosure:		* Disclosure:
	WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQw
	LTAxLTAxIl0		WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLT
	* Contents: ["Pc33JM2LchcU_lHggv_ufQ", "birthdate", "1940-01-01"]		AxIl0
			* Contents:
			["Pc33JM2LchcU_lHggv_ufQ", "birthdate", "1940-01-01"]
	*Claim updated_at*:		*Claim updated_at*:
	* SHA-256 Hash: CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI		* SHA-256 Hash:
			CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI
	* Disclosure:		* Disclosure:
	WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcw
	MDAwMDAwXQ		WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDAwMD
	* Contents: ["G02NSrQfjFXQ7Io09syajA", "updated_at", 1570000000]		AwXQ
			* Contents:
			["G02NSrQfjFXQ7Io09syajA", "updated_at", 1570000000]
	*Array Entry*:		*Array Entry*:
	* SHA-256 Hash: pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo		* SHA-256 Hash:
			pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo
	* Disclosure:		* Disclosure:
	WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0		WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0
	* Contents: ["lklxF5jMYlGTPUovMNIvCA", "US"]
			* Contents:
			["lklxF5jMYlGTPUovMNIvCA", "US"]
	*Array Entry*:		*Array Entry*:
	* SHA-256 Hash: 7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0		* SHA-256 Hash:
			7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0
	* Disclosure:		* Disclosure:
	WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0		WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0
	* Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "DE"]
			* Contents:
			["nPuoQnkRFq3BIeAm7AnXFA", "DE"]
	The payload is then signed by the Issuer to create the following		The payload is then signed by the Issuer to create the following
	Issuer-signed JWT:		Issuer-signed JWT:
	eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb		eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
	IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ		IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
	akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL		akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
	dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1		dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
	SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB		SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
	TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2		TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
	skipping to change at page 27, line 36 ¶		skipping to change at line 1351 ¶
	"country": "US"		"country": "US"
	},		},
	"given_name": "John"		"given_name": "John"
	}		}
	6. Considerations on Nested Data in SD-JWTs		6. Considerations on Nested Data in SD-JWTs
	Being JSON, an object in an SD-JWT payload MAY contain name/value		Being JSON, an object in an SD-JWT payload MAY contain name/value
	pairs where the value is another object or objects MAY be elements in		pairs where the value is another object or objects MAY be elements in
	arrays. In SD-JWT, the Issuer decides for each claim individually,		arrays. In SD-JWT, the Issuer decides for each claim individually,
	on each level of the JSON, whether the claim should be selectively		on each level of the JSON, whether or not the claim should be
	disclosable or not. This choice can be made on each level		selectively disclosable. This choice can be made on each level
	independent of whether keys higher in the hierarchy are selectively		independent of whether keys higher in the hierarchy are selectively
	disclosable.		disclosable.
	From this it follows that the _sd key containing digests MAY appear		From this it follows that the _sd key containing digests MAY appear
	multiple times in an SD-JWT, and likewise, there MAY be multiple		multiple times in an SD-JWT, and likewise, there MAY be multiple
	arrays within the hierarchy with each having selectively disclosable		arrays within the hierarchy with each having selectively disclosable
	elements. Digests of selectively disclosable claims MAY even appear		elements. Digests of selectively disclosable claims MAY even appear
	within other Disclosures.		within other Disclosures.
	The following examples illustrate some of the options an Issuer has.		The following examples illustrate some of the options an Issuer has.
	It is up to the Issuer to decide which structure to use, depending		It is up to the Issuer to decide which structure to use, depending
	on, for example, the expected use cases for the SD-JWT, requirements		on, for example, the expected use cases for the SD-JWT, requirements
	for privacy, size considerations, or operating environment		for privacy, size considerations, or operating environment
	requirements. For more examples with nested structures, see		requirements. For more examples with nested structures, see
	Appendix A.1 and Appendix A.2.		Appendices A.1 and A.2.
	The following input JWT Claims Set is used as an example throughout		The following input JWT Claims Set is used as an example throughout
	this section:		this section:
	{		{
	"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"
	}		}
	}		}
	| Note: The following examples of the structures are non-normative		| Note: The following examples of the structures are non-
	| and are not intended to represent all possible options. They are		| normative and are not intended to represent all possible
	| also not meant to define or restrict how address can be		| options. They are also not meant to define or restrict how
	| represented in an SD-JWT.		| address can be represented in an SD-JWT.
	6.1. Example: Flat SD-JWT		6.1. Example: Flat SD-JWT
	The Issuer can decide to treat the address claim as a block that can		The Issuer can decide to treat the address claim as a block that can
	either be disclosed completely or not at all. The following example		either be disclosed completely or not at all. The following example
	shows that in this case, the entire address claim is treated as an		shows that in this case, the entire address claim is treated as an
	object in the Disclosure.		object in the Disclosure.
	{		{
	"_sd": [		"_sd": [
	skipping to change at page 28, line 46 ¶		skipping to change at line 1410 ¶
	"exp": 1883000000,		"exp": 1883000000,
	"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",		"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
	"_sd_alg": "sha-256"		"_sd_alg": "sha-256"
	}		}
	The Issuer would create the following Disclosure referenced by the		The Issuer would create the following Disclosure referenced by the
	one hash in the SD-JWT:		one hash in the SD-JWT:
	*Claim address*:		*Claim address*:
	* SHA-256 Hash: fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do		* SHA-256 Hash:
			fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do
	* Disclosure:		* Disclosure:
	WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVl
	dF9hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1
	bHBmb3J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRy
	eSI6ICJERSJ9XQ
	* Contents: ["2GLC42sKQveCfGfryNRN9w", "address", {"street_address":		WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVldF9hZG
	"Schulstr. 12", "locality": "Schulpforta", "region":		RyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1bHBmb3J0YSIs
	"Sachsen-Anhalt", "country": "DE"}]		ICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRyeSI6ICJERSJ9XQ
			* Contents:
			["2GLC42sKQveCfGfryNRN9w", "address", {"street_address":
			"Schulstr. 12", "locality": "Schulpforta", "region": "Sachsen-
			Anhalt", "country": "DE"}]
	6.2. Example: Structured SD-JWT		6.2. Example: Structured SD-JWT
	The Issuer may instead decide to make the address claim contents		The Issuer may instead decide to make the address claim contents
	selectively disclosable individually:		selectively disclosable individually:
	{		{
	"iss": "https://issuer.example.com",		"iss": "https://issuer.example.com",
	"iat": 1683000000,		"iat": 1683000000,
	"exp": 1883000000,		"exp": 1883000000,
	skipping to change at page 29, line 35 ¶		skipping to change at line 1452 ¶
	]		]
	},		},
	"_sd_alg": "sha-256"		"_sd_alg": "sha-256"
	}		}
	In this case, the Issuer would use the following data in the		In this case, the Issuer would use the following data in the
	Disclosures for the address sub-claims:		Disclosures for the address sub-claims:
	*Claim street_address*:		*Claim street_address*:
	* SHA-256 Hash: 9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM		* SHA-256 Hash:
			9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
	* Disclosure:		* Disclosure:
	WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwg
	IlNjaHVsc3RyLiAxMiJd		WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlNjaH
	* Contents: ["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr.		Vsc3RyLiAxMiJd
	12"]
			* Contents:
			["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]
	*Claim locality*:		*Claim locality*:
	* SHA-256 Hash: 6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0		* SHA-256 Hash:
			6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
	* Disclosure:		* Disclosure:
	WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVs
	cGZvcnRhIl0		WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZvcn
	* Contents: ["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]		RhIl0
			* Contents:
			["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]
	*Claim region*:		*Claim region*:
	* SHA-256 Hash: KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88		* SHA-256 Hash:
			KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
	* Disclosure:		* Disclosure:
	WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2Vu
	LUFuaGFsdCJd		WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFuaG
	* Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]		FsdCJd
			* Contents:
			["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]
	*Claim country*:		*Claim country*:
	* SHA-256 Hash: WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM		* SHA-256 Hash:
			WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
	* Disclosure:		* Disclosure:
	WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ		WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
	* Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]
			* Contents:
			["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]
	The Issuer may also make one sub-claim of address permanently		The Issuer may also make one sub-claim of address permanently
	disclosed and hide only the other sub-claims:		disclosed and hide only the other sub-claims:
	{		{
	"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": {
	skipping to change at page 31, line 16 ¶		skipping to change at line 1548 ¶
	"_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"
	}		}
	The Issuer creates Disclosures first for the sub-claims and then		The Issuer first creates Disclosures for the sub-claims and then
	includes their digests in the Disclosure for the address claim:		includes their digests in the Disclosure for the address claim:
	*Claim street_address*:		*Claim street_address*:
	* SHA-256 Hash: 9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM		* SHA-256 Hash:
			9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
	* Disclosure:		* Disclosure:
	WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwg
	IlNjaHVsc3RyLiAxMiJd		WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlNjaH
	* Contents: ["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr.		Vsc3RyLiAxMiJd
	12"]
			* Contents:
			["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]
	*Claim locality*:		*Claim locality*:
	* SHA-256 Hash: 6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0		* SHA-256 Hash:
			6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
	* Disclosure:		* Disclosure:
	WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVs
	cGZvcnRhIl0		WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZvcn
	* Contents: ["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]		RhIl0
			* Contents:
			["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]
	*Claim region*:		*Claim region*:
	* SHA-256 Hash: KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88		* SHA-256 Hash:
			KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
	* Disclosure:		* Disclosure:
	WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2Vu
	LUFuaGFsdCJd		WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFuaG
	* Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]		FsdCJd
			* Contents:
			["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]
	*Claim country*:		*Claim country*:
	* SHA-256 Hash: WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM		* SHA-256 Hash:
			WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
	* Disclosure:		* Disclosure:
	WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ		WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
	* Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]
			* Contents:
			["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]
	*Claim address*:		*Claim address*:
	* SHA-256 Hash: HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg		* SHA-256 Hash:
			HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg
	* Disclosure:		* Disclosure:
	WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6
	IFsiNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVk		WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiNn
	MCIsICI5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3Nmtt		ZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCIsICI5Z2pW
	WXlNIiwgIktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEy		dVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgIktVUkRQaD
	TjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8y		RaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAiV045cjlkQ0JK
	cm8yamZYTSJdfV0		OEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8ycm8yamZYTSJdfV0
	* Contents: ["Qg_O64zqAxe412a108iroA", "address", {"_sd":
	["6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",		* Contents:
	"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
	"KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88",		["Qg_O64zqAxe412a108iroA", "address", {"_sd": ["6vh9bq-
			zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
			"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "KURDPh4ZC19-3tiz-
			Df39V8eidy1oV3a3H1Da2N0g88",
	"WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]		"WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]
	7. Verification and Processing		7. Verification and Processing
	7.1. Verification of the SD-JWT		7.1. Verification of the SD-JWT
	Upon receiving an SD-JWT, either directly or as a component of an SD-		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:		JWT+KB, a Holder or Verifier needs to ensure that:
	* the Issuer-signed JWT is valid, and		* the Issuer-signed JWT is valid, and
	* all Disclosures are valid and correspond to a respective digest		* all Disclosures are valid and correspond to a respective digest
	value in the Issuer-signed JWT (directly in the payload or		value in the Issuer-signed JWT (directly in the payload or
	recursively included in the contents of other Disclosures).		recursively included in the contents of other Disclosures).
	The Holder or the Verifier MUST perform the following checks when		The Holder or the Verifier MUST perform the following checks when
	receiving an SD-JWT to validate the SD-JWT and extract the payload:		receiving an SD-JWT to validate the SD-JWT and extract the payload:
	1. Separate the SD-JWT into the Issuer-signed JWT and the		1. Separate the SD-JWT into the Issuer-signed JWT and the
	Disclosures (if any).		Disclosures (if any).
	2. Validate the Issuer-signed JWT:		2. Validate the Issuer-signed JWT:
	1. Ensure that a signing algorithm was used that was deemed
	secure for the application. Refer to [RFC8725], Sections 3.1		a. Ensure that the used signing algorithm was deemed secure for
	and 3.2 for details. The none algorithm MUST NOT be		the application. Refer to [RFC8725], Sections 3.1 and 3.2
	accepted.		for details. The none algorithm MUST NOT be accepted.
	2. Validate the signature over the Issuer-signed JWT per
			b. Validate the signature over the Issuer-signed JWT per
	Section 5.2 of [RFC7515].		Section 5.2 of [RFC7515].
	3. Validate the Issuer and that the signing key belongs to this
			c. Validate the Issuer and that the signing key belongs to this
	Issuer.		Issuer.
	4. Check that the _sd_alg claim value is understood and the hash
			d. Check that the _sd_alg claim value is understood and the hash
	algorithm is deemed secure according to the Holder or		algorithm is deemed secure according to the Holder or
	Verifier's policy (see Section 4.1.1).		Verifier's policy (see Section 4.1.1).
	3. Process the Disclosures and embedded digests in the Issuer-signed		3. Process the Disclosures and embedded digests in the Issuer-signed
	JWT as follows:		JWT as follows:
	1. For each Disclosure provided:
	1. Calculate the digest over the base64url-encoded string as		a. For each Disclosure provided:
			i. Calculate the digest over the base64url-encoded string as
	described in Section 4.2.3.		described in Section 4.2.3.
	2. (*) Identify all embedded digests in the Issuer-signed JWT as		b. (*) Identify all embedded digests in the Issuer-signed JWT as
	follows:		follows:
	1. Find all objects having an _sd key that refers to an
	array of strings.		i. Find all objects having an _sd key that refers to an
	2. Find all array elements that are objects with one key,		array of strings.
	that key being ... and referring to a string.
	3. (**) For each embedded digest found in the previous step:		ii. Find all array elements that are objects with one key,
	1. Compare the value with the digests calculated previously		that key being ... and referring to a string.
	and find the matching Disclosure. If no such Disclosure
	can be found, the digest MUST be ignored.		c. (**) For each embedded digest found in the previous step:
	2. If the digest was found in an object's _sd key:
	1. If the contents of the respective Disclosure is not a		i. Compare the value with the digests calculated
	JSON array of three elements (salt, claim name, claim		previously and find the matching Disclosure. If no
	value), the SD-JWT MUST be rejected.		such Disclosure can be found, the digest MUST be
	2. If the claim name is _sd or ..., the SD-JWT MUST be		ignored.
	rejected.
	3. If the claim name already exists at the level of the		ii. If the digest was found in an object's _sd key:
	_sd key, the SD-JWT MUST be rejected.
	4. Insert, at the level of the _sd key, a new claim		1. If the contents of the respective Disclosure is not
	using the claim name and claim value from the		a JSON array of three elements (salt, claim name,
	Disclosure.		claim value), the SD-JWT MUST be rejected.
	5. Recursively process the value using the steps
	described in (*) and (**).		2. If the claim name is _sd or ..., the SD-JWT MUST be
	3. If the digest was found in an array element:		rejected.
	1. If the contents of the respective Disclosure is not a
	JSON array of two elements (salt, value), the SD-JWT		3. If the claim name already exists at the level of
	MUST be rejected.		the _sd key, the SD-JWT MUST be rejected.
	2. Replace the array element with the value from the
	Disclosure.		4. Insert, at the level of the _sd key, a new claim
	3. Recursively process the value using the steps		using the claim name and claim value from the
	described in (*) and (**).		Disclosure.
	4. Remove all array elements for which the digest was not found
			5. Recursively process the value using the steps
			described in (*) and (**).
			iii. If the digest was found in an array element:
			1. If the contents of the respective Disclosure is not
			a JSON array of two elements (salt, value), the SD-
			JWT MUST be rejected.
			2. Replace the array element with the value from the
			Disclosure.
			3. Recursively process the value using the steps
			described in (*) and (**).
			d. Remove all array elements for which the digest was not found
	in the previous step.		in the previous step.
	5. Remove all _sd keys and their contents from the Issuer-signed
			e. Remove all _sd keys and their contents from the Issuer-signed
	JWT payload. If this results in an object with no		JWT payload. If this results in an object with no
	properties, it should be represented as an empty object {}.		properties, it should be represented as an empty object {}.
	6. Remove the claim _sd_alg from the SD-JWT payload.
			f. Remove the claim _sd_alg from the SD-JWT payload.
	4. If any digest value is encountered more than once in the Issuer-		4. If any digest value is encountered more than once in the Issuer-
	signed JWT payload (directly or recursively via other		signed JWT payload (directly or recursively via other
	Disclosures), the SD-JWT MUST be rejected.		Disclosures), the SD-JWT MUST be rejected.
	5. If any Disclosure was not referenced by digest value in the		5. If any Disclosure was not referenced by digest value in the
	Issuer-signed JWT (directly or recursively via other		Issuer-signed JWT (directly or recursively via other
	Disclosures), the SD-JWT MUST be rejected.		Disclosures), the SD-JWT MUST be rejected.
	6. Check that the SD-JWT is valid using claims such as nbf, exp, and		6. Check that the SD-JWT is valid using claims such as nbf, exp, and
	aud in the processed payload, if present. If a required		aud in the processed payload, if present. If a required
	validity-controlling claim is missing (see Section 9.7), the SD-		validity-controlling claim is missing (see Section 9.7), the SD-
	JWT MUST be rejected.		JWT MUST be rejected.
	If any step fails, the SD-JWT is not valid, and processing MUST be		If any step fails, the SD-JWT is not valid, and processing MUST be
	aborted. Otherwise, the JSON document resulting from the preceding		aborted. Otherwise, the JSON document resulting from the preceding
	processing and verification steps, herein referred to as the		processing and verification steps, herein referred to as the
	Processed SD-JWT Payload, can be made available to the application to		"Processed SD-JWT Payload", can be made available to the application
	be used for its intended purpose.		to be used for its intended purpose.
	| Note that these processing steps do not yield any guarantees to		| Note that these processing steps do not yield any guarantees to
	| the Holder about having received a complete set of Disclosures.		| the Holder about having received a complete set of Disclosures.
	| That is, for some digest values in the Issuer-signed JWT (which		| That is, for some digest values in the Issuer-signed JWT (which
	| are not decoy digests) there may be no corresponding Disclosures,		| are not decoy digests), there may be no corresponding
	| for example, if the message from the Issuer was truncated. It is		| Disclosures, for example, if the message from the Issuer was
	| up to the Holder how to maintain the mapping between the		| truncated. It is up to the Holder how to maintain the mapping
	| Disclosures and the plaintext claim values to be able to display		| between the Disclosures and the plaintext claim values to be
	| them to the user when needed.		| able to display them to the user when needed.
	7.2. Processing by the Holder		7.2. Processing by the Holder
	The Issuer provides the Holder with an SD-JWT, not an SD-JWT+KB. If		The Issuer provides the Holder with an SD-JWT, not an SD-JWT+KB. If
	the Holder receives an SD-JWT+KB, it MUST be rejected.		the Holder receives an SD-JWT+KB, it MUST be rejected.
	When receiving an SD-JWT, the Holder MUST do the following:		When receiving an SD-JWT, the Holder MUST do the following:
	1. Process the SD-JWT as defined in Section 7.1 to validate it and		1. Process the SD-JWT as defined in Section 7.1 to validate it and
	extract the payload.		extract the payload.
	skipping to change at page 34, line 40 ¶		skipping to change at line 1780 ¶
	(depending on the application; for example, check that any values		(depending on the application; for example, check that any values
	the Holder can check are correct).		the Holder can check are correct).
	For presentation to a Verifier, the Holder MUST perform the following		For presentation to a Verifier, the Holder MUST perform the following
	(or equivalent) steps (in addition to the checks described in		(or equivalent) steps (in addition to the checks described in
	Section 7.1 performed after receiving the SD-JWT):		Section 7.1 performed after receiving the SD-JWT):
	1. Decide which Disclosures to release to the Verifier, obtaining		1. Decide which Disclosures to release to the Verifier, obtaining
	consent if necessary (note that if and how consent is attained is		consent if necessary (note that if and how consent is attained is
	out of scope for this document).		out of scope for this document).
	2. Verify that each selected Disclosure satisfies one of the two		2. Verify that each selected Disclosure satisfies one of the two
	following conditions:		following conditions:
	1. The hash of the Disclosure is contained in the Issuer-signed
	JWT claims		a. The hash of the Disclosure is contained in the Issuer-signed
	2. The hash of the Disclosure is contained in the claim value of		JWT claims.
	another selected Disclosure
			b. The hash of the Disclosure is contained in the claim value of
			another selected Disclosure.
	3. Assemble the SD-JWT, including the Issuer-signed JWT and the		3. Assemble the SD-JWT, including the Issuer-signed JWT and the
	selected Disclosures (see Section 4 for the format).		selected Disclosures (see Section 4 for the format).
	4. If Key Binding is not required:		4. If Key Binding is not required:
	1. Send the SD-JWT to the Verifier.
			a. Send the SD-JWT to the Verifier.
	5. If Key Binding is required:		5. If Key Binding is required:
	1. Create a Key Binding JWT tied to the SD-JWT.
	2. Assemble the SD-JWT+KB by concatenating the SD-JWT and the		a. Create a Key Binding JWT tied to the SD-JWT.
			b. Assemble the SD-JWT+KB by concatenating the SD-JWT and the
	Key Binding JWT.		Key Binding JWT.
	3. Send the SD-JWT+KB to the Verifier.
			c. Send the SD-JWT+KB to the Verifier.
	7.3. Verification by the Verifier		7.3. Verification by the Verifier
	Upon receiving a presentation from a Holder, in the form of either an		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		SD-JWT or an SD-JWT+KB, in addition to the checks described in
	Section 7.1, Verifiers need to ensure that		Section 7.1, Verifiers need to ensure that
	* if Key Binding is required, then the Holder has provided an SD-		* if Key Binding is required, then the Holder has provided an SD-
	JWT+KB, and		JWT+KB, and
	* the Key Binding JWT is signed by the Holder and valid.		* the Key Binding JWT is signed by the Holder and valid.
	To this end, Verifiers MUST follow the following steps (or		To this end, Verifiers MUST follow the following steps (or
	equivalent):		equivalent):
	1. Determine if Key Binding is to be checked according to the		1. Determine if Key Binding is to be checked according to the
	Verifier's policy for the use case at hand. This decision MUST		Verifier's policy for the use case at hand. This decision MUST
	NOT be based on whether a Key Binding JWT is provided by the		NOT be based on whether or not a Key Binding JWT is provided by
	Holder or not. Refer to Section 9.5 for details.		the Holder. Refer to Section 9.5 for details.
	2. If Key Binding is required and the Holder has provided an SD-JWT		2. If Key Binding is required and the Holder has provided an SD-JWT
	(without Key Binding), the Verifier MUST reject the presentation.		(without Key Binding), the Verifier MUST reject the presentation.
	3. If the Holder has provided an SD-JWT+KB, parse it into an SD-JWT		3. If the Holder has provided an SD-JWT+KB, parse it into an SD-JWT
	and a Key Binding JWT.		and a Key Binding JWT.
	4. Process the SD-JWT as defined in Section 7.1 to validate the		4. Process the SD-JWT as defined in Section 7.1 to validate the
	presentation and extract the payload.		presentation and extract the payload.
	5. If Key Binding is required:		5. If Key Binding is required:
	1. Determine the public key for the Holder from the SD-JWT (see
			a. Determine the public key for the Holder from the SD-JWT (see
	Section 4.1.2).		Section 4.1.2).
	2. Ensure that a signing algorithm was used that was deemed
			b. Ensure that a signing algorithm was used that was deemed
	secure for the application. Refer to [RFC8725], Sections 3.1		secure for the application. Refer to [RFC8725], Sections 3.1
	and 3.2 for details. The none algorithm MUST NOT be		and 3.2 for details. The none algorithm MUST NOT be
	accepted.		accepted.
	3. Validate the signature over the Key Binding JWT per
			c. Validate the signature over the Key Binding JWT per
	Section 5.2 of [RFC7515].		Section 5.2 of [RFC7515].
	4. Check that the typ of the Key Binding JWT is kb+jwt (see
			d. Check that the typ of the Key Binding JWT is kb+jwt (see
	Section 4.3).		Section 4.3).
	5. Check that the creation time of the Key Binding JWT, as
			e. Check that the creation time of the Key Binding JWT, as
	determined by the iat claim, is within an acceptable window.		determined by the iat claim, is within an acceptable window.
	6. Determine that the Key Binding JWT is bound to the current
			f. Determine that the Key Binding JWT is bound to the current
	transaction and was created for this Verifier (replay		transaction and was created for this Verifier (replay
	detection) by validating nonce and aud claims.		detection) by validating nonce and aud claims.
	7. Calculate the digest over the Issuer-signed JWT and
			g. Calculate the digest over the Issuer-signed JWT and
	Disclosures as defined in Section 4.3.1 and verify that it		Disclosures as defined in Section 4.3.1 and verify that it
	matches the value of the sd_hash claim in the Key Binding		matches the value of the sd_hash claim in the Key Binding
	JWT.		JWT.
	8. Check that the Key Binding JWT is a valid JWT in all other		h. Check that the Key Binding JWT is a valid JWT in all other
	respects, per [RFC7519] and [RFC8725].		respects, per [RFC7519] and [RFC8725].
	If any step fails, the presentation is not valid and processing MUST		If any step fails, the presentation is not valid and processing MUST
	be aborted.		be aborted.
	Otherwise, the Processed SD-JWT Payload can be passed to the		Otherwise, the Processed SD-JWT Payload can be passed to the
	application to be used for the intended purpose.		application to be used for the intended purpose.
	8. JWS JSON Serialization		8. JWS JSON Serialization
	skipping to change at page 36, line 27 ¶		skipping to change at line 1884 ¶
	JWT+KBs using the JWS JSON Serialization from [RFC7515]. Supporting		JWT+KBs using the JWS JSON Serialization from [RFC7515]. Supporting
	this format is OPTIONAL.		this format is OPTIONAL.
	8.1. New Unprotected Header Parameters		8.1. New Unprotected Header Parameters
	For both the General and Flattened JSON Serialization, the SD-JWT or		For both the General and Flattened JSON Serialization, the SD-JWT or
	SD-JWT+KB is represented as a JSON object according to Section 7.2 of		SD-JWT+KB is represented as a JSON object according to Section 7.2 of
	[RFC7515]. The following new unprotected header parameters are		[RFC7515]. The following new unprotected header parameters are
	defined:		defined:
	* disclosures: An array of strings where each element is an		disclosures: An array of strings where each element is an individual
	individual Disclosure as described in Section 4.2.		Disclosure as described in Section 4.2.
	* kb_jwt: Present only in an SD-JWT+KB, the Key Binding JWT as
			kb_jwt: Present only in an SD-JWT+KB, the Key Binding JWT as
	described in Section 4.3.		described in Section 4.3.
	In an SD-JWT+KB, kb_jwt MUST be present when using the JWS JSON		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		Serialization, and the digest in the sd_hash claim MUST be taken over
	the SD-JWT as described in Section 4.3.1. This means that even when		the SD-JWT as described in Section 4.3.1. This means that even when
	using the JWS JSON Serialization, the representation as a regular SD-		using the JWS JSON Serialization, the representation as a regular SD-
	JWT Compact Serialization MUST be created temporarily to calculate		JWT Compact Serialization MUST be created temporarily to calculate
	the digest. In detail, the SD-JWT Compact Serialization part is		the digest. In detail, the SD-JWT Compact Serialization part is
	built by concatenating the protected header, the payload, and the		built by concatenating the protected header, the payload, and the
	signature of the JWS JSON serialized SD-JWT using a . character as a		signature of the JWS JSON serialized SD-JWT using a . character as a
	separator, and using the Disclosures from the disclosures member of		separator, and using the Disclosures from the disclosures member of
	the unprotected header.		the unprotected header.
	Unprotected headers other than disclosures are not covered by the		Unprotected headers other than disclosures are not covered by the
	digest, and therefore, as usual, are not protected against tampering.		digest, and therefore, as usual, are not protected against tampering.
	8.2. Flattened JSON Serialization		8.2. Flattened JSON Serialization
	In case of the Flattened JSON Serialization, there is only one		In the case of Flattened JSON Serialization, there is only one
	unprotected header.		unprotected header.
	The following is a non-normative example of a JWS JSON serialized SD-		The following is a non-normative example of a JWS JSON serialized SD-
	JWT as issued using the Flattened JSON Serialization:		JWT as issued using the Flattened JSON Serialization:
	{		{
	"header": {		"header": {
	"disclosures": [		"disclosures": [
	"WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICJqb2huX2RvZV80M		"WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICJqb2huX2RvZV80M
	iJd",		iJd",
	skipping to change at page 38, line 38 ¶		skipping to change at line 1976 ¶
	lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm		lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm
	Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",		Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
	"protected":		"protected":
	"eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",		"eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
	"signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK		"signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK
	y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"		y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"
	}		}
	8.3. General JSON Serialization		8.3. General JSON Serialization
	In case of the General JSON Serialization, there are multiple		In the case of General JSON Serialization, there are multiple
	unprotected headers (one per signature). If present, disclosures and		unprotected headers (one per signature). If present, disclosures and
	kb_jwt, MUST be included in the first unprotected header and MUST NOT		kb_jwt MUST be included in the first unprotected header and MUST NOT
	be present in any following unprotected headers.		be present in any following unprotected headers.
	The following is a non-normative example of a presentation of a JWS		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:		JSON Serialization:
	{		{
	"payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn		"payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
	lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV		lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
	ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk		ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk
	U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl		U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl
	JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS		JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS
	IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG		IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG
	ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi		ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi
	skipping to change at page 40, line 13 ¶		skipping to change at line 2038 ¶
	}		}
	8.4. Verification of the JWS JSON Serialized SD-JWT		8.4. Verification of the JWS JSON Serialized SD-JWT
	Verification of the JWS JSON serialized SD-JWT follows the rules		Verification of the JWS JSON serialized SD-JWT follows the rules
	defined in Section 3.4, except for the following aspects:		defined in Section 3.4, except for the following aspects:
	* The SD-JWT or SD-JWT+KB does not need to be split into component		* The SD-JWT or SD-JWT+KB does not need to be split into component
	parts and the Disclosures can be found in the disclosures member		parts and the Disclosures can be found in the disclosures member
	of the unprotected header.		of the unprotected header.
	* To verify the digest in sd_hash in the Key Binding JWT of an SD-		* To verify the digest in sd_hash in the Key Binding JWT of an SD-
	JWT+KB, the Verifier MUST assemble the string to be hashed as		JWT+KB, the Verifier MUST assemble the string to be hashed as
	described in Section 8.1.		described in Section 8.1.
	9. Security Considerations		9. Security Considerations
	Security considerations in this section help achieve the following		The security considerations help achieve the following properties:
	properties:
	*Selective Disclosure:* An adversary in the role of the Verifier		*Selective Disclosure:*
	cannot obtain information from an SD-JWT about any claim name or		An adversary in the role of the Verifier cannot obtain information
	claim value that was not explicitly disclosed by the Holder unless		from an SD-JWT about any claim name or claim value that was not
	that information can be derived from other disclosed claims or		explicitly disclosed by the Holder unless that information can be
	sources other than the presented SD-JWT.		derived from other disclosed claims or sources other than the
			presented SD-JWT.
	*Integrity:* A malicious Holder cannot modify names or values of		*Integrity:*
	selectively disclosable claims without detection by the Verifier.		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		Additionally, as described in Section 9.5, the application of Key
	Binding can ensure that the presenter of an SD-JWT credential is the		Binding can ensure that the presenter of an SD-JWT credential is
	Holder of the credential.		the Holder of the credential.
	9.1. Mandatory Signing of the Issuer-signed JWT		9.1. Mandatory Signing of the Issuer-Signed JWT
	The JWT MUST be signed by the Issuer to protect the integrity of the		The JWT MUST be signed by the Issuer to protect the integrity of the
	issued claims. An attacker can modify or add claims if this JWT is		issued claims. An attacker can modify or add claims if this JWT is
	not signed (e.g., change the "email" attribute to take over the		not signed (e.g., change the "email" attribute to take over the
	victim's account or add an attribute indicating a fake academic		victim's account or add an attribute indicating a fake academic
	qualification).		qualification).
	The Verifier MUST always check the signature of the Issuer-signed JWT		The Verifier MUST always check the signature of the Issuer-signed JWT
	to ensure that it has not been tampered with since the issuance. The		to ensure that it has not been tampered with since its issuance. The
	Issuer-signed JWT MUST be rejected if the signature cannot be		Issuer-signed JWT MUST be rejected if the signature cannot be
	verified.		verified.
	The security of the Issuer-signed JWT depends on the security of the		The security of the Issuer-signed JWT depends on the security of the
	signature algorithm. Per the last paragraph of Section 5.2 of		signature algorithm. Per the last paragraph of Section 5.2 of
	[RFC7515], it is an application-specific decision to choose the		[RFC7515], it is an application-specific decision to choose the
	appropriate JWS algorithm from [IANA.JWS.Algorithms], including post-		appropriate JWS algorithm from [JWS.Algs], including post-quantum
	quantum algorithms, when they are ready.		algorithms, when they are ready.
	9.2. Manipulation of Disclosures		9.2. Manipulation of Disclosures
	Holders can manipulate the Disclosures by changing the values of the		Holders can manipulate the Disclosures by changing the values of the
	claims before sending them to the Verifier. The Verifier MUST check		claims before sending them to the Verifier. The Verifier MUST check
	the Disclosures to ensure that the values of the claims are correct,		the Disclosures to ensure that the values of the claims are correct,
	i.e., the digests of the Disclosures are actually present in the		i.e., the digests of the Disclosures are actually present in the
	signed SD-JWT.		signed SD-JWT.
	A naive Verifier that extracts all claim values from the Disclosures		A naive Verifier that extracts all claim values from the Disclosures
	skipping to change at page 41, line 38 ¶		skipping to change at line 2114 ¶
	function. The randomness ensures that the same plaintext claim value		function. The randomness ensures that the same plaintext claim value
	does not produce the same digest value. It also makes it infeasible		does not produce the same digest value. It also makes it infeasible
	to guess the preimage of the digest (thereby learning the plaintext		to guess the preimage of the digest (thereby learning the plaintext
	claim value) by enumerating the potential value space for a claim		claim value) by enumerating the potential value space for a claim
	into the hash function to search for a matching digest value. It is		into the hash function to search for a matching digest value. It is
	therefore vitally important that unrevealed salts cannot be learned		therefore vitally important that unrevealed salts cannot be learned
	or guessed, even if other salts have been revealed. As such, each		or guessed, even if other salts have been revealed. As such, each
	salt MUST be created in such a manner that it is cryptographically		salt MUST be created in such a manner that it is cryptographically
	random, sufficiently long, and has high enough entropy that it is		random, sufficiently long, and has high enough entropy that it is
	infeasible to guess. A new salt MUST be chosen for each claim		infeasible to guess. A new salt MUST be chosen for each claim
	independently of other salts. See Randomness Requirements for		independently of other salts. See "Randomness Requirements for
	Security [RFC4086] for considerations on generating random values.		Security" [RFC4086] for considerations on generating random values.
	The RECOMMENDED minimum length of the randomly-generated portion of		The RECOMMENDED minimum length of the randomly generated portion of
	the salt is 128 bits.		the salt is 128 bits.
	The Issuer MUST ensure that a new salt value is chosen for each		The Issuer MUST ensure that a new salt value is chosen for each
	claim, including when the same claim name occurs at different places		claim, including when the same claim name occurs at different places
	in the structure of the SD-JWT. This can be seen in the example in		in the structure of the SD-JWT. This can be seen in the example in
	Appendix A.2, where multiple claims with the name type appear, but		Appendix A.2, where multiple claims with the name type appear, but
	each of them has a different salt.		each of them has a different salt.
	9.4. Choice of a Hash Algorithm		9.4. Choice of a Hash Algorithm
	To ensure privacy of claims that are selectively disclosable, but are		To ensure privacy of claims that are selectively disclosable but are
	not being disclosed in a given presentation, the hash function MUST		not being disclosed in a given presentation, the hash function MUST
	ensure that it is infeasible to calculate any portion of the three		ensure that it is infeasible to calculate any portion of the three
	elements (salt, claim name, claim value) from a particular digest.		elements (salt, claim name, claim value) from a particular digest.
	This implies the hash function MUST be preimage resistant, but should		This implies the hash function MUST be preimage resistant, but should
	also not allow an observer to infer any partial information about the		also not allow an observer to infer any partial information about the
	undisclosed content. In the terminology of cryptographic commitment		undisclosed content. In the terminology of cryptographic commitment
	schemes, the hash function needs to be computationally hiding.		schemes, the hash function needs to be computationally hiding.
	To ensure the integrity of selectively disclosable claims, the hash		To ensure the integrity of selectively disclosable claims, the hash
	function MUST be second-preimage resistant. That is, for any		function MUST be second-preimage resistant. That is, for any
	combination of salt, claim name and claim value, it is infeasible to		combination of salt, claim name, and claim value, it is infeasible to
	find a different combination of salt, claim name and claim value that		find a different combination of salt, claim name, and claim value
	result in the same digest.		that results in the same digest.
	The hash function SHOULD also be collision resistant. Although not		The hash function SHOULD also be collision resistant. Although not
	essential to the anticipated uses of SD-JWT, without collision		essential to the anticipated uses of SD-JWT, without collision
	resistance an Issuer may be able to find multiple disclosures that		resistance an Issuer may be able to find multiple disclosures that
	have the same hash value. In which case, the signature over the SD-		have the same hash value. In which case, the signature over the SD-
	JWT would not then commit the Issuer to the contents of the JWT. The		JWT would not then commit the Issuer to the contents of the JWT. The
	collision resistance of the hash function used to generate digests		collision resistance of the hash function used to generate digests
	SHOULD match the collision resistance of the hash function used by		SHOULD match the collision resistance of the hash function used by
	the signature scheme. For example, use of the ES512 signature		the signature scheme. For example, use of the ES512 signature
	algorithm would require a disclosure hash function with at least		algorithm would require a disclosure hash function with at least
	256-bit collision resistance, such as SHA-512.		256-bit collision resistance, such as SHA-512.
	Inclusion in the "Named Information Hash Algorithm" registry		Inclusion in the "Named Information Hash Algorithm Registry"
	[IANA.Hash.Algorithms] alone does not indicate a hash algorithm's		[Hash.Algs] alone does not indicate a hash algorithm's suitability
	suitability for use in SD-JWT (it contains several heavily truncated		for use in SD-JWT (it contains several heavily truncated digests,
	digests, such as sha-256-32 and sha-256-64, which are unfit for		such as sha-256-32 and sha-256-64, which are unfit for security
	security applications).		applications).
	9.5. Key Binding		9.5. Key Binding
	Key Binding aims to ensure that the presenter of an SD-JWT credential		Key Binding aims to ensure that the presenter of an SD-JWT credential
	is actually the Holder of the credential. An SD-JWT compatible with		is actually the Holder of the credential. An SD-JWT compatible with
	Key Binding contains a public key, or a reference to a public key,		Key Binding contains a public key, or a reference to a public key,
	that corresponds to a private key possessed by the Holder. The		that corresponds to a private key possessed by the Holder. The
	Verifier requires that the Holder prove possession of that private		Verifier requires that the Holder prove possession of that private
	key when presenting the SD-JWT credential.		key when presenting the SD-JWT credential.
	Without Key Binding, a Verifier only gets the proof that the		Without Key Binding, a Verifier only gets the proof that the
	credential was issued by a particular Issuer, but the credential		credential was issued by a particular Issuer, but the credential
	itself can be replayed by anyone who gets access to it. This means		itself can be replayed by anyone who gets access to it. This means
	that, for example, after a credential was leaked to an attacker, the		that, for example, after the credential was leaked to an attacker,
	attacker can present the credential to any verifier that does not		the attacker can present the credential to any Verifier that does not
	require a binding. But also a malicious Verifier to which the Holder		require a binding. Also, a malicious Verifier to which the Holder
	presented the credential can present the credential to another		presented the credential can present the credential to another
	Verifier if that other Verifier does not require Key Binding.		Verifier if that other Verifier does not require Key Binding.
	Verifiers MUST decide whether Key Binding is required for a		Verifiers MUST decide whether Key Binding is required for a
	particular use case before verifying a credential. This decision can		particular use case before verifying a credential. This decision can
	be informed by various factors including, but not limited to the		be informed by various factors including but not limited to the
	following: business requirements, the use case, the type of binding		following: business requirements, the use case, the type of binding
	between a Holder and its credential that is required for a use case,		between a Holder and its credential that is required for a use case,
	the sensitivity of the use case, the expected properties of a		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.		presented at the same time, etc.
	It is important that a Verifier does not make its security policy		It is important that a Verifier not make its security policy
	decisions based on data that can be influenced by an attacker. For		decisions based on data that can be influenced by an attacker. For
	this reason, when deciding whether Key Binding is required or not,		this reason, when deciding whether or not Key Binding is required,
	Verifiers MUST NOT take into account whether the Holder has provided		Verifiers MUST NOT take into account whether the Holder has provided
	an SD-JWT+KB or a bare SD-JWT, since otherwise an attacker could		an SD-JWT+KB or a bare SD-JWT; otherwise, an attacker could strip the
	strip the KB-JWT from an SD-JWT+KB and present the resulting SD-JWT.		KB-JWT from an SD-JWT+KB and present the resultant SD-JWT.
	Furthermore, Verifiers should be aware that Key Binding information		Furthermore, Verifiers should be aware that Key Binding information
	may have been added to an SD-JWT in a format that they do not		may have been added to an SD-JWT in a format that they do not
	recognize and therefore may not be able to tell whether the SD-JWT		recognize and therefore may not be able to tell whether or not the
	supports Key Binding or not.		SD-JWT supports Key Binding.
	If a Verifier determines that Key Binding is required for a		If a Verifier determines that Key Binding is required for a
	particular use case and the Holder presents either a bare SD-JWT or		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		an SD-JWT+KB with an invalid Key Binding JWT, then the Verifier will
	reject the presentation when following the verification steps		reject the presentation when following the verification steps
	described in Section 7.3.		described in Section 7.3.
	9.6. Concealing Claim Names		9.6. Concealing Claim Names
	SD-JWT ensures that names of claims that are selectively disclosable		SD-JWT ensures that names of claims that are selectively disclosable
	are always concealed unless the claim's value is disclosed. This		are always concealed unless the claim's value is disclosed. This
	prevents an attacker from learning the names of such claims.		prevents an attacker from learning the names of such claims.
	However, the names of the claims that are permanently disclosed are		However, the names of the claims that are permanently disclosed are
	not hidden. This includes the keys of objects that themselves are		not hidden. This includes the keys of objects that themselves are
	not concealed, but contain concealed claims. This limitation needs		not concealed, but contain concealed claims. This limitation needs
	to be taken into account by Issuers when creating the structure of		to be taken into account by Issuers when creating the structure of
	the SD-JWT.		the SD-JWT.
	9.7. Selectively-Disclosable Validity Claims		9.7. Selectively Disclosable Validity Claims
	An Issuer MUST NOT allow any content to be selectively disclosable		An Issuer MUST NOT allow any content to be selectively disclosable
	that is critical for evaluating the SD-JWT's authenticity or		that is critical for evaluating the SD-JWT's authenticity or
	validity. The exact list of such content will depend on the		validity. The exact list of such content will depend on the
	application and SHOULD be listed by any application-specific profiles		application and SHOULD be listed by any application-specific profiles
	of SD-JWT. The following is a list of registered JWT claim names		of SD-JWT. The following is a list of registered JWT claim names
	that SHOULD be considered as security-critical:		that SHOULD be considered as security critical:
	* iss (Issuer)		* iss (Issuer)
	* aud (Audience), although issuers MAY allow individual entries in		* aud (Audience), although issuers MAY allow individual entries in
	the array to be selectively disclosable		the array to be selectively disclosable
	* exp (Expiration Time)		* exp (Expiration Time)
	* nbf (Not Before)		* nbf (Not Before)
	* cnf (Confirmation Key)		* cnf (Confirmation Key)
	Issuers will typically include claims controlling the validity of the		Issuers will typically include claims controlling the validity of the
	SD-JWT in plaintext in the SD-JWT payload, but there is no guarantee		SD-JWT in plaintext in the SD-JWT payload, but there is no guarantee
	they would do so. Therefore, Verifiers cannot reliably depend on		they will do so. Therefore, Verifiers cannot reliably depend on that
	that and need to operate as though security-critical claims might be		and need to operate as though security-critical claims might be
	selectively disclosable.		selectively disclosable.
	Verifiers therefore MUST ensure that all claims they deem necessary		Verifiers therefore MUST ensure that all claims they deem necessary
	for checking the validity of an SD-JWT in the given context are		for checking the validity of an SD-JWT in the given context are
	present (or disclosed, respectively) during validation of the SD-JWT.		present (or disclosed, respectively) during validation of the SD-JWT.
	This is implemented in the last step of the verification defined in		This is implemented in the last step of the verification defined in
	Section 7.1.		Section 7.1.
	The precise set of required validity claims will typically be defined		The precise set of required validity claims will typically be defined
	by operating environment rules, application-specific profile, or the		by operating environment rules, an application-specific profile, or
	credential format and MAY include claims other than those listed		the credential format, and MAY include claims other than those listed
	herein.		herein.
	9.8. Distribution and Rotation of Issuer Signature Verification Key		9.8. Distribution and Rotation of Issuer Signature Verification Key
	This specification does not define how signature verification keys of		This specification does not define how signature verification keys of
	Issuers are distributed to Verifiers. However, it is RECOMMENDED		Issuers are distributed to Verifiers. However, it is RECOMMENDED
	that Issuers publish their keys in a way that allows for efficient		that Issuers publish their keys in a way that allows for efficient
	and secure key rotation and revocation, for example, by publishing		and secure key rotation and revocation, for example, by publishing
	keys at a predefined location using the JSON Web Key Set (JWKS)		keys at a predefined location using the JSON Web Key Set (JWKS)
	format [RFC7517]. Verifiers need to ensure that they are not using		format [RFC7517]. Verifiers need to ensure that they are not using
	skipping to change at page 45, line 20 ¶		skipping to change at line 2279 ¶
	Disclosures such that the receiver learns only a subset of the claims		Disclosures such that the receiver learns only a subset of the claims
	contained in the original SD-JWT.		contained in the original SD-JWT.
	For example, a device manufacturer might produce an SD-JWT containing		For example, a device manufacturer might produce an SD-JWT containing
	information about upstream and downstream supply chain contributors.		information about upstream and downstream supply chain contributors.
	Each supply chain party can verify only the claims that were		Each supply chain party can verify only the claims that were
	selectively disclosed to them by an upstream party, and they can		selectively disclosed to them by an upstream party, and they can
	choose to further reduce the disclosed claims when presenting to a		choose to further reduce the disclosed claims when presenting to a
	downstream party.		downstream party.
	In some scenarios this behavior could be desirable, but if it is not,		In some scenarios, this behavior could be desirable; if it is not,
	Issuers need to support and Verifiers need to enforce Key Binding.		Issuers need to support and Verifiers need to enforce Key Binding.
	9.10. Integrity of SD-JWTs and SD-JWT+KBs		9.10. Integrity of SD-JWTs and SD-JWT+KBs
	With an SD-JWT, the Issuer-signed JWT is integrity-protected by the		With an SD-JWT, the Issuer-signed JWT is integrity protected by the
	Issuer's signature, and the values of the Disclosures are integrity-		Issuer's signature, and the values of the Disclosures are integrity
	protected by the digests included therein. The specific set of		protected by the digests included therein. The specific set of
	Disclosures, however, is not integrity-protected; the SD-JWT can be		Disclosures, however, is not integrity protected; the SD-JWT can be
	modified by adding or removing Disclosures and still be valid.		modified by adding or removing Disclosures and still be valid.
	With an SD-JWT+KB, the set of selected Disclosures is integrity-		With an SD-JWT+KB, the set of selected Disclosures is integrity
	protected. The signature in the Key Binding JWT covers a specific		protected. The signature in the Key Binding JWT covers a specific
	SD-JWT, with a specific Issuer-signed JWT and a specific set of		SD-JWT, with a specific Issuer-signed JWT and a specific set of
	Disclosures. Thus, the signature on the Key Binding JWT, in addition		Disclosures. Thus, the signature on the Key Binding JWT, in addition
	to proving Key Binding, also assures the authenticity and integrity		to proving Key Binding, also assures the authenticity and integrity
	of the set of Disclosures the Holder disclosed. The set of		of the set of Disclosures the Holder disclosed. The set of
	Disclosures in an SD-JWT+KB is the set that the Holder intended to		Disclosures in an SD-JWT+KB is the set that the Holder intended to
	send; no intermediate party has added, removed, or modified the list		send; no intermediate party has added, removed, or modified the list
	of Disclosures.		of Disclosures.
	9.11. Explicit Typing		9.11. Explicit Typing
	Section 3.11 of [RFC8725] describes the use of explicit typing as one		Section 3.11 of [RFC8725] describes the use of explicit typing as one
	mechanism to prevent confusion attacks (described in Section 2.8 of		mechanism to prevent confusion attacks (described in Section 2.8 of
	[RFC8725]) in which one kind of JWT is mistaken for another. SD-JWTs		[RFC8725]) in which one kind of JWT is mistaken for another. SD-JWTs
	are also potentially subject to such confusion attacks, so in the		are also potentially subject to such confusion attacks, so in the
	absence of other techniques, it is RECOMMENDED that application		absence of other techniques, it is RECOMMENDED that application
	profiles of SD-JWT specify an explicit type by including the typ		profiles of SD-JWT specify an explicit type by including the typ
	header parameter when the SD-JWT is issued, and for Verifiers to		header parameter when the SD-JWT is issued, and that Verifiers check
	check this value.		this value.
	When explicit typing using the typ header is employed for an SD-JWT,		When explicit typing using the typ header is employed for an SD-JWT,
	it is RECOMMENDED that a media type name of the format "application/		it is RECOMMENDED that a media type name of the format "application/
	example+sd-jwt" be used, where "example" is replaced by the		example+sd-jwt" be used, where "example" is replaced by the
	identifier for the specific kind of SD-JWT. The definition of typ in		identifier for the specific kind of SD-JWT. The definition of typ in
	Section 4.1.9 of [RFC7515] recommends that the "application/" prefix		Section 4.1.9 of [RFC7515] recommends that the "application/" prefix
	be omitted, so "example+sd-jwt" would be the value of the typ header		be omitted, so "example+sd-jwt" would be the value of the typ header
	parameter.		parameter.
	Use of the cty content type header parameter to indicate the content		Use of the cty content type header parameter to indicate the content
	type of the SD-JWT payload can also be used to distinguish different		type of the SD-JWT payload can also be used to distinguish different
	types of JSON objects, or different kinds of JWT Claim Sets.		types of JSON objects or different kinds of JWT Claim Sets.
	9.12. Key Pair Generation and Lifecycle Management		9.12. Key Pair Generation and Lifecycle Management
	Implementations of SD-JWT rely on asymmetric cryptographic keys and		Implementations of SD-JWT rely on asymmetric cryptographic keys and
	must therefore ensure that key pair generation, handling, storage,		must therefore ensure that key pair generation, handling, storage,
	and lifecycle management are performed securely.		and lifecycle management are performed securely.
	While the specific mechanisms for secure key management are out of		While the specific mechanisms for secure key management are out of
	scope for this document, implementers should follow established best		scope for this document, implementers should follow established best
	practices, such as those outlined in NIST SP 800-57 Part 1		practices, such as those outlined in NIST SP 800-57 Part 1
	skipping to change at page 47, line 15 ¶		skipping to change at line 2371 ¶
	* After a data breach at multiple Verifiers, publicly available		* After a data breach at multiple Verifiers, publicly available
	information might allow linking identifiable information presented		information might allow linking identifiable information presented
	to Verifier A with originally anonymous information presented to		to Verifier A with originally anonymous information presented to
	Verifier B, therefore revealing the identities of users of		Verifier B, therefore revealing the identities of users of
	Verifier B.		Verifier B.
	The following types of unlinkability are discussed below:		The following types of unlinkability are discussed below:
	* Presentation Unlinkability: A Verifier should not be able to link		* Presentation Unlinkability: A Verifier should not be able to link
	two presentations of the same credential.		two presentations of the same credential.
	* Verifier/Verifier Unlinkability: The presentations made to two		* Verifier/Verifier Unlinkability: The presentations made to two
	different Verifiers should not reveal that the same credential was		different Verifiers should not reveal that the same credential was
	presented (e.g., if the two Verifiers collude, or if they are		presented (e.g., if the two Verifiers collude, or if they are
	forced by a third party to reveal the presentations made to them,		forced by a third party to reveal the presentations made to them,
	or data leaks from one Verifier to the other).		or data leaks from one Verifier to the other).
	* Issuer/Verifier Unlinkability (Honest Verifier): An Issuer of a		* Issuer/Verifier Unlinkability (Honest Verifier): An Issuer of a
	credential should not be able to know that a user presented this		credential should not be able to know that a user presented this
	credential unless the Verifier is sharing presentation data with		credential unless the Verifier is sharing presentation data with
	the Issuer accidentally, deliberately, or because it is forced to		the Issuer accidentally, deliberately, or because it is forced to
	do so.		do so.
	* Issuer/Verifier Unlinkability (Careless/Colluding/Compromised/		* Issuer/Verifier Unlinkability (Careless/Colluding/Compromised/
	Coerced Verifier): An Issuer of a credential should under no		Coerced Verifier): >An Issuer of a credential should under no
	circumstances be able to tell that a user presented this		circumstances be able to tell that a user presented this
	credential to a certain Verifier. In particular this includes		credential to a certain Verifier. In particular, this includes
	cases when the Verifier accidentally or deliberately shares		cases when the Verifier accidentally or deliberately shares
	presentation data with the Issuer or is forced to do so.		presentation data with the Issuer or is forced to do so.
	In all cases, unlinkability is limited to cases where the disclosed		In all cases, unlinkability is limited to cases where the disclosed
	claims do not contain information that directly or indirectly		claims do not contain information that directly or indirectly
	identifies the user. For example, when a taxpayer identification		identifies the user. For example, when a taxpayer identification
	number is contained in the disclosed claims, the Issuer and Verifier		number is contained in the disclosed claims, the Issuer and Verifier
	can easily link the user's transactions. However, when the user only		can easily link the user's transactions. However, when the user only
	discloses a birthdate to one Verifier and a postal code to another		discloses a birthdate to one Verifier and a postal code to another
	Verifier, the two Verifiers should not be able to determine that they		Verifier, the two Verifiers should not be able to determine that they
	were interacting with the same user.		were interacting with the same user.
	Issuer/Verifier unlinkability with a careless, colluding,		Issuer/Verifier unlinkability with a careless, colluding,
	compromised, or coerced Verifier cannot be achieved in salted-hash		compromised, or coerced Verifier cannot be achieved in salted hash-
	based selective disclosure approaches, such as SD-JWT, as the issued		based selective disclosure approaches, such as SD-JWT, as the issued
	credential with the Issuer's signature is directly presented to the		credential with the Issuer's signature is directly presented to the
	Verifier, who can forward it to the Issuer. To reduce the risk of		Verifier, who can forward it to the Issuer. To reduce the risk of
	revealing the data later on, Section 10.2 defines requirements to		revealing the data later on, Section 10.2 defines requirements to
	reduce the amount of data stored.		reduce the amount of data stored.
	In considering Issuer/Verifier unlinkability, it is important to note		In considering Issuer/Verifier unlinkability, it is important to note
	the potential for an asymmetric power dynamic between Issuers and		the potential for an asymmetric power dynamic between Issuers and
	Verifiers. This dynamic can compel an otherwise honest Verifier into		Verifiers. This dynamic can compel an otherwise Honest Verifier into
	collusion. For example, a governmental Issuer might have the		collusion. For example, a governmental Issuer might have the
	authority to mandate that a Verifier report back information about		authority to mandate that a Verifier report back information about
	the credentials presented to it. Legal requirements could further		the credentials presented to it. Legal requirements could further
	enforce this, explicitly undermining Issuer/Verifier unlinkability.		enforce this, explicitly undermining Issuer/Verifier unlinkability.
	Similarly, a large service provider issuing credentials might		Similarly, a large service provider issuing credentials might
	implicitly pressure Verifiers into collusion by incentivizing		implicitly pressure Verifiers into collusion by incentivizing
	participation in their larger operating environment. Deployers of		participation in their larger operating environment. Deployers of
	SD-JWT must be aware of these potential power dynamics, mitigate them		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.		as much as possible, and/or make the risks transparent to the user.
	Contrary to that, Issuer/Verifier unlinkability with an honest		Contrary to that, Issuer/Verifier unlinkability with an Honest
	Verifier can generally be achieved. However, a callback from the		Verifier can generally be achieved. However, a callback from the
	Verifier to the Issuer, such as a revocation check, could potentially		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		Where such callbacks are necessary, they need to be executed in a
	manner that preserves privacy and does not disclose details about the		manner that preserves privacy and does not disclose details about the
	credential to the Issuer (the mechanism described in		credential to the Issuer (the mechanism described in [TSL] is an
	[I-D.ietf-oauth-status-list] is an example of an approach with		example of an approach that discloses minimal information towards the
	minimal information disclosure towards the Issuer). It is important		Issuer). It is important to note that the timing of such requests
	to note that the timing of such requests could potentially serve as a		could potentially serve as a side channel.
	side-channel.
	Verifier/Verifier unlinkability and presentation unlinkability can be		Verifier/Verifier unlinkability and presentation unlinkability can be
	achieved using batch issuance: A batch of credentials based on the		achieved using batch issuance: A batch of credentials based on the
	same claims is issued to the Holder instead of just a single		same claims is issued to the Holder instead of just a single
	credential. The Holder can then use a different credential for each		credential. The Holder can then use a different credential for each
	Verifier or even for each session with a Verifier. New key binding		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		keys and salts MUST be used for each credential in the batch to
	ensure that the Verifiers cannot link the credentials using these		ensure that the Verifiers cannot link the credentials using these
	values. Likewise, claims carrying time information, like iat, exp,		values. Likewise, claims carrying time information, like iat, exp,
	and nbf, MUST either be randomized within a time period considered		and nbf, MUST either be randomized within a time period considered
	appropriate (e.g., randomize iat within the last 24 hours and		appropriate (e.g., randomize iat within the last 24 hours and
	calculate exp accordingly) or rounded (e.g., rounded down to the		calculate exp accordingly) or rounded (e.g., rounded down to the
	beginning of the day).		beginning of the day).
	SD-JWT only conceals the value of claims that are not revealed. It		SD-JWT only conceals the value of claims that are not revealed. It
	does not meet the security properties for anonymous credentials		does not meet the security properties for anonymous credentials
	[CL01]. In particular, colluding Verifiers and Issuers can know when		[CL01]. In particular, colluding Verifiers and Issuers can know when
	they have seen the same credential no matter what fields have been		they have seen the same credential no matter what fields have been
	disclosed, even when none have been disclosed. This behavior may not		disclosed, even when none have been disclosed. This behavior may not
	align with what users naturally anticipate or are guided to expect		align with what users naturally anticipate or are guided to expect
	from user interface interactions, potentially causing them to make		from user-interface interactions, potentially causing them to make
	decisions they might not otherwise make. Workarounds such as batch		decisions they might not otherwise make. Workarounds such as batch
	issuance, as described above, help with keeping Verifiers from		issuance, as described above, help with keeping Verifiers from
	linking different presentations, but cannot work for Issuer/Verifier		linking different presentations, but cannot work for Issuer/Verifier
	unlinkability. This issue applies to all salted hash-based		unlinkability. This issue applies to all salted hash-based
	approaches, including mDL/mDoc [ISO.18013-5] and SD-CWT		approaches, including mDL/mDoc [ISO.18013-5] and SD-CWT [SD-CWT].
	[I-D.ietf-spice-sd-cwt].
	10.2. Storage of User Data		10.2. Storage of User Data
	Wherever user data is stored, it represents a potential target for an		Wherever user data is stored, it represents a potential target for an
	attacker. This target can be of particularly high value when the		attacker. This target can be of particularly high value when the
	data is signed by a trusted authority like an official national		data is signed by a trusted authority like an official national
	identity service. For example, in OpenID Connect [OpenID.Core],		identity service. For example, in OpenID Connect [OpenID.Core],
	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, and Issuers and Verifiers may		SD-JWT, Holders have to store SD-JWTs, and Issuers and Verifiers may
	decide to do so as well.		decide to do so as well.
	skipping to change at page 49, line 25 ¶		skipping to change at line 2478 ¶
	Not surprisingly, a leak of such data risks revealing private data of		Not surprisingly, a leak of such data risks revealing private data of
	users to third parties. Signed user data, the authenticity of which		users to third parties. Signed user data, the authenticity of which
	can be easily verified by third parties, further exacerbates the		can be easily verified by third parties, further exacerbates the
	risk. As discussed in Section 9.5, leaked SD-JWTs may also allow		risk. As discussed in Section 9.5, leaked SD-JWTs may also allow
	attackers to impersonate Holders unless Key Binding is enforced and		attackers to impersonate Holders unless Key Binding is enforced and
	the attacker does not have access to the Holder's cryptographic keys.		the attacker does not have access to the Holder's cryptographic keys.
	Due to these risks, and the risks described in Section 10.1, systems		Due to these risks, and the risks described in Section 10.1, systems
	implementing SD-JWT SHOULD be designed to minimize the amount of data		implementing SD-JWT SHOULD be designed to minimize the amount of data
	that is stored. All involved parties SHOULD NOT store SD-JWTs longer		that is stored. All involved parties SHOULD NOT store SD-JWTs longer
	than strictly needed, including in log files.		than strictly necessary, including in log files.
	After Issuance, Issuers SHOULD NOT store the Issuer-signed JWT or the		After Issuance, Issuers SHOULD NOT store the Issuer-signed JWT or the
	respective Disclosures.		respective Disclosures.
	Holders SHOULD store SD-JWTs only in encrypted form, and, wherever		Holders SHOULD store SD-JWTs only in encrypted form, and, wherever
	possible, use hardware-backed encryption in particular for the		possible, use hardware-backed encryption in particular for the
	private Key Binding key. Decentralized storage of data, e.g., on		private Key Binding key. Decentralized storage of data, e.g., on
	user devices, SHOULD be preferred for user credentials over		user devices, SHOULD be preferred for user credentials over
	centralized storage. Expired SD-JWTs SHOULD be deleted as soon as		centralized storage. Expired SD-JWTs SHOULD be deleted as soon as
	possible.		possible.
	skipping to change at page 49, line 47 ¶		skipping to change at line 2500 ¶
	After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT		After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT
	or the respective Disclosures. It may be sufficient to store the		or the respective Disclosures. It may be sufficient to store the
	result of the verification and any user data that is needed for the		result of the verification and any user data that is needed for the
	application.		application.
	Exceptions from the rules above can be made if there are strong		Exceptions from the rules above can be made if there are strong
	requirements to do so (e.g., functional requirements or legal audit		requirements to do so (e.g., functional requirements or legal audit
	requirements), secure storage can be ensured, and the privacy impact		requirements), secure storage can be ensured, and the privacy impact
	has been assessed.		has been assessed.
	10.3. Confidentiality during Transport		10.3. Confidentiality During Transport
	If an SD-JWT or SD-JWT+KB is transmitted over an insecure channel		If an SD-JWT or SD-JWT+KB is transmitted over an insecure channel
	during issuance or presentation, an adversary may be able to		during issuance or presentation, an adversary may be able to
	intercept and read the user's personal data or correlate the		intercept and read the user's personal data or correlate the
	information with previous uses.		information with previous uses.
	Usually, transport protocols for issuance and presentation of		Usually, transport protocols for issuance and presentation of
	credentials are designed to protect the confidentiality of the		credentials are designed to protect the confidentiality of the
	transmitted data, for example, by requiring the use of TLS.		transmitted data, for example, by requiring the use of TLS.
	skipping to change at page 50, line 28 ¶		skipping to change at line 2530 ¶
	insecure or leakage-prone channels, implementers MAY use JSON Web		insecure or leakage-prone channels, implementers MAY use JSON Web
	Encryption (JWE) [RFC7516], encapsulating the SD-JWT or SD-JWT+KB as		Encryption (JWE) [RFC7516], encapsulating the SD-JWT or SD-JWT+KB as
	the plaintext payload of the JWE. Especially, when an SD-JWT is		the plaintext payload of the JWE. Especially, when an SD-JWT is
	transmitted via a URL and information may be stored/cached in the		transmitted via a URL and information may be stored/cached in the
	browser or end up in web server logs, the SD-JWT SHOULD be encrypted		browser or end up in web server logs, the SD-JWT SHOULD be encrypted
	using JWE.		using JWE.
	10.4. Decoy Digests		10.4. Decoy Digests
	The use of decoy digests is RECOMMENDED when the number of claims (or		The use of decoy digests is RECOMMENDED when the number of claims (or
	the existence of particular claims) can be a side-channel disclosing		the existence of particular claims) can be a side channel disclosing
	information about otherwise undisclosed claims. In particular, if a		information about otherwise undisclosed claims. In particular, if a
	claim in an SD-JWT is present only if a certain condition is met		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		(e.g., a membership number is only contained if the user is a member
	of a group), the Issuer SHOULD add decoy digests when the condition		of a group), the Issuer SHOULD add decoy digests when the condition
	is not met.		is not met.
	Decoy digests increase the size of the SD-JWT. The number of decoy		Decoy digests increase the size of the SD-JWT. The number of decoy
	digests (or whether to use them at all) is a trade-off between the		digests (or whether to use them at all) is a trade-off between the
	size of the SD-JWT and the privacy of the user's data.		size of the SD-JWT and the privacy of the user's data.
	10.5. Issuer Identifier		10.5. Issuer Identifier
	An Issuer issuing only one type of SD-JWT might have privacy		An Issuer issuing only one type of SD-JWT might have privacy
	implications, because if the Holder has an SD-JWT issued by that		implications, because if the Holder has an SD-JWT issued by that
	Issuer, its type and claim names can be determined.		Issuer, its type and claim names can be determined.
	For example, if a cancer research institute only issued SD-JWTs with		For example, if a cancer research institute only issued SD-JWTs with
	cancer registry information, it is possible to deduce that the Holder		cancer registry information, it is possible to deduce that the Holder
	owning its SD-JWT is a cancer patient.		owning its SD-JWT is a cancer patient.
	Moreover, the issuer identifier alone may reveal information about		Moreover, the Issuer identifier alone may reveal information about
	the user.		the user.
	For example, when a military organization or a drug rehabilitation		For example, when a military organization or a drug rehabilitation
	center issues a vaccine credential, verifiers can deduce that the		center issues a vaccine credential, Verifiers can deduce that the
	holder is a military member or may have a substance use disorder.		holder is a military member or may have a substance use disorder.
	To mitigate this issue, a group of issuers may elect to use a common		To mitigate this issue, a group of issuers may elect to use a common
	Issuer identifier. A group signature scheme outside the scope of		Issuer identifier. A group signature scheme outside the scope of
	this specification may also be used, instead of an individual		this specification may also be used, instead of an individual
	signature.		signature.
	11. Acknowledgements		11. IANA Considerations
	We would like to thank Alen Horvat, Alex Hodder, Anders Rundgren,		11.1. JSON Web Token Claims Registration
	Arjan Geluk, Chad Parry, Christian Bormann, Christian Paquin, Dale
	Bowie, Dan Moore, David Bakker, David Waite, Deb Cooley, Dick Hardt,
	Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey
	Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das,
	Martin Thomson, Matthew Miller, Michael Fraser, Michael B. Jones,
	Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele,
	Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Rohan
	Mahy, Roman Danyliw, Ryosuke Abe, Sami Rosendahl, Shawn Emery, Shawn
	Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten
	Lodderstedt, Vittorio Bertocci, Watson Ladd, and Yaron Sheffer for
	their contributions (some of which were substantial) to this draft
	and to the initial set of implementations.
	The work on this draft was started at OAuth Security Workshop 2022 in		IANA has registered the following Claims in the "JSON Web Token
	Trondheim, Norway.		Claims" registry [JWT.Claims] established by [RFC7519].
	12. IANA Considerations		Claim Name: _sd
			Claim Description: Digests of Disclosures for object properties
			Change Controller: IETF
			Specification Document(s): Section 4.2.4.1 of RFC 9901
	12.1. JSON Web Token Claims Registration		Claim Name: ...
			Claim Description: Digest of the Disclosure for an array element
			Change Controller: IETF
			Specification Document(s): Section 4.2.4.2 of RFC 9901
	This specification requests registration of the following Claims in		Claim Name: _sd_alg
	the IANA "JSON Web Token Claims" registry [IANA.JWT] established by		Claim Description: Hash algorithm used to generate Disclosure
	[RFC7519].		digests and digest over presentation
			Change Controller: IETF
			Specification Document(s): Section 4.1.1 of RFC 9901
	* Claim Name: _sd		Claim Name: sd_hash
	* Claim Description: Digests of Disclosures for object properties		Claim Description: Digest of the SD-JWT to which the KB-JWT is tied
	* Change Controller: IETF		Change Controller: IETF
	* Specification Document(s): [[ Section 4.2.4.1 of this		Specification Document(s): Section 4.3 of RFC 9901
	specification ]]
	* Claim Name: ...		11.2. Media Type Registrations
	* Claim Description: Digest of the Disclosure for an array element
	* Change Controller: IETF
	* Specification Document(s): [[ Section 4.2.4.2 of this
	specification ]]
	* Claim Name: _sd_alg		IANA has registered the following media types [RFC2046] in the "Media
	* Claim Description: Hash algorithm used to generate Disclosure		Types" registry [MediaTypes] in the manner described in [RFC6838].
	digests and digest over presentation
	* Change Controller: IETF
	* Specification Document(s): [[ Section 4.1.1 of this specification
	]]
	* Claim Name: sd_hash		| Note: For the media type value used in the typ header in the
	* Claim Description: Digest of the SD-JWT to which the KB-JWT is		| Issuer-signed JWT itself, see Section 9.11.
	tied
	* Change Controller: IETF
	* Specification Document(s): [[ Section 4.3 of this specification ]]
	12.2. Media Type Registration		11.2.1. SD-JWT Content
	This section requests registration of the following media types		To indicate that the content is an SD-JWT:
	[RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the
	manner described in [RFC6838].
	| Note: For the media type value used in the typ header in the		Type name: application
	| Issuer-signed JWT itself, see Section 9.11.
	To indicate that the content is an SD-JWT:		Subtype name: sd-jwt
	* Type name: application		Required parameters: n/a
	* Subtype name: sd-jwt
	* Required parameters: n/a		Optional parameters: n/a
	* Optional parameters: n/a
	* Encoding considerations: binary; application/sd-jwt values are a		Encoding considerations: binary; application/sd-jwt values are a
	series of base64url-encoded values (some of which may be the empty		series of base64url-encoded values (some of which may be the empty
	string) separated by period ('.') and tilde ('~') characters.		string) separated by period ('.') and tilde ('~') characters.
	* Security considerations: See the Security Considerations section
	of [[ this specification ]], [RFC7519], and [RFC8725].		Security considerations: See the Security Considerations sections of
	* Interoperability considerations: n/a		RFC 9901, [RFC7519], and [RFC8725].
	* Published specification: [[ this specification ]]
	* Applications that use this media type: Applications requiring		Interoperability considerations: n/a
	selective disclosure of integrity protected content.
	* Fragment identifier considerations: n/a		Published specification: RFC 9901
	* Additional information:
	- Magic number(s): n/a		Applications that use this media type: Applications requiring
	- File extension(s): n/a		selective disclosure of integrity-protected content.
	- Macintosh file type code(s): n/a
	* Person & email address to contact for further information: Daniel		Fragment identifier considerations: n/a
			Additional information:
			Magic number(s): n/a
			File extension(s): n/a
			Macintosh file type code(s): n/a
			Person & email address to contact for further information: Daniel
	Fett, mail@danielfett.de		Fett, mail@danielfett.de
	* Intended usage: COMMON
	* Restrictions on usage: none		Intended usage: COMMON
	* Author: Daniel Fett, mail@danielfett.de
	* Change Controller: IETF		Restrictions on usage: none
	* Provisional registration? No
			Author: Daniel Fett, mail@danielfett.de
			Change Controller: IETF
			11.2.2. JWS JSON Serialized SD-JWT Content
	To indicate that the content is a JWS JSON serialized SD-JWT:		To indicate that the content is a JWS JSON serialized SD-JWT:
	* Type name: application		Type name: application
	* Subtype name: sd-jwt+json
	* Required parameters: n/a		Subtype name: sd-jwt+json
	* Optional parameters: n/a
	* Encoding considerations: binary; application/sd-jwt+json values		Required parameters: n/a
	are represented as a JSON Object.
	* Security considerations: See the Security Considerations section		Optional parameters: n/a
	of [[ this specification ]], and [RFC7515].
	* Interoperability considerations: n/a		Encoding considerations: binary; application/sd-jwt+json values are
	* Published specification: [[ this specification ]]		represented as a JSON Object.
	* Applications that use this media type: Applications requiring
			Security considerations: See the Security Considerations sections of
			RFC 9901 and [RFC7515].
			Interoperability considerations: n/a
			Published specification: RFC 9901
			Applications that use this media type: Applications requiring
	selective disclosure of content protected by ETSI JAdES compliant		selective disclosure of content protected by ETSI JAdES compliant
	signatures.		signatures.
	* Fragment identifier considerations: n/a
	* Additional information:		Fragment identifier considerations: n/a
	- Magic number(s): n/a
	- File extension(s): n/a		Additional information:
	- Macintosh file type code(s): n/a
	* Person & email address to contact for further information: Daniel		Magic number(s): n/a
			File extension(s): n/a
			Macintosh file type code(s): n/a
			Person & email address to contact for further information: Daniel
	Fett, mail@danielfett.de		Fett, mail@danielfett.de
	* Intended usage: COMMON
	* Restrictions on usage: none		Intended usage: COMMON
	* Author: Daniel Fett, mail@danielfett.de
	* Change Controller: IETF		Restrictions on usage: none
	* Provisional registration? No
			Author: Daniel Fett, mail@danielfett.de
			Change Controller: IETF
			11.2.3. Key Binding JWT Content
	To indicate that the content is a Key Binding JWT:		To indicate that the content is a Key Binding JWT:
	* Type name: application		Type name: application
	* Subtype name: kb+jwt
	* Required parameters: n/a		Subtype name: kb+jwt
	* Optional parameters: n/a
	* Encoding considerations: binary; A Key Binding JWT is a JWT; JWT		Required parameters: n/a
			Optional parameters: n/a
			Encoding considerations: binary; A Key Binding JWT is a JWT; JWT
	values are encoded as a series of base64url-encoded values		values are encoded as a series of base64url-encoded values
	separated by period ('.') characters.		separated by period ('.') characters.
	* Security considerations: See the Security Considerations section		Security considerations: See the Security Considerations sections of
	of [[ this specification ]], [RFC7519], and [RFC8725].		RFC 9901, [RFC7519], and [RFC8725].
	* Interoperability considerations: n/a
	* Published specification: [[ this specification ]]		Interoperability considerations: n/a
	* Applications that use this media type: Applications utilizing a
	JWT based proof of possession mechanism.		Published specification: RFC 9901
	* Fragment identifier considerations: n/a
	* Additional information:		Applications that use this media type: Applications utilizing a JWT-
	- Magic number(s): n/a		based proof-of-possession mechanism.
	- File extension(s): n/a
	- Macintosh file type code(s): n/a		Fragment identifier considerations: n/a
	* Person & email address to contact for further information: Daniel
			Additional information:
			Magic number(s): n/a
			File extension(s): n/a
			Macintosh file type code(s): n/a
			Person & email address to contact for further information: Daniel
	Fett, mail@danielfett.de		Fett, mail@danielfett.de
	* Intended usage: COMMON
	* Restrictions on usage: none
	* Author: Daniel Fett, mail@danielfett.de
	* Change Controller: IETF
	* Provisional registration? No
	12.3. Structured Syntax Suffix Registration		Intended usage: COMMON
	This section requests registration of the "+sd-jwt" structured syntax		Restrictions on usage: none
	suffix in the "Structured Syntax Suffix" registry
	[IANA.StructuredSuffix] in the manner described in [RFC6838], which
	can be used to indicate that the media type is encoded as an SD-JWT.
	* Name: SD-JWT		Author: Daniel Fett, mail@danielfett.de
	* +suffix: +sd-jwt
	* References: [[ this specification ]]		Change Controller: IETF
	* Encoding considerations: binary; SD-JWT values are a series of
			11.3. Structured Syntax Suffixes Registration
			IANA has registered "+sd-jwt" in the "Structured Syntax Suffixes"
			registry [StructuredSuffix] in the manner described in [RFC6838],
			which can be used to indicate that the media type is encoded as an
			SD-JWT.
			Name: SD-JWT
			+suffix: +sd-jwt
			References: RFC 9901
			Encoding considerations: binary; SD-JWT values are a series of
	base64url-encoded values (some of which may be the empty string)		base64url-encoded values (some of which may be the empty string)
	separated by period ('.') or tilde ('~') characters.		separated by period ('.') or tilde ('~') characters.
	* Interoperability considerations: n/a		Interoperability considerations: n/a
	* Fragment identifier considerations: n/a		Fragment identifier considerations: n/a
	* Security considerations: See the Security Considerations section		Security considerations: See the Security Considerations sections of
	of [[ this specification ]], [RFC7519], and [RFC8725].		RFC 9901, [RFC7519], and [RFC8725].
	* Contact: Daniel Fett, mail@danielfett.de		Contact: Daniel Fett, mail@danielfett.de
	* Author/Change controller: IETF		Author/Change controller: IETF
	13. References		12. References
	13.1. Normative References		12.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
			Specifications: ABNF", STD 68, RFC 5234,
			DOI 10.17487/RFC5234, January 2008,
			<https://www.rfc-editor.org/info/rfc5234>.
	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type		[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Specifications and Registration Procedures", BCP 13,		Specifications and Registration Procedures", BCP 13,
	RFC 6838, DOI 10.17487/RFC6838, January 2013,		RFC 6838, DOI 10.17487/RFC6838, January 2013,
	<https://www.rfc-editor.org/info/rfc6838>.		<https://www.rfc-editor.org/info/rfc6838>.
	[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web		[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
	Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May		Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
	2015, <https://www.rfc-editor.org/info/rfc7515>.		2015, <https://www.rfc-editor.org/info/rfc7515>.
	[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",		[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
	skipping to change at page 55, line 36 ¶		skipping to change at line 2799 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best		[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
	Current Practices", BCP 225, RFC 8725,		Current Practices", BCP 225, RFC 8725,
	DOI 10.17487/RFC8725, February 2020,		DOI 10.17487/RFC8725, February 2020,
	<https://www.rfc-editor.org/info/rfc8725>.		<https://www.rfc-editor.org/info/rfc8725>.
	13.2. Informative References		12.2. Informative References
	[CL01] Camenisch, J. and A. Lysyanskaya, "An Efficient System for		[CL01] Camenisch, J. and A. Lysyanskaya, "An Efficient System for
	Non-Transferable Anonymous Credentials with Optional		Non-Transferable Anonymous Credentials with Optional
	Anonymity Revocation", Proceedings of the International		Anonymity Revocation", Cryptology ePrint Archive, Paper
	Conference on the Theory and Application of Cryptographic		2001/019, 2001, <https://eprint.iacr.org/2001/019.pdf>.
	Techniques (EUROCRYPT) 2001, 2001,
	<https://eprint.iacr.org/2001/019.pdf>.
	[EUDIW.ARF]		[EUDIW.ARF]
	Commission, E., "The European Digital Identity Wallet		European Commission, "The European Digital Identity Wallet
	Architecture and Reference Framework", <https://eu-		Architecture and Reference Framework", <https://eu-
	digital-identity-wallet.github.io/eudi-doc-architecture-		digital-identity-wallet.github.io/eudi-doc-architecture-
	and-reference-framework>.		and-reference-framework>.
	[I-D.ietf-oauth-sd-jwt-vc]		[Hash.Algs]
	Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based		IANA, "Named Information Hash Algorithm Registry",
	Verifiable Credentials (SD-JWT VC)", Work in Progress,		<https://www.iana.org/assignments/named-information>.
	Internet-Draft, draft-ietf-oauth-sd-jwt-vc-08, 3 December
	2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
	oauth-sd-jwt-vc-08>.
	[I-D.ietf-oauth-status-list]
	Looker, T., Bastian, P., and C. Bormann, "Token Status
	List", Work in Progress, Internet-Draft, draft-ietf-oauth-
	status-list-11, 23 May 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
	status-list-11>.
	[I-D.ietf-spice-sd-cwt]
	Prorock, M., Steele, O., Birkholz, H., and R. Mahy, "SPICE
	SD-CWT", Work in Progress, Internet-Draft, draft-ietf-
	spice-sd-cwt-03, 2 March 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-spice-
	sd-cwt-03>.
	[IANA.Hash.Algorithms]		[ISO.18013-5]
	IANA, "Named Information Hash Algorithm",		ISO/IEC, "Personal identification - ISO-compliant driving
	<https://www.iana.org/assignments/named-information/named-		license — Part 5: Mobile driving license (mDL)
	information.xhtml>.		application", ISO/IEC 18013-5:2021, September 2021,
			<https://www.iso.org/standard/69084.html>.
	[IANA.JWS.Algorithms]		[JWS.Algs] IANA, "JSON Web Signature and Encryption Algorithms",
	IANA, "JSON Web Signature and Encryption Algorithms",		<https://www.iana.org/assignments/jose>.
	<https://www.iana.org/assignments/jose/jose.xhtml#web-
	signature-encryption-algorithms>.
	[IANA.JWT] IANA, "JSON Web Token Claims",		[JWT.Claims]
			IANA, "JSON Web Token Claims",
	<https://www.iana.org/assignments/jwt>.		<https://www.iana.org/assignments/jwt>.
	[IANA.MediaTypes]		[MediaTypes]
	IANA, "Media Types", <https://www.iana.org/assignments/		IANA, "Media Types",
	media-types/media-types.xhtml>.		<https://www.iana.org/assignments/media-types>.
	[IANA.StructuredSuffix]
	IANA, "Structured Syntax Suffixs",
	<https://www.iana.org/assignments/media-type-structured-
	suffix/media-type-structured-suffix.xhtml>.
	[ISO.18013-5]
	ISO/IEC JTC 1/SC 17 Cards and security devices for
	personal identification, "ISO/IEC 18013-5:2021 Personal
	identification — ISO-compliant driving license — Part 5:
	Mobile driving license (mDL) application", 2021,
	<https://www.iso.org/standard/69084.html>.
	[NIST.SP.800-57pt1r5]		[NIST.SP.800-57pt1r5]
	Barker, E. and NIST, "Recommendation for key		Barker, E., "Recommendation for Key Management: Part 1 -
	management:part 1 - general", NIST Special Publications		General", NIST SP 800-57pt1r5,
	(General) 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5,		DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
	May 2020,
	<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/		<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
	NIST.SP.800-57pt1r5.pdf>.		NIST.SP.800-57pt1r5.pdf>.
	[OIDC.IDA] Lodderstedt, T., Fett, D., Haine, M., Pulido, A., Lehmann,		[OIDC.IDA] Lodderstedt, T., Fett, D., Haine, M., Pulido, A., Lehmann,
	K., and K. Koiwai, "OpenID Connect for Identity Assurance		K., and K. Koiwai, "OpenID Connect for Identity Assurance
	1.0", 24 July 2024, <https://openid.net/specs/openid-		1.0", 1 October 2024, <https://openid.net/specs/openid-
	connect-4-identity-assurance-1_0.html>.		connect-4-identity-assurance-1_0.html>.
	[OpenID.Core]		[OpenID.Core]
	Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and		Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
	C. Mortimore, "OpenID Connect Core 1.0 incorporating		C. Mortimore, "OpenID Connect Core 1.0 incorporating
	errata set 2", 15 December 2023,		errata set 2", 15 December 2023,
	<https://openid.net/specs/openid-connect-core-1_0.html>.		<https://openid.net/specs/openid-connect-core-1_0.html>.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	DOI 10.17487/RFC2046, November 1996,		DOI 10.17487/RFC2046, November 1996,
	<https://www.rfc-editor.org/info/rfc2046>.		<https://www.rfc-editor.org/info/rfc2046>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.
	[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,		[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
	DOI 10.17487/RFC7517, May 2015,		DOI 10.17487/RFC7517, May 2015,
	<https://www.rfc-editor.org/info/rfc7517>.		<https://www.rfc-editor.org/info/rfc7517>.
	[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON		[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
	Canonicalization Scheme (JCS)", RFC 8785,		Canonicalization Scheme (JCS)", RFC 8785,
	DOI 10.17487/RFC8785, June 2020,		DOI 10.17487/RFC8785, June 2020,
	<https://www.rfc-editor.org/info/rfc8785>.		<https://www.rfc-editor.org/info/rfc8785>.
			[SD-CWT] Prorock, M., Steele, O., Birkholz, H., and R. Mahy,
			"Selective Disclosure CBOR Web Tokens (SD-CWT)", Work in
			Progress, Internet-Draft, draft-ietf-spice-sd-cwt-05, 20
			October 2025, <https://datatracker.ietf.org/doc/html/
			draft-ietf-spice-sd-cwt-05>.
			[SD-JWT-VC]
			Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based
			Verifiable Credentials (SD-JWT VC)", Work in Progress,
			Internet-Draft, draft-ietf-oauth-sd-jwt-vc-13, 6 November
			2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
			oauth-sd-jwt-vc-13>.
			[StructuredSuffix]
			IANA, "Structured Syntax Suffixes",
			<https://www.iana.org/assignments/media-type-structured-
			suffix>.
			[TSL] Looker, T., Bastian, P., and C. Bormann, "Token Status
			List (TSL)", Work in Progress, Internet-Draft, draft-ietf-
			oauth-status-list-13, 20 October 2025,
			<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
			status-list-13>.
	[VC_DATA_v2.0]		[VC_DATA_v2.0]
	Sporny, M., Jr, T. T., Jones, M. B., Cohen, G., and I.		Sporny, M., Ed., Thiboeau, T., Ed., Jones, M. B., Ed.,
	Herman, "Verifiable Credentials Data Model 2.0", May 2025,		Cohen, G., Ed., and I. Herman, Ed., "Verifiable
			Credentials Data Model 2.0", W3C Recommendation, May 2025,
	<https://www.w3.org/TR/vc-data-model-2.0/>.		<https://www.w3.org/TR/vc-data-model-2.0/>.
	Appendix A. Additional Examples		Appendix A. Additional Examples
	The following examples are not normative and are provided for		The following examples are not normative and are provided for
	illustrative purposes only. In particular, neither the structure of		illustrative purposes only. In particular, neither the structure of
	the claims nor the selection of selectively disclosable claims is		the claims nor the selection of selectively disclosable claims is
	normative.		normative.
	Line breaks have been added for readability.		Line breaks have been added for readability.
	A.1. Simple Structured SD-JWT		A.1. Simple Structured SD-JWT
	In this example, in contrast to Section 5, the Issuer decided to		In this example, in contrast to Section 5, the Issuer decided to
	create a structured object for the address claim, allowing to		create a structured object for the address claim, allowing individual
	separately disclose individual members of the claim.		members of the claim to be disclosed separately.
	The following data about the user comprises the input JWT Claims Set		The following data about the user comprises the input JWT Claims Set
	used by the Issuer:		used by the Issuer:
	{		{
	"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",
	skipping to change at page 59, line 39 ¶		skipping to change at line 2972 ¶
	]		]
	},		},
	"_sd_alg": "sha-256"		"_sd_alg": "sha-256"
	}		}
	The digests in the SD-JWT payload reference the following		The digests in the SD-JWT payload reference the following
	Disclosures:		Disclosures:
	*Claim sub*:		*Claim sub*:
	* SHA-256 Hash: X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g		* SHA-256 Hash:
			X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g
	* Disclosure:		* Disclosure:
	WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1i
	NTg5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ		WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1iNTg5LT
	* Contents: ["2GLC42sKQveCfGfryNRN9w", "sub",		QzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ
	"6c5c0a49-b589-431d-bae7-219122a9ec2c"]
			* Contents:
			["2GLC42sKQveCfGfryNRN9w", "sub", "6c5c0a49-b589-431d-
			bae7-219122a9ec2c"]
	*Claim given_name*:		*Claim given_name*:
	* SHA-256 Hash: ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q		* SHA-256 Hash:
			ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q
	* Disclosure:		* Disclosure:
	WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1
	OTJhXHU5MGNlIl0		WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1OTJhXH
	* Contents: ["eluV5Og3gSNII8EYnsxA_A", "given_name", "\u592a\u90ce"]		U5MGNlIl0
			* Contents:
			["eluV5Og3gSNII8EYnsxA_A", "given_name", "\u592a\u90ce"]
	*Claim family_name*:		*Claim family_name*:
	* SHA-256 Hash: C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU		* SHA-256 Hash:
			C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU
	* Disclosure:		* Disclosure:
	WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1
	NWM3MVx1NzUzMCJd		WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1NWM3MV
	* Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "family_name",		x1NzUzMCJd
	"\u5c71\u7530"]
			* Contents:
			["6Ij7tM-a5iVPGboS5tmvVA", "family_name", "\u5c71\u7530"]
	*Claim email*:		*Claim email*:
	* SHA-256 Hash: Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE		* SHA-256 Hash:
			Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE
	* Disclosure:		* Disclosure:
	WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3Vh
	bCBlbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd		WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3VhbCBlbW
	* Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual email		FpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd
			* Contents:
			["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual email
	address\"@example.jp"]		address\"@example.jp"]
	*Claim phone_number*:		*Claim phone_number*:
	* SHA-256 Hash: s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U		* SHA-256 Hash:
			s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U
	* Disclosure:		* Disclosure:
	WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIr
	ODEtODAtMTIzNC01Njc4Il0		WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIrODEtOD
	* Contents: ["Qg_O64zqAxe412a108iroA", "phone_number",		AtMTIzNC01Njc4Il0
	"+81-80-1234-5678"]
			* Contents:
			["Qg_O64zqAxe412a108iroA", "phone_number", "+81-80-1234-5678"]
	*Claim street_address*:		*Claim street_address*:
	* SHA-256 Hash: 6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E		* SHA-256 Hash:
			6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E
	* Disclosure:		* Disclosure:
	WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwg
	Ilx1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1		WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwgIlx1Nj
	NTcxMlx1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd		c3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1NTcxMlx1ZmYx
	* Contents: ["AJx-095VPrpTtN4QMOqROA", "street_address",		NFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd
	"\u6771\u4eac\u
	90fd\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u		* Contents:
	2212\uff18"]
			["AJx-095VPrpTtN4QMOqROA", "street_address", "\u6771\u4eac\u90fd\u
			6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u2212\uff18"]
	*Claim locality*:		*Claim locality*:
	* SHA-256 Hash: rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA		* SHA-256 Hash:
			rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA
	* Disclosure:		* Disclosure:
	WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3
	MVx1NGVhY1x1OTBmZCJd		WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3MVx1NG
	* Contents: ["Pc33JM2LchcU_lHggv_ufQ", "locality",		VhY1x1OTBmZCJd
	"\u6771\u4eac\u90fd"]
			* Contents:
			["Pc33JM2LchcU_lHggv_ufQ", "locality", "\u6771\u4eac\u90fd"]
	*Claim region*:		*Claim region*:
	* SHA-256 Hash: PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k		* SHA-256 Hash:
			PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k
	* Disclosure:		* Disclosure:
	WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZc
	dTUzM2EiXQ		WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZcdTUzM2
	* Contents: ["G02NSrQfjFXQ7Io09syajA", "region", "\u6e2f\u533a"]		EiXQ
			* Contents:
			["G02NSrQfjFXQ7Io09syajA", "region", "\u6e2f\u533a"]
	*Claim country*:		*Claim country*:
	* SHA-256 Hash: uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4		* SHA-256 Hash:
			uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4
	* Disclosure:		* Disclosure:
	WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ		WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ
	* Contents: ["lklxF5jMYlGTPUovMNIvCA", "country", "JP"]
			* Contents:
			["lklxF5jMYlGTPUovMNIvCA", "country", "JP"]
	*Claim birthdate*:		*Claim birthdate*:
	* SHA-256 Hash: MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY		* SHA-256 Hash:
			MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY
	* Disclosure:		* Disclosure:
	WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQw
	LTAxLTAxIl0		WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLT
	* Contents: ["yytVbdAPGcgl2rI4C9GSog", "birthdate", "1940-01-01"]		AxIl0
			* Contents:
			["yytVbdAPGcgl2rI4C9GSog", "birthdate", "1940-01-01"]
	The following decoy digests are added:		The following decoy digests are added:
	* AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg		* AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg
	* cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ		* cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ
	* glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4		* glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4
	* b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek		* b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek
	* fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs		* fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs
	* Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE		* Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE
	The following is a presentation of the SD-JWT that discloses only		The following is a presentation of the SD-JWT that discloses only
	region and country of the address property:		region and country of the address property:
	eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb		eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
	IkM5aW5wNllvUmFFWFI0Mjd6WUpQN1FyazFXSF84YmR3T0FfWVVyVW5HUVUiLCAiS3Vl		IkM5aW5wNllvUmFFWFI0Mjd6WUpQN1FyazFXSF84YmR3T0FfWVVyVW5HUVUiLCAiS3Vl
	dDF5QWEwSElRdlluT1ZkNTloY1ZpTzlVZzZKMmtTZnFZUkJlb3d2RSIsICJNTWxkT0ZG		dDF5QWEwSElRdlluT1ZkNTloY1ZpTzlVZzZKMmtTZnFZUkJlb3d2RSIsICJNTWxkT0ZG
	ekIyZDB1bWxtcFRJYUdlcmhXZFVfUHBZZkx2S2hoX2ZfOWFZIiwgIlg2WkFZT0lJMnZQ		ekIyZDB1bWxtcFRJYUdlcmhXZFVfUHBZZkx2S2hoX2ZfOWFZIiwgIlg2WkFZT0lJMnZQ
	TjQwVjd4RXhad1Z3ejd5Um1MTmNWd3Q1REw4Ukx2NGciLCAiWTM0em1JbzBRTExPdGRN		TjQwVjd4RXhad1Z3ejd5Um1MTmNWd3Q1REw4Ukx2NGciLCAiWTM0em1JbzBRTExPdGRN
	skipping to change at page 64, line 47 ¶		skipping to change at line 3276 ¶
	}		}
	},		},
	"_sd_alg": "sha-256"		"_sd_alg": "sha-256"
	}		}
	The digests in the SD-JWT payload reference the following		The digests in the SD-JWT payload reference the following
	Disclosures:		Disclosures:
	*Claim time*:		*Claim time*:
	* SHA-256 Hash: vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw		* SHA-256 Hash:
			vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw
	* Disclosure:		* Disclosure:
	WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0y
	M1QxODoyNVoiXQ		WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1QxOD
	* Contents: ["2GLC42sKQveCfGfryNRN9w", "time", "2012-04-23T18:25Z"]		oyNVoiXQ
			* Contents:
			["2GLC42sKQveCfGfryNRN9w", "time", "2012-04-23T18:25Z"]
	*Claim verification_process*:		*Claim verification_process*:
	* SHA-256 Hash: 7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc		* SHA-256 Hash:
			7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc
	* Disclosure:		* Disclosure:
	WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9j
	ZXNzIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ		WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9jZXNzIi
	* Contents: ["eluV5Og3gSNII8EYnsxA_A", "verification_process",		wgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ
	"f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"]
			* Contents:
			["eluV5Og3gSNII8EYnsxA_A", "verification_process", "f24c6f-6d3f-
			4ec5-973e-b0d8506f3bc7"]
	*Claim type*:		*Claim type*:
	* SHA-256 Hash: G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk		* SHA-256 Hash:
			G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk
	* Disclosure:		* Disclosure:
	WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQi
	XQ		WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQiXQ
	* Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "type", "document"]
			* Contents:
			["6Ij7tM-a5iVPGboS5tmvVA", "type", "document"]
	*Claim method*:		*Claim method*:
	* SHA-256 Hash: WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ		* SHA-256 Hash:
			WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ
	* Disclosure:		* Disclosure:
	WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0		WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0
	* Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "method", "pipp"]
			* Contents:
			["eI8ZWm9QnKPpNPeNenHdhQ", "method", "pipp"]
	*Claim time*:		*Claim time*:
	* SHA-256 Hash: 9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI		* SHA-256 Hash:
			9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI
	* Disclosure:		* Disclosure:
	WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0y
	MlQxMTozMFoiXQ		WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0yMlQxMT
	* Contents: ["Qg_O64zqAxe412a108iroA", "time", "2012-04-22T11:30Z"]		ozMFoiXQ
			* Contents:
			["Qg_O64zqAxe412a108iroA", "time", "2012-04-22T11:30Z"]
	*Claim document*:		*Claim document*:
	* SHA-256 Hash: IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4		* SHA-256 Hash:
			IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4
	* Disclosure:		* Disclosure:
	WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBl
	IjogImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1		WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBlIjogIm
	cmciLCAiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0Iiwg		lkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1cmciLCAiY291
	ImRhdGVfb2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4		bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0IiwgImRhdGVfb2ZfaXNzdW
	cGlyeSI6ICIyMDIwLTAzLTIyIn1d		FuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4cGlyeSI6ICIyMDIwLTAzLTIy
	* Contents: ["AJx-095VPrpTtN4QMOqROA", "document", {"type":		In1d
	"idcard",
	"issuer": {"name": "Stadt Augsburg", "country": "DE"},		* Contents:
	"number": "53554554", "date_of_issuance": "2010-03-23",
	"date_of_expiry": "2020-03-22"}]		["AJx-095VPrpTtN4QMOqROA", "document", {"type": "idcard",
			"issuer": {"name": "Stadt Augsburg", "country": "DE"}, "number":
			"53554554", "date_of_issuance": "2010-03-23", "date_of_expiry":
			"2020-03-22"}]
	*Array Entry*:		*Array Entry*:
	* SHA-256 Hash: tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k		* SHA-256 Hash:
			tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k
	* Disclosure:		* Disclosure:
	WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1
	RDdQSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhP		WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDdQSz
	QU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdG		Buc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZR
	cldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldw		TU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdGcldVQjYzUmNacTl5dm
	eFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d		daMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURz
	* Contents: ["Pc33JM2LchcU_lHggv_ufQ", {"_sd":		bEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d
			* Contents:
			["Pc33JM2LchcU_lHggv_ufQ", {"_sd":
	["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI",		["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI",
	"G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk",		"G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk",
	"IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4",		"IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4",
	"WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]		"WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]
	*Claim given_name*:		*Claim given_name*:
	* SHA-256 Hash: S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo		* SHA-256 Hash:
			S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo
	* Disclosure:		* Disclosure:
	WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4
	Il0		WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0
	* Contents: ["G02NSrQfjFXQ7Io09syajA", "given_name", "Max"]
			* Contents:
			["G02NSrQfjFXQ7Io09syajA", "given_name", "Max"]
	*Claim family_name*:		*Claim family_name*:
	* SHA-256 Hash: Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk		* SHA-256 Hash:
			Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk
	* Disclosure:		* Disclosure:
	WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1c
	dTAwZmNsbGVyIl0		WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTAwZm
	* Contents: ["lklxF5jMYlGTPUovMNIvCA", "family_name", "M\u00fcller"]		NsbGVyIl0
			* Contents:
			["lklxF5jMYlGTPUovMNIvCA", "family_name", "M\u00fcller"]
	*Claim nationalities*:		*Claim nationalities*:
	* SHA-256 Hash: hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE		* SHA-256 Hash:
			hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE
	* Disclosure:		* Disclosure:
	WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBb
	IkRFIl1d		WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl
	* Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]		1d
			* Contents:
			["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]
	*Claim birthdate*:		*Claim birthdate*:
	* SHA-256 Hash: WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk		* SHA-256 Hash:
			WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk
	* Disclosure:		* Disclosure:
	WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2
	LTAxLTI4Il0		WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2LTAxLT
	* Contents: ["5bPs1IquZNa0hkaFzzzZNw", "birthdate", "1956-01-28"]		I4Il0
			* Contents:
			["5bPs1IquZNa0hkaFzzzZNw", "birthdate", "1956-01-28"]
	*Claim place_of_birth*:		*Claim place_of_birth*:
	* SHA-256 Hash: RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo		* SHA-256 Hash:
			RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo
	* Disclosure:		* Disclosure:
	WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwg
	eyJjb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1		WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwgeyJjb3
	MDBlNmphcmtsYXVzdHVyIn1d		VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1MDBlNmphcmts
	* Contents: ["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", {"country":		YXVzdHVyIn1d
	"IS", "locality": "\u00deykkvab\u00e6jarklaustur"}]
			* Contents:
			["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", {"country": "IS",
			"locality": "\u00deykkvab\u00e6jarklaustur"}]
	*Claim address*:		*Claim address*:
	* SHA-256 Hash: _O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ		* SHA-256 Hash:
			_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ
	* Disclosure:		* Disclosure:
	WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2Fs
	aXR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNv		WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2FsaXR5Ij
	dW50cnkiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1		ogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiOiAi
	MDBkZmUgMjIifV0		REUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0
	* Contents: ["y1sVU5wdfJahVdgwPgS7RQ", "address", {"locality":
	"Maxstadt", "postal_code": "12344", "country": "DE",		* Contents:
	"street_address": "Weidenstra\u00dfe 22"}]
			["y1sVU5wdfJahVdgwPgS7RQ", "address", {"locality": "Maxstadt",
			"postal_code": "12344", "country": "DE", "street_address":
			"Weidenstra\u00dfe 22"}]
	*Claim birth_middle_name*:		*Claim birth_middle_name*:
	* SHA-256 Hash: otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI		* SHA-256 Hash:
			otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI
	* Disclosure:		* Disclosure:
	WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1l
	IiwgIlRpbW90aGV1cyJd		WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1lIiwgIl
	* Contents: ["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name",		RpbW90aGV1cyJd
	"Timotheus"]
			* Contents:
			["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name", "Timotheus"]
	*Claim salutation*:		*Claim salutation*:
	* SHA-256 Hash: -aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw		* SHA-256 Hash:
			-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw
	* Disclosure:		* Disclosure:
	WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIu
	Il0		WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIuIl0
	* Contents: ["C9GSoujviJquEgYfojCb1A", "salutation", "Dr."]
			* Contents:
			["C9GSoujviJquEgYfojCb1A", "salutation", "Dr."]
	*Claim msisdn*:		*Claim msisdn*:
	* SHA-256 Hash: IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg		* SHA-256 Hash:
			IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg
	* Disclosure:		* Disclosure:
	WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1
	Njc4OSJd		WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1Njc4OS
	* Contents: ["kx5kF17V-x0JmwUx9vgvtw", "msisdn", "49123456789"]		Jd
			* Contents:
			["kx5kF17V-x0JmwUx9vgvtw", "msisdn", "49123456789"]
	The following is a presentation of the SD-JWT:		The following is a presentation of the SD-JWT:
	eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb		eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
	Ii1hU3puSWQ5bVdNOG9jdVFvbENsbHN4VmdncTEtdkhXNE90bmhVdFZtV3ciLCAiSUti		Ii1hU3puSWQ5bVdNOG9jdVFvbENsbHN4VmdncTEtdkhXNE90bmhVdFZtV3ciLCAiSUti
	cllObjN2QTdXRUZyeXN2YmRCSmpERFVfRXZRSXIwVzE4dlRScFVTZyIsICJvdGt4dVQx		cllObjN2QTdXRUZyeXN2YmRCSmpERFVfRXZRSXIwVzE4dlRScFVTZyIsICJvdGt4dVQx
	NG5CaXd6TkozTVBhT2l0T2w5cFZuWE9hRUhhbF94a3lOZktJIl0sICJpc3MiOiAiaHR0		NG5CaXd6TkozTVBhT2l0T2w5cFZuWE9hRUhhbF94a3lOZktJIl0sICJpc3MiOiAiaHR0
	cHM6Ly9pc3N1ZXIuZXhhbXBsZS5jb20iLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6		cHM6Ly9pc3N1ZXIuZXhhbXBsZS5jb20iLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6
	IDE4ODMwMDAwMDAsICJ2ZXJpZmllZF9jbGFpbXMiOiB7InZlcmlmaWNhdGlvbiI6IHsi		IDE4ODMwMDAwMDAsICJ2ZXJpZmllZF9jbGFpbXMiOiB7InZlcmlmaWNhdGlvbiI6IHsi
	X3NkIjogWyI3aDRVRTlxU2N2REtvZFhWQ3VvS2ZLQkpwVkJmWE1GX1RtQUdWYVplM1Nj		X3NkIjogWyI3aDRVRTlxU2N2REtvZFhWQ3VvS2ZLQkpwVkJmWE1GX1RtQUdWYVplM1Nj
	skipping to change at page 69, line 32 ¶		skipping to change at line 3591 ¶
	"address": {		"address": {
	"locality": "Maxstadt",		"locality": "Maxstadt",
	"postal_code": "12344",		"postal_code": "12344",
	"country": "DE",		"country": "DE",
	"street_address": "Weidenstraße 22"		"street_address": "Weidenstraße 22"
	}		}
	}		}
	}		}
	}		}
	A.3. SD-JWT-based Verifiable Credentials (SD-JWT VC)		A.3. SD-JWT-Based Verifiable Credentials (SD-JWT VC)
	This example shows how the artifacts defined in this specification		This example shows how the artifacts defined in this specification
	could be used in the context of SD-JWT-based Verifiable Credentials		could be used in the context of SD-JWT-based Verifiable Credentials
	(SD-JWT VC) [I-D.ietf-oauth-sd-jwt-vc] to represent the concept of a		(SD-JWT VC) [SD-JWT-VC] to represent the concept of a Person
	Person Identification Data (PID) as defined in the "PID Rulebook" in		Identification Data (PID) as defined in the "PID Rulebook" in
	[EUDIW.ARF]. This example uses fictional data of a German citizen.		[EUDIW.ARF]. This example uses fictional data of a German citizen.
	Key Binding is applied using the Holder's public key passed in a cnf		Key Binding is applied using the Holder's public key passed in a cnf
	claim in the SD-JWT.		claim in the SD-JWT.
	The following citizen data is the input JWT Claims Set:		The following citizen data is the input JWT Claims Set:
	{		{
	"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",
	skipping to change at page 72, line 47 ¶		skipping to change at line 3743 ¶
	"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"		"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
	}		}
	}		}
	}		}
	The digests in the SD-JWT payload reference the following		The digests in the SD-JWT payload reference the following
	Disclosures:		Disclosures:
	*Claim given_name*:		*Claim given_name*:
	* SHA-256 Hash: 0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg		* SHA-256 Hash:
			0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg
	* Disclosure:		* Disclosure:
	WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJp
	a2EiXQ		WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJpa2EiXQ
	* Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]
			* Contents:
			["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]
	*Claim family_name*:		*Claim family_name*:
	* SHA-256 Hash: I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc		* SHA-256 Hash:
			I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc
	* Disclosure:		* Disclosure:
	WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11
	c3Rlcm1hbm4iXQ		WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11c3Rlcm
	* Contents: ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Mustermann"]		1hbm4iXQ
			* Contents:
			["eluV5Og3gSNII8EYnsxA_A", "family_name", "Mustermann"]
	*Claim birthdate*:		*Claim birthdate*:
	* SHA-256 Hash: Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg		* SHA-256 Hash:
			Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg
	* Disclosure:		* Disclosure:
	WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYz
	LTA4LTEyIl0		WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA4LT
	* Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1963-08-12"]		EyIl0
			* Contents:
			["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1963-08-12"]
	*Claim street_address*:		*Claim street_address*:
	* SHA-256 Hash: ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8		* SHA-256 Hash:
			ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8
	* Disclosure:		* Disclosure:
	WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwg
	IkhlaWRlc3RyYVx1MDBkZmUgMTciXQ		WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwgIkhlaW
	* Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "street_address",		Rlc3RyYVx1MDBkZmUgMTciXQ
	"Heidestra\u00dfe 17"]
			* Contents:
			["eI8ZWm9QnKPpNPeNenHdhQ", "street_address", "Heidestra\u00dfe
			17"]
	*Claim locality*:		*Claim locality*:
	* SHA-256 Hash: D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k		* SHA-256 Hash:
			D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k
	* Disclosure:		* Disclosure:
	WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAw
	ZjZsbiJd		WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAwZjZsbi
	* Contents: ["Qg_O64zqAxe412a108iroA", "locality", "K\u00f6ln"]		Jd
			* Contents:
			["Qg_O64zqAxe412a108iroA", "locality", "K\u00f6ln"]
	*Claim postal_code*:		*Claim postal_code*:
	* SHA-256 Hash: xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I		* SHA-256 Hash:
			xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I
	* Disclosure:		* Disclosure:
	WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUx
	MTQ3Il0		WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUxMTQ3Il
	* Contents: ["AJx-095VPrpTtN4QMOqROA", "postal_code", "51147"]		0
			* Contents:
			["AJx-095VPrpTtN4QMOqROA", "postal_code", "51147"]
	*Claim country*:		*Claim country*:
	* SHA-256 Hash: eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0		* SHA-256 Hash:
			eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0
	* Disclosure:		* Disclosure:
	WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ		WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ
	* Contents: ["Pc33JM2LchcU_lHggv_ufQ", "country", "DE"]
			* Contents:
			["Pc33JM2LchcU_lHggv_ufQ", "country", "DE"]
	*Claim address*:		*Claim address*:
	* SHA-256 Hash: RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM		* SHA-256 Hash:
			RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM
	* Disclosure:		* Disclosure:
	WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6
	IFsiQUxaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3		WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiQU
	OCIsICJEX19XX3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNf		xaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3OCIsICJEX19X
	dzlrIiwgImVCcENYVTFKNWRoSDJnNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZ		X3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNfdzlrIiwgImVCcENYVT
	b1BobzAiLCAieE9QeTktZ0pBTEs2VWJXS0ZMUjg1Y09CeVVEM0FiTndGZzNJ		FKNWRoSDJnNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZb1BobzAiLCAieE9QeTktZ0pB
	M1lmUUVfSSJdfV0		TEs2VWJXS0ZMUjg1Y09CeVVEM0FiTndGZzNJM1lmUUVfSSJdfV0
	* Contents: ["G02NSrQfjFXQ7Io09syajA", "address", {"_sd":
			* Contents:
			["G02NSrQfjFXQ7Io09syajA", "address", {"_sd":
	["ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8",		["ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8",
	"D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k",		"D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k",
	"eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0",		"eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0",
	"xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I"]}]		"xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I"]}]
	*Claim nationalities*:		*Claim nationalities*:
	* SHA-256 Hash: y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU		* SHA-256 Hash:
			y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU
	* Disclosure:		* Disclosure:
	WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBb
	IkRFIl1d		WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl
	* Contents: ["lklxF5jMYlGTPUovMNIvCA", "nationalities", ["DE"]]		1d
			* Contents:
			["lklxF5jMYlGTPUovMNIvCA", "nationalities", ["DE"]]
	*Claim sex*:		*Claim sex*:
	* SHA-256 Hash: 90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk		* SHA-256 Hash:
			90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk
	* Disclosure:		* Disclosure:
	WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgInNleCIsIDJd		WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgInNleCIsIDJd
	* Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "sex", 2]
			* Contents:
			["nPuoQnkRFq3BIeAm7AnXFA", "sex", 2]
	*Claim birth_family_name*:		*Claim birth_family_name*:
	* SHA-256 Hash: KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA		* SHA-256 Hash:
			KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA
	* Disclosure:		* Disclosure:
	WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX2ZhbWlseV9uYW1l
	IiwgIkdhYmxlciJd		WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX2ZhbWlseV9uYW1lIiwgIk
	* Contents: ["5bPs1IquZNa0hkaFzzzZNw", "birth_family_name",		dhYmxlciJd
	"Gabler"]
			* Contents:
			["5bPs1IquZNa0hkaFzzzZNw", "birth_family_name", "Gabler"]
	*Claim locality*:		*Claim locality*:
	* SHA-256 Hash: KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE		* SHA-256 Hash:
			KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE
	* Disclosure:		* Disclosure:
	WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImxvY2FsaXR5IiwgIkJlcmxp
	biJd		WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImxvY2FsaXR5IiwgIkJlcmxpbiJd
	* Contents: ["5a2W0_NrlEZzfqmk_7Pq-w", "locality", "Berlin"]
			* Contents:
			["5a2W0_NrlEZzfqmk_7Pq-w", "locality", "Berlin"]
	*Claim country*:		*Claim country*:
	* SHA-256 Hash: YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ		* SHA-256 Hash:
			YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ
	* Disclosure:		* Disclosure:
	WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImNvdW50cnkiLCAiREUiXQ		WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImNvdW50cnkiLCAiREUiXQ
	* Contents: ["y1sVU5wdfJahVdgwPgS7RQ", "country", "DE"]
			* Contents:
			["y1sVU5wdfJahVdgwPgS7RQ", "country", "DE"]
	*Claim place_of_birth*:		*Claim place_of_birth*:
	* SHA-256 Hash: 1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow		* SHA-256 Hash:
			1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow
	* Disclosure:		* Disclosure:
	WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwg
	eyJfc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BN		WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwgeyJfc2
	alphR2t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVa		QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BNalphR2t4QUUi
	Y2xGSFhmLVVTUSJdfV0		LCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVaY2xGSFhmLVVTUSJdfV
	* Contents: ["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd":		0
			* Contents:
			["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd":
	["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE",		["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE",
	"YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ"]}]		"YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ"]}]
	*Claim 12*:		*Claim 12*:
	* SHA-256 Hash: gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU		* SHA-256 Hash:
			gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU
	* Disclosure:		* Disclosure:
	WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0		WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0
	* Contents: ["C9GSoujviJquEgYfojCb1A", "12", true]
			* Contents:
			["C9GSoujviJquEgYfojCb1A", "12", true]
	*Claim 14*:		*Claim 14*:
	* SHA-256 Hash: y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI		* SHA-256 Hash:
			y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI
	* Disclosure:		* Disclosure:
	WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0		WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0
	* Contents: ["kx5kF17V-x0JmwUx9vgvtw", "14", true]
			* Contents:
			["kx5kF17V-x0JmwUx9vgvtw", "14", true]
	*Claim 16*:		*Claim 16*:
	* SHA-256 Hash: hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI		* SHA-256 Hash:
			hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI
	* Disclosure:		* Disclosure:
	WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0		WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0
	* Contents: ["H3o1uswP760Fi2yeGdVCEQ", "16", true]
			* Contents:
			["H3o1uswP760Fi2yeGdVCEQ", "16", true]
	*Claim 18*:		*Claim 18*:
	* SHA-256 Hash: CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg		* SHA-256 Hash:
			CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg
	* Disclosure:		* Disclosure:
	WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0		WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0
	* Contents: ["OBKlTVlvLg-AdwqYGbP8ZA", "18", true]
			* Contents:
			["OBKlTVlvLg-AdwqYGbP8ZA", "18", true]
	*Claim 21*:		*Claim 21*:
	* SHA-256 Hash: 1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk		* SHA-256 Hash:
			1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk
	* Disclosure:		* Disclosure:
	WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1ZV0		WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1ZV0
	* Contents: ["M0Jb57t41ubrkSuyrDT3xA", "21", true]
			* Contents:
			["M0Jb57t41ubrkSuyrDT3xA", "21", true]
	*Claim 65*:		*Claim 65*:
	* SHA-256 Hash: a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg		* SHA-256 Hash:
			a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg
	* Disclosure:		* Disclosure:
	WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd		WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd
	* Contents: ["DsmtKNgpV4dAHpjrcaosAw", "65", false]
			* Contents:
			["DsmtKNgpV4dAHpjrcaosAw", "65", false]
	*Claim age_equal_or_over*:		*Claim age_equal_or_over*:
	* SHA-256 Hash: 2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8		* SHA-256 Hash:
			2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8
	* Disclosure:		* Disclosure:
	WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVy
	IiwgeyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4		WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiwgey
	SFhBMHI1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lO		Jfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J3
	QTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96		a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3pSYW9ock1EZy
	ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4		IsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlczUkxwWEdnIiwg
	bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNl		ImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4bXUyLWtDRTctTmIyUXh1QlUiLCAiaH
	SVFBYUlkaHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFx		JZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlkaHJxVVhRTkNXYmZaSSIsICJ5NlNG
	alFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ		clZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ
	* Contents: ["eK5o5pHfgupPpltj1qhAJw", "age_equal_or_over", {"_sd":
			* Contents:
			["eK5o5pHfgupPpltj1qhAJw", "age_equal_or_over", {"_sd":
	["1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk",		["1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk",
	"CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg",		"CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg",
	"a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg",		"a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg",
	"gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU",		"gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU",
	"hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI",		"hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI",
	"y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI"]}]		"y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI"]}]
	*Claim age_in_years*:		*Claim age_in_years*:
	* SHA-256 Hash: WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE		* SHA-256 Hash:
			WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE
	* Disclosure:		* Disclosure:
	WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3IiwgImFnZV9pbl95ZWFycyIsIDYy
	XQ		WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3IiwgImFnZV9pbl95ZWFycyIsIDYyXQ
	* Contents: ["j7ADdb0UVb0Li0ciPcP0ew", "age_in_years", 62]
			* Contents:
			["j7ADdb0UVb0Li0ciPcP0ew", "age_in_years", 62]
	*Claim age_birth_year*:		*Claim age_birth_year*:
	* SHA-256 Hash: LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4		* SHA-256 Hash:
			LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4
	* Disclosure:		* Disclosure:
	WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgImFnZV9iaXJ0aF95ZWFyIiwg
	MTk2M10		WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgImFnZV9iaXJ0aF95ZWFyIiwgMTk2M1
	* Contents: ["WpxJrFuX8uSi2p4ht09jvw", "age_birth_year", 1963]		0
			* Contents:
			["WpxJrFuX8uSi2p4ht09jvw", "age_birth_year", 1963]
	*Claim issuance_date*:		*Claim issuance_date*:
	* SHA-256 Hash: W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8		* SHA-256 Hash:
			W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8
	* Disclosure:		* Disclosure:
	WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgImlzc3VhbmNlX2RhdGUiLCAi
	MjAyMC0wMy0xMSJd		WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgImlzc3VhbmNlX2RhdGUiLCAiMjAyMC
	* Contents: ["atSmFACYMbJVKD05o3JgtQ", "issuance_date",		0wMy0xMSJd
	"2020-03-11"]
			* Contents:
			["atSmFACYMbJVKD05o3JgtQ", "issuance_date", "2020-03-11"]
	*Claim expiry_date*:		*Claim expiry_date*:
	* SHA-256 Hash: 78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM		* SHA-256 Hash:
			78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM
	* Disclosure:		* Disclosure:
	WyI0S3lSMzJvSVp0LXprV3ZGcWJVTEtnIiwgImV4cGlyeV9kYXRlIiwgIjIw
	MzAtMDMtMTIiXQ		WyI0S3lSMzJvSVp0LXprV3ZGcWJVTEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzAtMD
	* Contents: ["4KyR32oIZt-zkWvFqbULKg", "expiry_date", "2030-03-12"]		MtMTIiXQ
			* Contents:
			["4KyR32oIZt-zkWvFqbULKg", "expiry_date", "2030-03-12"]
	*Claim issuing_authority*:		*Claim issuing_authority*:
	* SHA-256 Hash: 6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os		* SHA-256 Hash:
			6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os
	* Disclosure:		* Disclosure:
	WyJjaEJDc3loeWgtSjg2SS1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5
	IiwgIkRFIl0		WyJjaEJDc3loeWgtSjg2SS1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5IiwgIk
	* Contents: ["chBCsyhyh-J86I-awQDiCQ", "issuing_authority", "DE"]		RFIl0
			* Contents:
			["chBCsyhyh-J86I-awQDiCQ", "issuing_authority", "DE"]
	*Claim issuing_country*:		*Claim issuing_country*:
	* SHA-256 Hash: _ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs		* SHA-256 Hash:
			_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs
	* Disclosure:		* Disclosure:
	WyJmbE5QMW5jTXo5TGctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIs
	ICJERSJd		WyJmbE5QMW5jTXo5TGctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJERS
	* Contents: ["flNP1ncMz9Lg-c9qMIz_9g", "issuing_country", "DE"]		Jd
			* Contents:
			["flNP1ncMz9Lg-c9qMIz_9g", "issuing_country", "DE"]
	The following is an example of an SD-JWT+KB that discloses only		The following is an example of an SD-JWT+KB that discloses only
	nationality and the fact that the person is over 18 years old:		nationality and the fact that the person is over 18 years old:
	eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1		eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1
	uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21		uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21
	VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJ		VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJ
	XclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0F		XclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0F
	rYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB		rYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB
	5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWk		5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWk
	skipping to change at page 79, line 30 ¶		skipping to change at line 4233 ¶
	},		},
	"nationalities": [		"nationalities": [
	"DE"		"DE"
	]		]
	}		}
	A.4. W3C Verifiable Credentials Data Model v2.0		A.4. W3C Verifiable Credentials Data Model v2.0
	This non-normative example illustrates how the artifacts defined in		This non-normative example illustrates how the artifacts defined in
	this specification could be used to express a W3C Verifiable		this specification could be used to express a W3C Verifiable
	Credentials Data Model v2.0 [VC_DATA_v2.0] payload.		Credentials Data Model v2.0 payload [VC_DATA_v2.0].
	Key Binding is applied using the Holder's public key passed in a cnf		Key Binding is applied using the Holder's public key passed in a cnf
	claim in the SD-JWT.		claim in the SD-JWT.
	The following is the input JWT Claims Set:		The following is the input JWT Claims Set:
	{		{
	"@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"
	skipping to change at page 83, line 15 ¶		skipping to change at line 4389 ¶
	"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"		"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
	}		}
	}		}
	}		}
	The digests in the SD-JWT payload reference the following		The digests in the SD-JWT payload reference the following
	Disclosures:		Disclosures:
	*Claim atcCode*:		*Claim atcCode*:
	* SHA-256 Hash: 1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI		* SHA-256 Hash:
			1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI
	* Disclosure:		* Disclosure:
	WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3Qlgw
	MyJd		WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd
	* Contents: ["2GLC42sKQveCfGfryNRN9w", "atcCode", "J07BX03"]
			* Contents:
			["2GLC42sKQveCfGfryNRN9w", "atcCode", "J07BX03"]
	*Claim medicinalProductName*:		*Claim medicinalProductName*:
	* SHA-256 Hash: Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo		* SHA-256 Hash:
			Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo
	* Disclosure:		* Disclosure:
	WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3RO
	YW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd		WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIi
	* Contents: ["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName",		wgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd
	"COVID-19
			* Contents:
			["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName", "COVID-19
	Vaccine Moderna"]		Vaccine Moderna"]
	*Claim marketingAuthorizationHolder*:		*Claim marketingAuthorizationHolder*:
	* SHA-256 Hash: Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE		* SHA-256 Hash:
			Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE
	* Disclosure:		* Disclosure:
	WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6
	YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0		WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6YXRpb2
	* Contents: ["6Ij7tM-a5iVPGboS5tmvVA",		5Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0
	"marketingAuthorizationHolder",
			* Contents:
			["6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHolder",
	"Moderna Biotech"]		"Moderna Biotech"]
	*Claim nextVaccinationDate*:		*Claim nextVaccinationDate*:
	* SHA-256 Hash: R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4		* SHA-256 Hash:
			R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4
	* Disclosure:		* Disclosure:
	WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRh
	dGUiLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ		WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGUiLC
	* Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate",		AiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ
			* Contents:
			["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate",
	"2021-08-16T13:40:12Z"]		"2021-08-16T13:40:12Z"]
	*Claim countryOfVaccination*:		*Claim countryOfVaccination*:
	* SHA-256 Hash: JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg		* SHA-256 Hash:
			JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg
	* Disclosure:		* Disclosure:
	WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0
	aW9uIiwgIkdFIl0		WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0aW9uIi
	* Contents: ["Qg_O64zqAxe412a108iroA", "countryOfVaccination", "GE"]		wgIkdFIl0
			* Contents:
			["Qg_O64zqAxe412a108iroA", "countryOfVaccination", "GE"]
	*Claim dateOfVaccination*:		*Claim dateOfVaccination*:
	* SHA-256 Hash: zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0		* SHA-256 Hash:
			zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0
	* Disclosure:		* Disclosure:
	WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9u
	IiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0		WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9uIiwgIj
	* Contents: ["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination",		IwMjEtMDYtMjNUMTM6NDA6MTJaIl0
			* Contents:
			["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination",
	"2021-06-23T13:40:12Z"]		"2021-06-23T13:40:12Z"]
	*Claim order*:		*Claim order*:
	* SHA-256 Hash: b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g		* SHA-256 Hash:
			b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g
	* Disclosure:		* Disclosure:
	WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd		WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd
	* Contents: ["Pc33JM2LchcU_lHggv_ufQ", "order", "3/3"]
			* Contents:
			["Pc33JM2LchcU_lHggv_ufQ", "order", "3/3"]
	*Claim gender*:		*Claim gender*:
	* SHA-256 Hash: 3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI		* SHA-256 Hash:
			3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI
	* Disclosure:		* Disclosure:
	WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUi
	XQ		WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUiXQ
	* Contents: ["G02NSrQfjFXQ7Io09syajA", "gender", "Female"]
			* Contents:
			["G02NSrQfjFXQ7Io09syajA", "gender", "Female"]
	*Claim birthDate*:		*Claim birthDate*:
	* SHA-256 Hash: Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU		* SHA-256 Hash:
			Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU
	* Disclosure:		* Disclosure:
	WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYx
	LTA4LTE3Il0		WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYxLTA4LT
	* Contents: ["lklxF5jMYlGTPUovMNIvCA", "birthDate", "1961-08-17"]		E3Il0
			* Contents:
			["lklxF5jMYlGTPUovMNIvCA", "birthDate", "1961-08-17"]
	*Claim givenName*:		*Claim givenName*:
	* SHA-256 Hash: lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw		* SHA-256 Hash:
			lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw
	* Disclosure:		* Disclosure:
	WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJp
	b24iXQ		WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJpb24iXQ
	* Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "givenName", "Marion"]
			* Contents:
			["nPuoQnkRFq3BIeAm7AnXFA", "givenName", "Marion"]
	*Claim familyName*:		*Claim familyName*:
	* SHA-256 Hash: 1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA		* SHA-256 Hash:
			1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA
	* Disclosure:		* Disclosure:
	WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVz
	dGVybWFubiJd		WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVzdGVybW
	* Contents: ["5bPs1IquZNa0hkaFzzzZNw", "familyName", "Mustermann"]		FubiJd
			* Contents:
			["5bPs1IquZNa0hkaFzzzZNw", "familyName", "Mustermann"]
	*Claim administeringCentre*:		*Claim administeringCentre*:
	* SHA-256 Hash: TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg		* SHA-256 Hash:
			TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg
	* Disclosure:		* Disclosure:
	WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50
	cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd		WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLC
	* Contents: ["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre",		AiUHJheGlzIFNvbW1lcmdhcnRlbiJd
	"Praxis
			* Contents:
			["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre", "Praxis
	Sommergarten"]		Sommergarten"]
	*Claim batchNumber*:		*Claim batchNumber*:
	* SHA-256 Hash: V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM		* SHA-256 Hash:
			V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM
	* Disclosure:		* Disclosure:
	WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2
	MjYzODI3MzYiXQ		WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzOD
	* Contents: ["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber", "1626382736"]		I3MzYiXQ
			* Contents:
			["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber", "1626382736"]
	*Claim healthProfessional*:		*Claim healthProfessional*:
	* SHA-256 Hash: 1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww		* SHA-256 Hash:
			1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww
	* Disclosure:		* Disclosure:
	WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25h
	bCIsICI4ODMxMTAwMDAwMTUzNzYiXQ		WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCIsIC
	* Contents: ["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional",		I4ODMxMTAwMDAwMTUzNzYiXQ
			* Contents:
			["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional",
	"883110000015376"]		"883110000015376"]
	This is an example of an SD-JWT+KB that discloses only type,		This is an example of an SD-JWT+KB that discloses only type,
	medicinalProductName, atcCode of the vaccine, type of the recipient,		medicinalProductName, atcCode of the vaccine, type of the recipient,
	type, order and dateOfVaccination:		type, order, and dateOfVaccination:
	eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4		eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4
	dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0		dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0
	cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJs		cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJs
	ZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjog		ZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjog
	Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIz		Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIz
	LTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDEx		LTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDEx
	OjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl		OjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl
	IiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl		IiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl
	IiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhi		IiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhi
	skipping to change at page 88, line 4 ¶		skipping to change at line 4694 ¶
	The following Elliptic Curve public key, represented in JWK format,		The following Elliptic Curve public key, represented in JWK format,
	can be used to validate the Issuer signatures in the above examples:		can be used to validate the Issuer signatures in the above examples:
	{		{
	"kty": "EC",		"kty": "EC",
	"crv": "P-256",		"crv": "P-256",
	"x": "b28d4MwZMjw8-00CG4xfnn9SLMVMM19SlqZpVb_uNtQ",		"x": "b28d4MwZMjw8-00CG4xfnn9SLMVMM19SlqZpVb_uNtQ",
	"y": "Xv5zWwuoaTgdS6hV43yI6gBwTnjukmFQQnJ_kCxzqk8"		"y": "Xv5zWwuoaTgdS6hV43yI6gBwTnjukmFQQnJ_kCxzqk8"
	}		}
	The public key used to validate a Key Binding JWT can be found in the		The public key used to validate a Key Binding JWT can be found in the
	examples as the content of the cnf claim.		examples as the content of the cnf claim.
	Appendix B. Disclosure Format Considerations		Appendix B. Disclosure Format Considerations
	As described in Section 4.2, the Disclosure structure is JSON		As described in Section 4.2, the Disclosure structure is JSON
	containing salt and the cleartext content of a claim, which is		containing a salt and the cleartext content of a claim, which is
	base64url encoded. The encoded value is the input used to calculate		base64url encoded. The encoded value is the input used to calculate
	a digest for the respective claim. The inclusion of digest value in		a digest for the respective claim. The inclusion of digest value in
	the signed JWT ensures the integrity of the claim value. Using		the signed JWT ensures the integrity of the claim value. Using
	encoded content as the input to the integrity mechanism is		encoded content as the input to the integrity mechanism is
	conceptually similar to the approach in JWS and particularly useful		conceptually similar to the approach in JWS and particularly useful
	when the content, like JSON, can have different representations but		when the content, like JSON, can have different representations but
	is semantically equivalent, thus avoiding canonicalization. Some		is semantically equivalent, thus avoiding canonicalization. Some
	further discussion of the considerations around this design decision		further discussion of the considerations around this design decision
	follows.		follows.
	When receiving an SD-JWT, a Verifier must be able to re-compute		When receiving an SD-JWT, a Verifier must be able to recompute
	digests of the disclosed claim values and, given the same input		digests of the disclosed claim values and, given the same input
	values, obtain the same digest values as signed by the Issuer.		values, obtain the same digest values as signed by the Issuer.
	Usually, JSON-based formats transport claim values as simple		Usually, JSON-based formats transport claim values as simple
	properties of a JSON object such as this:		properties of a JSON object such as this:
	...		...
	"family_name": "Möbius",		"family_name": "Möbius",
	"address": {		"address": {
	"street_address": "Schulstr. 12",		"street_address": "Schulstr. 12",
	skipping to change at page 89, line 4 ¶		skipping to change at line 4738 ¶
	performed and verified, like signing or computing digests. Common		performed and verified, like signing or computing digests. Common
	signature schemes require the same byte string as input to the		signature schemes require the same byte string as input to the
	signature verification as was used for creating the signature. In		signature verification as was used for creating the signature. In
	the digest approach outlined above, the same problem exists: for the		the digest approach outlined above, the same problem exists: for the
	Issuer and the Verifier to arrive at the same digest, the same byte		Issuer and the Verifier to arrive at the same digest, the same byte
	string must be hashed.		string must be hashed.
	JSON, however, does not prescribe a unique encoding for data, but		JSON, however, does not prescribe a unique encoding for data, but
	allows for variations in the encoded string. The data above, for		allows for variations in the encoded string. The data above, for
	example, can be encoded as		example, can be encoded as
	...		...
	"family_name": "M\u00f6bius",		"family_name": "M\u00f6bius",
	"address": {		"address": {
	"street_address": "Schulstr. 12",		"street_address": "Schulstr. 12",
	"locality": "Schulpforta"		"locality": "Schulpforta"
	}		}
	...		...
	or as		or as
	...		...
	"family_name": "Möbius",		"family_name": "Möbius",
	"address": {"locality":"Schulpforta", "street_address":"Schulstr. 12"}		"address": {"locality":"Schulpforta", "street_address":"Schulstr. 12"}
	...		...
	The two representations of the value in family_name are very		The two representations of the value in family_name are very
	different on the byte-level, but yield equivalent objects. Same for		different on the byte level, but they yield equivalent objects. The
	the representations of address, varying in white space and order of		same is true for the representations of address, which vary in white
	elements in the object.		space and order of elements in the object.
	The variations in white space, ordering of object properties, and		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 [RFC8785]. Variations can be		floating-point numbers, as described in [RFC8785]. Variations can be
	introduced whenever JSON data is serialized or deserialized and		introduced whenever JSON data is serialized or deserialized and
	unless dealt with, will lead to different digests and the inability		unless dealt with, will lead to different digests and the inability
	to verify signatures.		to verify signatures.
	There are generally two approaches to deal with this problem:		There are generally two approaches to deal with this problem:
	skipping to change at page 89, line 40 ¶		skipping to change at line 4775 ¶
	to verify signatures.		to verify signatures.
	There are generally two approaches to deal with this problem:		There are generally two approaches to deal with this problem:
	1. Canonicalization: The data is transferred in JSON format,		1. Canonicalization: The data is transferred in JSON format,
	potentially introducing variations in its representation, but is		potentially introducing variations in its representation, but is
	transformed into a canonical form before computing a digest.		transformed into a canonical form before computing a digest.
	Both the Issuer and the Verifier must use the same		Both the Issuer and the Verifier must use the same
	canonicalization algorithm to arrive at the same byte string for		canonicalization algorithm to arrive at the same byte string for
	computing a digest.		computing a digest.
	2. Source string hardening: Instead of transferring data in a format		2. Source string hardening: Instead of transferring data in a format
	that may introduce variations, a representation of the data is		that may introduce variations, a representation of the data is
	serialized. This representation is then used as the hashing		serialized. This representation is then used as the hashing
	input at the Verifier, but also transferred to the Verifier and		input at the Verifier, but also transferred to the Verifier and
	used for the same digest calculation there. This means that the		used for the same digest calculation there. This means that the
	Verifier can easily compute and check the digest of the byte		Verifier can easily compute and check the digest of the byte
	string before finally deserializing and accessing the data.		string before finally deserializing and accessing the data.
	Mixed approaches are conceivable, i.e., transferring both the		Mixed approaches are conceivable, i.e., transferring both the
	original JSON data plus a string suitable for computing a digest, but		original JSON data and a string suitable for computing a digest, but
	such approaches can easily lead to undetected inconsistencies		such approaches can easily lead to undetected inconsistencies
	resulting in time-of-check-time-of-use type security vulnerabilities.		resulting in time-of-check-time-of-use type security vulnerabilities.
	In this specification, the source string hardening approach is used,		In this specification, the source string hardening approach is used,
	as it allows for simple and reliable interoperability without the		as it allows for simple and reliable interoperability without the
	requirement for a canonicalization library. To harden the source		requirement for a canonicalization library. To harden the source
	string, any serialization format that supports the necessary data		string, any serialization format that supports the necessary data
	types could be used in theory, like protobuf, msgpack, or pickle. In		types could be used in theory, like protobuf, msgpack, or pickle. In
	this specification, JSON is used and plaintext contents of each		this specification, JSON is used and plaintext contents of each
	Disclosure are encoded using base64url-encoding for transport. This		Disclosure are encoded using base64url encoding for transport. This
	approach means that SD-JWTs can be implemented purely based on widely		approach means that SD-JWTs can be implemented purely based on widely
	available JWT, JSON, and Base64 encoding and decoding libraries.		available JWT, JSON, and Base64 encoding and decoding libraries.
	A Verifier can then easily check the digest over the source string		A Verifier can then easily check the digest over the source string
	before extracting the original JSON data. Variations in the encoding		before extracting the original JSON data. Variations in the encoding
	of the source string are implicitly tolerated by the Verifier, as the		of the source string are implicitly tolerated by the Verifier, as the
	digest is computed over a predefined byte string and not over a JSON		digest is computed over a predefined byte string and not over a JSON
	object.		object.
	It is important to note that the Disclosures are neither intended nor		It is important to note that the Disclosures are neither intended nor
	suitable for direct consumption by an application that needs to		suitable for direct consumption by an application that needs to
	access the disclosed claim values after the verification by the		access the disclosed claim values after the verification by the
	Verifier. The Disclosures are only intended to be used by a Verifier		Verifier. The Disclosures are only intended to be used by a Verifier
	to check the digests over the source strings and to extract the		to check the digests over the source strings and to extract the
	original JSON data. The original JSON data is then used by the		original JSON data. The original JSON data is then used by the
	application. See Section 7.3 for details.		application. See Section 7.3 for details.
	Appendix C. Document History		Acknowledgements
	[[ To be removed from the final specification ]]
	-22
	* fix text that was out of sync with the associated example
	-21
	* A few more minor IESG balloting updates
	-20
	* IESG balloting updates
	-19
	* Attempt to improve some language around exactly what bytes get
	base64url encoded
	* Update the ABNF to something that is cleaner and more idiomatic
	* updates from AD's review of comments
	-18
	* Update PID example to align with the latest ARF and update the ARF
	reference
	* Editorial updates from SECDIR IETF LC review
	* Terminology improvements around the phrase "non-selectively
	disclosable claims" and "not disclosable"
	* Suggest against using extra claims/headers in the KB-JWT without a
	good reason
	-17
	* Acknowledgements updates
	-16
	* Updates following review of -15 by Hannes Tschofenig, document
	shepherd
	* Editorial updates to text introduced in -15
	* Changes based on feedback received after the end of the second
	working group last call
	-15
	* Additions and adjustments to privacy considerations
	* Address AD review comments resulting from evaluation of formal
	appeal
	* Clarify language around compromised/coerced verifiers
	-14
	* Address WGLC (part 2) comments
	* Note that the Hash Function Claim value is case-sensitive
	* Update the typ value in the SD-JWT VC example to dc+sd-jwt to
	align with anticipated changes in the SD-JWT VC draft.
	-13
	* WGLC (part 1) updates
	* Rewrote introduction
	* Added note on algorithm for Holder's verification of the SD-JWT
	-12
	* Clarify, add context, or otherwise improve the examples
	* Editorial and reference fixes
	* Better introduce the phrase processed SD-JWT payload in the end of
	Section 7.1 on Verifying the SD-JWT
	* Moved considerations around unlinkability to the top of the
	Privacy Considerations section
	* Remove the brief discussion of publishing private key(s) to
	attempt to reduce the value of leaked or stolen data
	-11
	* Add a paragraph attempting to better frame the risks and
	difficulties around Issuer/Verifier unlinkability (i.e., a
	government issuer or huge service provider compelling collusion)
	* Tightened the exposition
	-10
	* Add a section clarifying recursive disclosures and their
	interdependencies
	* Editorial updates/fixes
	-09
	* Distinguished SD-JWT from SD-JWT+KB
	* Provide ABNF for the SD-JWT, SD-JWT+KB, and various constituent
	parts
	* New structure for JSON-serialized SD-JWTs/KB-JWTs to better align
	with JAdES.
	* Attempt to better explain how salt in the Disclosure makes
	guessing the preimage of the digest infeasible
	* Consolidate salt entropy and length security consideration
	subsections
	* Unnumbered most of the examples for improved clarity
	* More definitive language around the exclusive use of the cnf claim
	for enabling Key Binding
	-08
	* Make RFCs 0020 and 7515 normative references
	* Be a bit more prescriptive in suggesting RFC7800 cnf/jwk be used
	to convey the Key Binding key
	* Editorial changes aimed at improved clarity
	* Improve unlinkability considerations, mention that different KB
	keys must be used
	* Remove the explicit prohibition on HMAC
	* Remove mention of unspecified key binding methods and the
	Enveloping SD-JWTs section
	* Editorial updates aimed at more consistent treatment of a
	Disclosure vs the contents of a Disclosure
	* Update PID example
	* Be more explicit that the VCDM and SD-JWT VC examples are only
	illustrative and do not define anything
	-07
	* Reference RFC4086 in security considerations about salt entropy
	* Update change controller for the Structured Syntax Suffix
	registration from IESG to IETF per IANA suggestion
	* Strengthen security considerations around claims controlling the
	validity of the SD-JWT not being selectively disclosable
	* Expand/rework considerations on the choice of hash algorithm
	* Clarify validation around no duplicate digests in the payload
	(directly or recursively) and no unused disclosures at the end of
	processing
	* Better describe and illustrate the tilde separated format
	* Change claim name from _sd_hash to sd_hash
	-06
	* Added hash of Issuer-signed part and Disclosures in KB-JWT
	* Fix minor issues in some examples
	* Added IANA media type registration request for the JSON
	Serialization
	* More precise wording around storing artifacts with sensitive data
	* The claim name _sd or ... must not be used in a disclosure.
	* Added JWT claims registration requests to IANA
	* Ensure claims that control validity are checked after decoding
	payload
	* Restructure sections around data formats and Example 1
	* Update JSON Serialization to remove the kb_jwt member and allow
	for the disclosures to be conveyed elsewhere
	* Expand the Enveloping SD-JWTs section to also discuss enveloping
	JSON serialized SD-JWTs
	-05
	* Consolidate processing rules for Holder and Verifier
	* Add support for selective disclosure of array elements.
	* Consolidate SD-JWT terminology and format
	* Use the term Key Binding rather than Holder Binding
	* Defined the structure of the Key Binding JWT
	* Added a JWS JSON Serialization
	* Added initial IANA media type and structured suffix registration
	requests
	* Added recommendation for explicit typing of SD-JWTs
	* Added considerations around forwarding credentials
	* Removed Example 2b and merged the demo of decoy digests into
	Example 2a
	* Improved example for allowed variations in Disclosures
	* Added some text to the Abstract and Introduction to be more
	inclusive of JWS with JSON
	* Added some security considerations text about the scope of the Key
	Binding JWT
	* Aligned examples structure and used the term input JWT Claims Set
	* Replaced the general SD-JWT VC example with one based on Person
	Identification Data (PID) from the European Digital Identity
	Wallet Architecture and Reference Framework
	* Added/clarified some privacy considerations in Confidentiality
	during Transport
	* No longer recommending a claim name for enveloped SD-JWTs
	* Mention prospective future PQ algs for JWS
	* Include the public key in the draft, which can be used to verify
	the issuer signature examples
	* Clarify that _sd_alg can only be at the top level of the SD-JWT
	payload
	* Externalized the SD-JWT library that generates examples
	* Attempt to improve description of security properties
	-04
	* Improve description of processing of disclosures
	-03
	* Clarify that other specifications may define enveloping multiple
	Combined Formats for Presentation
	* Add an example of W3C vc-data-model that uses a JSON-LD object as
	the claims set
	* Clarify requirements for the combined formats for issuance and
	presentation
	* Added overview of the Security Considerations section
	* Enhanced examples in the Privacy Considerations section
	* Allow for recursive disclosures
	* Discussion on holder binding and privacy of stored credentials
	* Add some context about SD-JWT being general-purpose despite being
	a product of the OAuth WG
	* More explicitly say that SD-JWTs have to be signed asymmetrically
	(no MAC and no none)
	* Make sha-256 the default hash algorithm, if the hash alg claim is
	omitted
	* Use ES256 instead of RS256 in examples
	* Rename and move the c14n challenges section to an appendix
	* A bit more in security considerations for Choice of a Hash
	Algorithm (1st & 2nd preimage resistant and not majorly truncated)
	* Remove the notational figures from the Concepts section
	* Change salt to always be a string (rather than any JSON type)
	* Fix the Document History (which had a premature list for -03)
	-02
	* Disclosures are now delivered not as a JWT but as separate
	base64url-encoded JSON objects.
	* In the SD-JWT, digests are collected under a _sd claim per level.
	* Terms "II-Disclosures" and "HS-Disclosures" are replaced with
	"Disclosures".
	* Holder Binding is now separate from delivering the Disclosures and
	implemented, if required, with a separate JWT.
	* Examples updated and modified to properly explain the specifics of
	the new SD-JWT format.
	* Examples are now pulled in from the examples directory, not
	inlined.
	* Updated and automated the W3C VC example.
	* Added examples with multibyte characters to show that the
	specification and demo code work well with UTF-8.
	* reverted back to hash alg from digest derivation alg (renamed to
	_sd_alg)
	* reformatted
	-01
	* introduced blinded claim names
	* explained why JSON-encoding of values is needed
	* explained merging algorithm ("processing model")
	* generalized hash alg to digest derivation alg which also enables
	HMAC to calculate digests
	* _sd_hash_alg renamed to sd_digest_derivation_alg
	* Salt/Value Container (SVC) renamed to Issuer-Issued Disclosures
	(II-Disclosures)
	* SD-JWT-Release (SD-JWT-R) renamed to Holder-Selected Disclosures
	(HS-Disclosures)
	* sd_disclosure in II-Disclosures renamed to sd_ii_disclosures
	* sd_disclosure in HS-Disclosures renamed to sd_hs_disclosures
	* clarified relationship between sd_hs_disclosure and SD-JWT
	* clarified combined formats for issuance and presentation
	* clarified security requirements for blinded claim names
	* improved description of Holder Binding security considerations -
	especially around the usage of "alg=none".
	* updated examples
	* text clarifications
	* fixed cnf structure in examples
	* added feature summary
	-00
	* Upload as draft-ietf-oauth-selective-disclosure-jwt-00
	[[ pre Working Group Adoption: ]]
	-02
	* Added acknowledgements
	* Improved Security Considerations
	* Stressed entropy requirements for salts
	* Python reference implementation clean-up and refactoring
	* hash_alg renamed to _sd_hash_alg
	-01
	* Editorial fixes
	* Added hash_alg claim
	* Renamed _sd to sd_digests and sd_release
	* Added descriptions on Holder Binding - more work to do
	* Clarify that signing the SD-JWT is mandatory
	-00		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 Preuß Mattsson, Joseph Heenan, Justin Richer, Kushal
			Das, Martin Thomson, Matthew Miller, Michael Fraser, Michael
			B. Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie
			Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard
			Barnes, Rohan Mahy, Roman Danyliw, Ryosuke Abe, Sami Rosendahl, Shawn
			Butterfield, Shawn Emery, Simon Schulz, Takahiko Kawasaki, Tobias
			Looker, Torsten Lodderstedt, Vittorio Bertocci, Watson Ladd, and
			Yaron Sheffer for their contributions (some of which were
			substantial) to this draft and to the initial set of implementations.
	* Renamed to SD-JWT (focus on JWT instead of JWS since signature is		The work on this document was started at the OAuth Security Workshop
	optional)		2022 in Trondheim, Norway.
	* Make Holder Binding optional
	* Rename proof to release, since when there is no signature, the
	term "proof" can be misleading
	* Improved the structure of the description
	* Described verification steps
	* All examples generated from python demo implementation
	* Examples for structured objects
	Authors' Addresses		Authors' Addresses
	Daniel Fett		Daniel Fett
	Authlete		Authlete
	Email: mail@danielfett.de		Email: mail@danielfett.de
	URI: https://danielfett.de/		URI: https://danielfett.de/
	Kristina Yasuda		Kristina Yasuda
	Keio University		Keio University
End of changes. 429 change blocks.
	1267 lines changed or deleted		1703 lines changed or added
This html diff was produced by rfcdiff 1.48.