- Copyright (c) 2024 IETF Trust and the persons identified as the + Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal @@ -1325,6 +1325,9 @@
SD-JWT+KB is a composite structure enabling cryptographic key binding when presented to the Verifier. It comprises the following:¶
sd_hash claim.¶
+ sd_hash claim. A JWT for proving Key Binding
+as defined in Section 4.3.¶
An SD-JWT, at its core, is a digitally signed JSON document containing digests over the selectively disclosable claims with the Disclosures outside the document. Disclosures can be omitted without breaking the signature, and modifying them can be detected. Selectively disclosable claims can be individual object properties (name/value pairs) or array elements.¶
-Each digest value ensures the integrity of, and maps to, the respective Disclosure. Digest values are calculated using a hash function over the Disclosures, each of which contains a cryptographically secure random salt, the claim name (only when the claim is an object property), and the claim value. The Disclosures are sent to the Holder as part of the SD-JWT in the format defined in Section 4. +
Each digest value ensures the integrity of, and maps to, the respective Disclosure. Digest values are calculated using a hash function over the Disclosures, each of which contains a cryptographically secure random salt, the claim name (only when the claim is an object property), and the claim value. The Disclosures are sent to the Holder with the SD-JWT in the format defined in Section 4. When presenting an SD-JWT to a Verifier, the Holder only includes the Disclosures for the claims that it wants to reveal to that Verifier.¶
An SD-JWT MAY also contain cleartext claims that are always disclosed to the Verifier.¶
@@ -1719,8 +1723,8 @@As an alternative illustration of the SD-JWT format, for those who celebrate, ABNF [RFC5234] for the -SD-JWT, SD-JWT+KB, and various constituent parts is provided here:¶
+As an alternative illustration of the SD-JWT format, ABNF [RFC5234] for the +SD-JWT, SD-JWT+KB, and various constituent parts is provided here (for those who celebrate):¶
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 @@ -2414,8 +2418,8 @@¶InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG -MkhaUSJ9fX0.KoZGuv5lw09OSCaDPWsw1blPSkvUOHNpe3mmj6ZZJsWf8ch9Bn1KGdKW -Ox1tY111cfzdxi0ezk5VjUyBqD24nQ +MkhaUSJ9fX0.rvsNKVN_VkKbr7ESx7Km-PQSiwKXDGWbtHjWGITfA25G9uLFIS8piVjB +YpcoPA8ml7ga9cLhXBh2FWWB2xYZDg
{
"nonce": "1234567890",
"aud": "https://verifier.example.org",
- "iat": 1734554206,
- "sd_hash": "trPiXfCbEPWAiGyKBdwJ33Ynrn6tEz4Z05ziOj-gQbg"
+ "iat": 1737051100,
+ "sd_hash": "TVr2xB6QO-yBTq7nds54v0tfXulTnjajjYUFtPLcHJA"
}
¶
@@ -2819,7 +2823,7 @@ The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving -an SD-JWT:¶
+an SD-JWT to validate the SD-JWT and extract the payload:¶The Issuer MUST provide the Holder an SD-JWT, not an SD-JWT+KB. If the Holder receives an SD-JWT+KB, it MUST be rejected.¶
-For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps:¶
+When receiving an SD-JWT, the Holder MUST do the following:¶
For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps (in addition to the checks described in Section 7.1 performed after receiving the SD-JWT):¶
+Verify that each selected Disclosure satisfies one of the two following conditions:¶
-Verify that each selected Disclosure satisfies one of the two following conditions:¶
+If Key Binding is not required:¶
-If Key Binding is not required:¶
+If Key Binding is required:¶
-If Key Binding is required:¶
+Upon receiving a presentation from a Holder, in the form of either an SD-JWT or -an SD-JWT+KB, in addition to the checks outlined in Section 7.1, Verifiers need to ensure that¶
+an SD-JWT+KB, in addition to the checks described in Section 7.1, Verifiers need to ensure that¶If Key Binding is required:¶
@@ -3076,8 +3087,8 @@Integrity: A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier.¶
-Additionally, as described in Section 9.5, the application of Key Binding can ensure that the presenter of an SD-JWT credential is the legitimate Holder of the credential.¶
+Additionally, as described in Section 9.5, the application of Key Binding can ensure that the presenter of an SD-JWT credential is the Holder of the credential.¶
Key Binding aims to ensure that the presenter of an SD-JWT credential is actually the legitimate Holder of the 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 Key Binding contains a public key, or a reference to a public key, that corresponds to a private key possessed by the Holder. The Verifier requires that the Holder prove possession of that private key when presenting the SD-JWT credential.¶
Without Key Binding, a Verifier only gets the proof that the @@ -3463,6 +3474,27 @@
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 types of JSON objects, or different kinds of JWT Claim Sets.¶
Implementations of SD-JWT rely on asymmetric cryptographic keys and must therefore ensure that key pair generation, +handling, storage, and lifecycle management are performed securely.¶
+While the specific mechanisms for secure key management are out of scope for this document, implementers +should follow established best practices, such as those outlined in NIST SP 800-57 Part 1 [NIST.SP.800-57pt1r5]. +This includes:¶
+Appropriate key management is essential, as any compromise can lead to unauthorized disclosure or forgery of SD-JWTs.¶
+In all cases, unlinkability is limited to cases where the disclosed claims do @@ -3515,10 +3550,11 @@
Issuer/Verifier unlinkability with a colluding or compromised Verifier cannot be +
Issuer/Verifier unlinkability with a careless, colluding, compromised, or coerced Verifier cannot be achieved in salted-hash based selective disclosure approaches, such as SD-JWT, as the issued credential with the Issuer's signature is directly presented to the Verifier, who can forward it to -the Issuer.¶
+the Issuer. To reduce the risk of revealing the data later on, Section 10.2 defines +requirements to reduce the amount of data stored.¶In considering Issuer/Verifier unlinkability, it is important to note the potential for an asymmetric power dynamic between Issuers and Verifiers. This dynamic can compel an otherwise honest Verifier into collusion. For example, a governmental Issuer might have the authority to mandate that a Verifier report back information @@ -3545,7 +3581,7 @@
Due to these risks, systems implementing SD-JWT SHOULD be designed to minimize -the amount of data that is stored. All involved parties SHOULD store SD-JWTs -containing privacy-sensitive data only for as long as needed, including in log -files.¶
+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 that is stored. All involved parties SHOULD NOT store SD-JWTs +longer than strictly needed, including in log files.¶
After Issuance, Issuers SHOULD NOT store the Issuer-signed JWT or the respective -Disclosures if they contain privacy-sensitive data.¶
+Disclosures.¶Holders SHOULD store SD-JWTs only in encrypted form, and, wherever possible, use hardware-backed encryption in particular for the private Key Binding key. Decentralized storage @@ -3577,9 +3612,12 @@
After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT or the -respective Disclosures if they contain privacy-sensitive data. It may be +respective Disclosures. It may be sufficient to store the result of the verification and any user data that is needed for the application.¶
+Exceptions from the rules above can be made if there are strong requirements to do +so (e.g., functional requirements or legal audit requirements), secure storage can +be ensured, and the privacy impact has been assessed.¶
{
"nonce": "1234567890",
"aud": "https://verifier.example.org",
- "iat": 1734554206,
- "sd_hash": "E6yvEtXAGj2kvYvEGq_ldsw4r6OW4QyGEOoXh4cjS1M"
+ "iat": 1737051100,
+ "sd_hash": "6Xp3UijqmT0i6cMoLJxMTm9tz909VIhXSvlPER8OxrM"
}
¶
@@ -5231,8 +5273,8 @@ [[ To be removed from the final specification ]]¶
--14¶
+-15¶
+* Address AD review comments resulting from evaluation of formal appeal +* Clarify language around compromised/coerced verifiers + +¶ +
-14¶
typ value in the SD-JWT VC example to dc+sd-jwt to align with anticipated changes in the SD-JWT VC draft.¶
+ typ value in the SD-JWT VC example to dc+sd-jwt to align with anticipated changes in the SD-JWT VC draft.¶
-13¶
+-13¶
-12¶
+-12¶
-11¶
+-11¶
-10¶
+-10¶
-09¶
+-09¶
cnf claim for enabling Key Binding¶
+ cnf claim for enabling Key Binding¶
-08¶
+-08¶
-07¶
+-07¶
_sd_hash to sd_hash¶
+ _sd_hash to sd_hash¶
-06¶
+-06¶
_sd or ... must not be used in a disclosure.¶
+ _sd or ... must not be used in a disclosure.¶
-05¶
+-05¶
_sd_alg can only be at the top level of the SD-JWT payload¶
+ _sd_alg can only be at the top level of the SD-JWT payload¶
-04¶
+-04¶
-03¶
+-03¶
none)¶
+ none)¶
-02¶
+-02¶
_sd claim per level.¶
+ _sd claim per level.¶
_sd_alg)¶
+ _sd_alg)¶
-01¶
+-01¶
_sd_hash_alg renamed to sd_digest_derivation_alg¶
+ _sd_hash_alg renamed to sd_digest_derivation_alg¶
sd_disclosure in II-Disclosures renamed to sd_ii_disclosures¶
+ sd_disclosure in II-Disclosures renamed to sd_ii_disclosures¶
sd_disclosure in HS-Disclosures renamed to sd_hs_disclosures¶
+ sd_disclosure in HS-Disclosures renamed to sd_hs_disclosures¶
sd_hs_disclosure and SD-JWT¶
+ sd_hs_disclosure and SD-JWT¶
cnf structure in examples¶
+ cnf structure in examples¶
-00¶
+-00¶
[[ pre Working Group Adoption: ]]¶
--02¶
+[[ pre Working Group Adoption: ]]¶
+-02¶
hash_alg renamed to _sd_hash_alg¶
+ hash_alg renamed to _sd_hash_alg¶
-01¶
+-01¶
hash_alg claim¶
+ hash_alg claim¶
_sd to sd_digests and sd_release¶
+ _sd to sd_digests and sd_release¶
-00¶
+-00¶