From 65140c86e644662b170fad59aafc79d772679f0d Mon Sep 17 00:00:00 2001 From: ID Bot Date: Thu, 16 Jan 2025 18:11:49 +0000 Subject: [PATCH] Script updating gh-pages from 52f71ac. [ci skip] --- ...t-ietf-oauth-selective-disclosure-jwt.html | 573 ++++++++++-------- ...ft-ietf-oauth-selective-disclosure-jwt.txt | 264 ++++---- 2 files changed, 472 insertions(+), 365 deletions(-) diff --git a/iso-frustrated-by-iso/draft-ietf-oauth-selective-disclosure-jwt.html b/iso-frustrated-by-iso/draft-ietf-oauth-selective-disclosure-jwt.html index f823afdf..1b79576a 100644 --- a/iso-frustrated-by-iso/draft-ietf-oauth-selective-disclosure-jwt.html +++ b/iso-frustrated-by-iso/draft-ietf-oauth-selective-disclosure-jwt.html @@ -22,7 +22,7 @@ ConfigArgParse 1.7 google-i18n-address 3.1.1 intervaltree 3.1.0 - Jinja2 3.1.4 + Jinja2 3.1.5 lxml 5.3.0 platformdirs 4.3.6 pycountry 24.6.1 @@ -1048,11 +1048,11 @@ Internet-Draft SD-JWT -December 2024 +January 2025 Fett, et al. -Expires 21 June 2025 +Expires 20 July 2025 [Page] @@ -1065,12 +1065,12 @@
draft-ietf-oauth-selective-disclosure-jwt-latest
Published:
- +
Intended Status:
Standards Track
Expires:
-
+
Authors:
@@ -1124,7 +1124,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 21 June 2025.

+ This Internet-Draft will expire on 20 July 2025.

Key Binding:
-
Ability of the Holder to prove legitimate possession of an SD-JWT by proving +
Ability of the Holder to prove possession of an SD-JWT by proving control over a private key during the presentation. When utilizing Key Binding, an SD-JWT contains the public key corresponding to the private key controlled by the Holder (or a reference to this public key).
Key Binding JWT (KB-JWT):
-
A JWT for proving Key Binding as defined in Section 4.3. A Key Binding JWT is -said to "be tied to" a particular SD-JWT when its payload includes a hash of the -SD-JWT in its sd_hash claim. +
A Key Binding JWT is said to "be tied to" a particular SD-JWT when its payload +is signed using the key included in the SD-JWT payload, and also contains +a hash of the SD-JWT in its sd_hash claim. A JWT for proving Key Binding +as defined in Section 4.3.
Selectively Disclosable JWT with Key Binding (SD-JWT+KB):
@@ -1556,7 +1560,7 @@

| | +------------+ | - Presents SD-JWT+KB + Presents SD-JWT or SD-JWT+KB including selected Disclosures | v @@ -1588,7 +1592,7 @@

3.1. SD-JWT and Disclosures

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
@@ -2437,8 +2441,8 @@

InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG -MkhaUSJ9fX0.KoZGuv5lw09OSCaDPWsw1blPSkvUOHNpe3mmj6ZZJsWf8ch9Bn1KGdKW -Ox1tY111cfzdxi0ezk5VjUyBqD24nQ~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgI +MkhaUSJ9fX0.rvsNKVN_VkKbr7ESx7Km-PQSiwKXDGWbtHjWGITfA25G9uLFIS8piVjB +YpcoPA8ml7ga9cLhXBh2FWWB2xYZDg~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgI mdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZh bWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWl sIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZW5IZGhR @@ -2482,18 +2486,18 @@

InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG -MkhaUSJ9fX0.KoZGuv5lw09OSCaDPWsw1blPSkvUOHNpe3mmj6ZZJsWf8ch9Bn1KGdKW -Ox1tY111cfzdxi0ezk5VjUyBqD24nQ~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgI +MkhaUSJ9fX0.rvsNKVN_VkKbr7ESx7Km-PQSiwKXDGWbtHjWGITfA25G9uLFIS8piVjB +YpcoPA8ml7ga9cLhXBh2FWWB2xYZDg~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgI mZhbWlseV9uYW1lIiwgIkRvZSJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFk ZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5 IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMi fV0~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~eyJhbGciOiAiRVMyNTYiLCA idHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodH -RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3MzQ1NTQyMDYsICJzZF -9oYXNoIjogInRyUGlYZkNiRVBXQWlHeUtCZHdKMzNZbnJuNnRFejRaMDV6aU9qLWdRYm -cifQ.lA-YiuO3z0MRIU8Eec8b93psLm4O2uU58CzncqJu5s0iKjMeoQFPu5vL2qijieA -4lXWGTQsd_8wWI2K5wQcIQA +RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3MzcwNTExMDAsICJzZF +9oYXNoIjogIlRWcjJ4QjZRTy15QlRxN25kczU0djB0Zlh1bFRuamFqallVRnRQTGNISk +EifQ.uYbouVfj5T2iKaQVAlmf3By4Pcx8AS8ZdTgORWlXbu12V1MBxlOt-KAAUEq2AKq +vA4FFfxu-l9cXthstylLpEw @@ -2502,8 +2506,8 @@ 

{
   "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:

  1. Separate the SD-JWT into the Issuer-signed JWT and the Disclosures (if any).
    2. @@ -2915,36 +2919,43 @@

    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:

      -
    1. Decide which Disclosures to release to the Verifier, obtaining proper consent if necessary. +
    2. Process the SD-JWT as defined in Section 7.1 to validate it and extract the payload. +
      3. +
    3. Ensure that the contents of claims in the payload are acceptable (depending on the application; for example, check that any values the Holder can check are correct). +
      4. +
    +

    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):

    +
      +
    1. Decide which Disclosures to release to the Verifier, obtaining proper consent if necessary.
      2. -
    2. -

      Verify that each selected Disclosure satisfies one of the two following conditions:

      -
        -
      1. The hash of the Disclosure is contained in the Issuer-signed JWT claims +
      2. +

        Verify that each selected Disclosure satisfies one of the two following conditions:

        +
          +
        1. The hash of the Disclosure is contained in the Issuer-signed JWT claims
          2. -
        2. The hash of the Disclosure is contained in the claim value of another selected Disclosure +
        3. The hash of the Disclosure is contained in the claim value of another selected Disclosure
        3. -
      3. Assemble the SD-JWT, including the Issuer-signed JWT and the selected Disclosures (see Section 4 for the format). +
      4. Assemble the SD-JWT, including the Issuer-signed JWT and the selected Disclosures (see Section 4 for the format).
        5. -
      5. -

        If Key Binding is not required:

        -
          -
        1. Send the SD-JWT to the Verifier. +
        2. +

          If Key Binding is not required:

          +
            +
          1. Send the SD-JWT to the Verifier.
          3. -
        3. -

          If Key Binding is required:

          -
            -
          1. Create a Key Binding JWT tied to the SD-JWT. +
          2. +

            If Key Binding is required:

            +
              +
            1. Create a Key Binding JWT tied to the SD-JWT.
              2. -
            2. Assemble the SD-JWT+KB by concatenating the SD-JWT and the Key Binding JWT. +
            3. Assemble the SD-JWT+KB by concatenating the SD-JWT and the Key Binding JWT.
              4. -
            4. Send the SD-JWT+KB to the Verifier. +
            5. Send the SD-JWT+KB to the Verifier.
            3. @@ -2957,7 +2968,7 @@

            7.3. Verification by the Verifier

            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, then the Holder has provided an SD-JWT+KB, and
              • @@ -2975,7 +2986,7 @@

            • If the Holder has provided an SD-JWT+KB, parse it into an SD-JWT and a Key Binding JWT.
              • -
            • Process the SD-JWT as defined in Section 7.1. +
            • Process the SD-JWT as defined in Section 7.1 to validate the presentation and extract the payload.

            • If Key Binding is required:

              @@ -3076,8 +3087,8 @@

              Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", - "signature": "7F8WwZOBl5pTvKalfYaxF6aaJ6UtO6uPzySe2FZfQpG6DBG8Upjj - C1Ai9kAaJ85O11JomjKRKf47CGA2kF6MBA" + "signature": "y1Zqi908WOXZfYxUEbxv1T0-o9rkNUOcFSJ1vpMUiCLoI7H0cfd8 + IMIn0lqSo6Jx63KxEuN5z0GhwYO_cICOnw" } @@ -3094,10 +3105,10 @@

              ], "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25j ZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW - 1wbGUub3JnIiwgImlhdCI6IDE3MzQ1NTQyMDYsICJzZF9oYXNoIjogIm9KMUZr - WkxNVnp1WTc3cE5hOTBoeWNGSk1UcjAzcUNfWV9kWDJkZnplQ0UifQ.fTH2vYQ - 2oaVDwnAfUKoTcFzY1wWIEeYumus0ZDuCZrU0E-mOq5tJ8Z5-GmLQ3DJFQTrKC - XgfBQ21KQSNc8rpPw" + 1wbGUub3JnIiwgImlhdCI6IDE3MzcwNTExMDAsICJzZF9oYXNoIjogIkRzVTE4 + TTR5VnVIcEE4YUJTT1VEZWZaWlE0SXg4dGJFd29rOFgzdzJyYUkifQ.R6p9nmo + dd8E058MhMrADzXEMkPmOE6oX6n4jIPyuTCn2urkT2jixOOtY9RaokTRFyAGqD + 86TLOpLt2LOmubqkg" }, "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV @@ -3111,8 +3122,8 @@

              Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", - "signature": "7F8WwZOBl5pTvKalfYaxF6aaJ6UtO6uPzySe2FZfQpG6DBG8Upjj - C1Ai9kAaJ85O11JomjKRKf47CGA2kF6MBA" + "signature": "y1Zqi908WOXZfYxUEbxv1T0-o9rkNUOcFSJ1vpMUiCLoI7H0cfd8 + IMIn0lqSo6Jx63KxEuN5z0GhwYO_cICOnw" } @@ -3155,15 +3166,15 @@

              "kid": "issuer-key-1", "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJu b25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaW - VyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3MzQ1NTQyMDYsICJzZF9oYXNo - IjogIkFHOXp6OTlMaG9OZzd3ZmItX3Z4VGlRcTRLeTAxRWQtQVpwQ1FNcC - 1IdjgifQ.pOqrUkS0i7mDwqcojUQFe5zjQYifBqvAaf96KoAjrdU_lSp1w - WJXOcWq0LeuFhkz0qUiKJGhV8FWVaXhbOQTFw" + VyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3MzcwNTExMDAsICJzZF9oYXNo + IjogIjFzWGdqM1k4TzM0NkFBb1FaaFVjN3N5S0VYZ0RLWjNrUXA1SzJURE + 5ydjQifQ.52_3LkkD8mJMmMSlyhVvi7F7tan8OfJ6UEwHX4E01y7CVahWU + xpQb7CyqH2lQ78hiWDMyhKDrZW0RC9UunTasg" }, "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", - "signature": "HSkWy4Zq8ushfemxzo7KMrID3zjc9rgCqu1DTc2HEMXxYdLP - 5B87o8gcjEjXIuKuKgupQ9B4vhMSKRV-G-uKmw" + "signature": "4lCKThsJc4_gOs8qF8VmO0JcZcpxeZAxH0SmsSPBYcHwurCp + -Us7mA8ytbXuVk66ddAb8vIz5YU8gFoGwonbiQ" }, { "header": { @@ -3171,8 +3182,8 @@

              }, "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", - "signature": "ZaLsMdMJ5T9462El3TM02cFrZCcohyS2Y9Ez-6eumi94GY0n - fiMqWimSOQIgNuUXBEatoRkCpQW2A9plf0X6uA" + "signature": "n0E5ztl6M2W1GPRKU2hs-qBQoloXb0aWvBO0NEhlZb_URmKm + lLN0v6wdK3mHwZ7PaiExiy9Hm0F_lKR-T1I3wQ" } ] } @@ -3212,7 +3223,7 @@

              explicitly disclosed by the Holder unless that information can be derived from other disclosed claims or sources other than the presented SD-JWT.

              Integrity: A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier.

              -

              Additionally, as described in Section 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.

              @@ -3308,7 +3319,7 @@

              9.5. Key Binding

              -

              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.

              +
              +
              +

              +9.12. Key Pair Generation and Lifecycle Management +

              +

              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:

              +
                +
              • Secure Generation: Using cryptographically secure methods and random number generators. +
                • +
              • Secure Storage: Protecting private keys from unauthorized access. +
                • +
              • Lifecycle Management: Ensuring secure key rotation, revocation, and disposal as needed. +
                • +
              +

              Appropriate key management is essential, as any compromise can lead to unauthorized disclosure or forgery of SD-JWTs.

              +
              +
              @@ -3497,17 +3529,20 @@

            • Presentation Unlinkability: A Verifier should not be able to link two presentations of the same credential.
              • -
            • Verifier/Verifier Unlinkability: Two colluding Verifiers should not be able to -learn that they have received presentations of the same credential. +
            • Verifier/Verifier Unlinkability: The presentations made to two different +Verifiers should not reveal that the same credential was presented (e.g., if the two +Verifiers collude, or if they are forced by a third party to reveal the presentations +made to them, or data leaks from one Verifier to the other).
            • Issuer/Verifier Unlinkability (Honest Verifier): An Issuer of a credential -should not be able to know that a user presented the credential to a certain -Verifier that is not behaving maliciously. +should not be able to know that a user presented this credential unless +the Verifier is sharing presentation data with the Issuer +accidentally, deliberately, or because it is forced to do so.
              • -
            • Issuer/Verifier Unlinkability (Colluding/Compromised Verifier): An Issuer of a -credential should not be able to tell that a user presented the credential to -a certain Verifier, even if the Verifier colludes with the Issuer or becomes -compromised and leaks stored credentials from presentations. +
            • Issuer/Verifier Unlinkability (Careless/Colluding/Compromised/Coerced Verifier): An Issuer of a +credential should under no circumstances be able to tell that a user presented this credential to +a certain Verifier. In particular this includes cases when the Verifier accidentally or deliberately shares +presentation data with the Issuer or is forced to do so.

            In all cases, unlinkability is limited to cases where the disclosed claims do @@ -3515,10 +3550,11 @@

            example, when a taxpayer identification number is contained in the disclosed claims, the Issuer and Verifier can easily link the user's transactions. However, when the user only discloses a birthdate to one Verifier and a postal code to another Verifier, the two Verifiers should not be able to determine that they were interacting with the same user.

            -

            Issuer/Verifier unlinkability with a colluding or compromised Verifier cannot be +

            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 @@

            beginning of the day).

            -
            +

            10.2. Storage of User Data @@ -3564,12 +3600,11 @@

            SD-JWTs may also allow attackers to impersonate Holders unless Key Binding is enforced and the attacker does not have access to the Holder's cryptographic keys.

            -

            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 @@

            credentials over centralized storage. Expired SD-JWTs SHOULD be deleted as soon as possible.

            After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT or the -respective Disclosures if they contain privacy-sensitive data. It may be +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.

            @@ -3993,6 +4031,10 @@

            IANA, "Structured Syntax Suffixs", <https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml>.
            +
            [NIST.SP.800-57pt1r5]
            +
            +Barker, E. and NIST, "Recommendation for key management:part 1 - general", NIST Special Publications (General) 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5, , <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf>.
            +
            [OIDC.IDA]
            Lodderstedt, T., Fett, D., Haine, M., Pulido, A., Lehmann, K., and K. Koiwai, "OpenID Connect for Identity Assurance 1.0", , <https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html>.
            @@ -4272,8 +4314,8 @@

            U1U3ZlNXZ3dGNVVEWm1Xd0JUdzMyZ25VbGRJaGk4aEdWQ2FWNCIsICJydkpkNmlxNlQ1 ZWptc0JNb0d3dU5YaDlxQUFGQVRBY2k0MG9pZEVlVnNBIiwgInVOSG9XWWhYc1poVkpD TkUyRHF5LXpxdDd0NjlnSkt5NVFhRnY3R3JNWDQiXX0sICJfc2RfYWxnIjogInNoYS0y -NTYifQ.pNnKy_BQ35LpG-dVxB1rBj1neA5fc88sn5RaleuXpTwSINLvtr0ccZII2U7nY -8jiHZmXZ8hYGlFAiQGURuGXjw~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2 +NTYifQ.WMxUESPBBrPKrD_9AU7HGwcEhUFx8WTM79BP9XsO22pzLVV_zv1sIgz26zARq +FOTSgR48n5z6VzofxsKuJbPtw~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2 lvbiIsICJcdTZlMmZcdTUzM2EiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImN vdW50cnkiLCAiSlAiXQ~ @@ -4624,8 +4666,8 @@

            TWsiLCAiV3hoX3NWM2lSSDliZ3JUQkppLWFZSE5DTHQtdmpoWDFzZC1pZ09mXzlsayIs ICJfTy13SmlIM2VuU0I0Uk9IbnRUb1FUOEptTHR6LW1oTzJmMWM4OVhvZXJRIiwgImh2 RFhod21HY0pRc0JDQTJPdGp1TEFjd0FNcERzYVUwbmtvdmNLT3FXTkUiXX19LCAiX3Nk -X2FsZyI6ICJzaGEtMjU2In0.Y_cjw1Kqy-xcgKA5bCIttKhRvLkyRmOCM_H6FgfxFobY -XTNxSolfYzZpB2Pd4qoMVC_1Arq0uClzW_9FKws7hw~WyIyR0xDNDJzS1F2ZUNmR2Zye +X2FsZyI6ICJzaGEtMjU2In0.wKsAwLLEJhcpIIFXFstrJS2KL2Lc3TjL6KiCDBxvb2Dk +TTCIZL7Tvwfc2OZ8Mpq2HbBQ2GEf8S-gW00JptM8UQ~WyIyR0xDNDJzS1F2ZUNmR2Zye U5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1QxODoyNVoiXQ~WyJQYzMzSk0yTGNoY1 VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDdQSzBuc1FETDhCMDZsbWRnVj NMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRX @@ -4745,8 +4787,8 @@

            6ICJzaGEtMjU2IiwgImNuZiI6IHsiandrIjogeyJrdHkiOiAiRUMiLCAiY3J2IjogIlA tMjU2IiwgIngiOiAiVENBRVIxOVp2dTNPSEY0ajRXNHZmU1ZvSElQMUlMaWxEbHM3dkN lR2VtYyIsICJ5IjogIlp4amlXV2JaTVFHSFZXS1ZRNGhiU0lpcnNWZnVlY0NFNnQ0alQ -5RjJIWlEifX19.kD-Fp0dmjOSBh2O7YPlrKsi9Uz-kld6yh8OMugqK-KMC1MzCgt_WkQ -rQZut6zAX6vLb6-flPSA2KP_8_CJu7RQ~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3Iiw +5RjJIWlEifX19.gubpvlnkPUKFme76H6RXgmzjqq4JsR8GAEPue7jRTHF6R3PsC-Ytp8 +-_yrvykwCSfmMTNoZ9N9Ou7QS4SbsSKA~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3Iiw gImdpdmVuX25hbWUiLCAiRXJpa2EiXQ~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwg ImZhbWlseV9uYW1lIiwgIk11c3Rlcm1hbm4iXQ~WyI2SWo3dE0tYTVpVlBHYm9TNXRtd lZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA4LTEyIl0~WyJlSThaV205UW5LUHBOUGVOZ @@ -5101,14 +5143,14 @@

            6ICJzaGEtMjU2IiwgImNuZiI6IHsiandrIjogeyJrdHkiOiAiRUMiLCAiY3J2IjogIlA tMjU2IiwgIngiOiAiVENBRVIxOVp2dTNPSEY0ajRXNHZmU1ZvSElQMUlMaWxEbHM3dkN lR2VtYyIsICJ5IjogIlp4amlXV2JaTVFHSFZXS1ZRNGhiU0lpcnNWZnVlY0NFNnQ0alQ -5RjJIWlEifX19.kD-Fp0dmjOSBh2O7YPlrKsi9Uz-kld6yh8OMugqK-KMC1MzCgt_WkQ -rQZut6zAX6vLb6-flPSA2KP_8_CJu7RQ~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiw +5RjJIWlEifX19.gubpvlnkPUKFme76H6RXgmzjqq4JsR8GAEPue7jRTHF6R3PsC-Ytp8 +-_yrvykwCSfmMTNoZ9N9Ou7QS4SbsSKA~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiw gIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d~WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIi wgIjE4IiwgdHJ1ZV0~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub 25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW1wb -GUub3JnIiwgImlhdCI6IDE3MzQ1NTQyMDYsICJzZF9oYXNoIjogIkU2eXZFdFhBR2oya -3ZZdkVHcV9sZHN3NHI2T1c0UXlHRU9vWGg0Y2pTMU0ifQ.xrD3u_HypAi4ffXjgn7DWy -vKccfYBOzpgpGg5ZZWRRGgTkkK9DZcdDvlzymvaYUDsRJphBvD-PIe2o-u4uvvgg +GUub3JnIiwgImlhdCI6IDE3MzcwNTExMDAsICJzZF9oYXNoIjogIjZYcDNVaWpxbVQwa +TZjTW9MSnhNVG05dHo5MDlWSWhYU3ZsUEVSOE94ck0ifQ.KmfM7WQMhWLu3_asVx5ukc +28B9kSaKGbP8Qqe-3N_qnTClV2GYvELFOX07bTnXVFWuo1zZIvC9pVX0cKkexxuA

            @@ -5117,8 +5159,8 @@ 

            {
   "nonce": "1234567890",
   "aud": "https://verifier.example.org",
-  "iat": 1734554206,
-  "sd_hash": "E6yvEtXAGj2kvYvEGq_ldsw4r6OW4QyGEOoXh4cjS1M"
+  "iat": 1737051100,
+  "sd_hash": "6Xp3UijqmT0i6cMoLJxMTm9tz909VIhXSvlPER8OxrM"
 }
            @@ -5231,8 +5273,8 @@

            c2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJj cnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxp bERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVj -Q0U2dDRqVDlGMkhaUSJ9fX0.h7E5VLNIi-7wE6Q-PP8W0pZL8b7SvUYtfbZX12Y-JdN0 -HwP-m1e9cmLntzQpqiEWFi8zcsI51pfpBnBHFhbPZQ~WyIyR0xDNDJzS1F2ZUNmR2Zye +Q0U2dDRqVDlGMkhaUSJ9fX0.HjSjnlv9tfZ63lUX6b8UxLD3OLkpuXdnHBKIE9r_7zfN +Nyw0vBliD_0erJaSXlbrn6Z9F90FcQc6ALAqfbxLmg~WyIyR0xDNDJzS1F2ZUNmR2Zye U5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4 QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9k ZXJuYSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml @@ -5514,18 +5556,18 @@

            c2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJj cnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxp bERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVj -Q0U2dDRqVDlGMkhaUSJ9fX0.h7E5VLNIi-7wE6Q-PP8W0pZL8b7SvUYtfbZX12Y-JdN0 -HwP-m1e9cmLntzQpqiEWFi8zcsI51pfpBnBHFhbPZQ~WyJQYzMzSk0yTGNoY1VfbEhnZ +Q0U2dDRqVDlGMkhaUSJ9fX0.HjSjnlv9tfZ63lUX6b8UxLD3OLkpuXdnHBKIE9r_7zfN +Nyw0vBliD_0erJaSXlbrn6Z9F90FcQc6ALAqfbxLmg~WyJQYzMzSk0yTGNoY1VfbEhnZ 3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwg ImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyIyR0xD NDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9 nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE 5IFZhY2NpbmUgTW9kZXJuYSJd~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dC J9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyL -mV4YW1wbGUub3JnIiwgImlhdCI6IDE3MzQ1NTQyMDYsICJzZF9oYXNoIjogIl9lV2lnS -TNaeWdIMW9jNV9HOFhfSGw3aHRCYkg3U0lmMy1jY3l4YjFOYk0ifQ.epQHzU2KlLq6dY -3kazBYZrwdg57vy9DcSgbulpa9rB_js_BpPslJxi6kj9gsZXG2wuo9Ut1Z9EG6YJhrGE -vQnA +mV4YW1wbGUub3JnIiwgImlhdCI6IDE3MzcwNTExMDAsICJzZF9oYXNoIjogIjgtLXh6R +DFzNG5zaDNsZlZKWHNkdkRYVDlxZkdYazRMbGJGNlhNVFhoNG8ifQ.TEf4zdLTf0GvRN +FMbzYV0xyChjUrPT9OOWuGyGDpTEsh8M6holph4yPailMqnd60ysHE-LhDWkXWcKULV7 +zUkw

            @@ -5700,328 +5742,335 @@

            Appendix C. Document History

            [[ 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

              -
            • Address WGLC (part 2) comments +
            • Address WGLC (part 2) comments
              • -
            • Note that the Hash Function Claim value is case-sensitive +
            • 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. +
            • 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

            +

            -13

              -
            • WGLC (part 1) updates +
            • WGLC (part 1) updates
              • -
            • Rewrote introduction +
            • Rewrote introduction
              • -
            • Added note on algorithm for Holder's verification of the SD-JWT +
            • Added note on algorithm for Holder's verification of the SD-JWT
            -

            -12

            +

            -12

              -
            • Clarify, add context, or otherwise improve the examples +
            • Clarify, add context, or otherwise improve the examples
              • -
            • Editorial and reference fixes +
            • Editorial and reference fixes
              • -
            • Better introduce the phrase processed SD-JWT payload in the end of Section 7.1 on Verifying the SD-JWT +
            • 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 +
            • 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 +
            • Remove the brief discussion of publishing private key(s) to attempt to reduce the value of leaked or stolen data
            -

            -11

            +

            -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) +
            • 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 +
            • Tightened the exposition
            -

            -10

            +

            -10

              -
            • Add a section clarifying recursive disclosures and their interdependencies +
            • Add a section clarifying recursive disclosures and their interdependencies
              • -
            • Editorial updates/fixes +
            • Editorial updates/fixes
            -

            -09

            +

            -09

              -
            • Distinguished SD-JWT from SD-JWT+KB +
            • Distinguished SD-JWT from SD-JWT+KB
              • -
            • Provide ABNF for the SD-JWT, SD-JWT+KB, and various constituent parts +
            • 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. +
            • 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 +
            • 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 +
            • Consolidate salt entropy and length security consideration subsections
              • -
            • Unnumbered most of the examples for improved clarity +
            • Unnumbered most of the examples for improved clarity
              • -
            • More definitive language around the exclusive use of the cnf claim for enabling Key Binding +
            • More definitive language around the exclusive use of the cnf claim for enabling Key Binding
            -

            -08

            +

            -08

              -
            • Make RFCs 0020 and 7515 normative references +
            • 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 +
            • Be a bit more prescriptive in suggesting RFC7800 cnf/jwk be used to convey the Key Binding key
              • -
            • Editorial changes aimed at improved clarity +
            • Editorial changes aimed at improved clarity
              • -
            • Improve unlinkability considerations, mention that different KB keys must be used +
            • Improve unlinkability considerations, mention that different KB keys must be used
              • -
            • Remove the explicit prohibition on HMAC +
            • Remove the explicit prohibition on HMAC
              • -
            • Remove mention of unspecified key binding methods and the Enveloping SD-JWTs section +
            • 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 +
            • Editorial updates aimed at more consistent treatment of a Disclosure vs the contents of a Disclosure
              • -
            • Update PID example +
            • Update PID example
              • -
            • Be more explicit that the VCDM and SD-JWT VC examples are only illustrative and do not define anything +
            • Be more explicit that the VCDM and SD-JWT VC examples are only illustrative and do not define anything
            -

            -07

            +

            -07

              -
            • Reference RFC4086 in security considerations about salt entropy +
            • Reference RFC4086 in security considerations about salt entropy
              • -
            • Update change controller for the Structured Syntax Suffix registration from IESG to IETF per IANA suggestion +
            • 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 +
            • 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 +
            • 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 +
            • 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 +
            • Better describe and illustrate the tilde separated format
              • -
            • Change claim name from _sd_hash to sd_hash +
            • Change claim name from _sd_hash to sd_hash
            -

            -06

            +

            -06

              -
            • Added hash of Issuer-signed part and Disclosures in KB-JWT +
            • Added hash of Issuer-signed part and Disclosures in KB-JWT
              • -
            • Fix minor issues in some examples +
            • Fix minor issues in some examples
              • -
            • Added IANA media type registration request for the JSON Serialization +
            • Added IANA media type registration request for the JSON Serialization
              • -
            • More precise wording around storing artifacts with sensitive data +
            • More precise wording around storing artifacts with sensitive data
              • -
            • The claim name _sd or ... must not be used in a disclosure. +
            • The claim name _sd or ... must not be used in a disclosure.
              • -
            • Added JWT claims registration requests to IANA +
            • Added JWT claims registration requests to IANA
              • -
            • Ensure claims that control validity are checked after decoding payload +
            • Ensure claims that control validity are checked after decoding payload
              • -
            • Restructure sections around data formats and Example 1 +
            • 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 +
            • 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 +
            • Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs
            -

            -05

            +

            -05

              -
            • Consolidate processing rules for Holder and Verifier +
            • Consolidate processing rules for Holder and Verifier
              • -
            • Add support for selective disclosure of array elements. +
            • Add support for selective disclosure of array elements.
              • -
            • Consolidate SD-JWT terminology and format +
            • Consolidate SD-JWT terminology and format
              • -
            • Use the term Key Binding rather than Holder Binding +
            • Use the term Key Binding rather than Holder Binding
              • -
            • Defined the structure of the Key Binding JWT +
            • Defined the structure of the Key Binding JWT
              • -
            • Added a JWS JSON Serialization +
            • Added a JWS JSON Serialization
              • -
            • Added initial IANA media type and structured suffix registration requests +
            • Added initial IANA media type and structured suffix registration requests
              • -
            • Added recommendation for explicit typing of SD-JWTs +
            • Added recommendation for explicit typing of SD-JWTs
              • -
            • Added considerations around forwarding credentials +
            • Added considerations around forwarding credentials
              • -
            • Removed Example 2b and merged the demo of decoy digests into Example 2a +
            • Removed Example 2b and merged the demo of decoy digests into Example 2a
              • -
            • Improved example for allowed variations in Disclosures +
            • 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 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 +
            • Added some security considerations text about the scope of the Key Binding JWT
              • -
            • Aligned examples structure and used the term input JWT Claims Set +
            • 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 +
            • 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 +
            • Added/clarified some privacy considerations in Confidentiality during Transport
              • -
            • No longer recommending a claim name for enveloped SD-JWTs +
            • No longer recommending a claim name for enveloped SD-JWTs
              • -
            • Mention prospective future PQ algs for JWS +
            • Mention prospective future PQ algs for JWS
              • -
            • Include the public key in the draft, which can be used to verify the issuer signature examples +
            • 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 +
            • Clarify that _sd_alg can only be at the top level of the SD-JWT payload
              • -
            • Externalized the SD-JWT library that generates examples +
            • Externalized the SD-JWT library that generates examples
              • -
            • Attempt to improve description of security properties +
            • Attempt to improve description of security properties
            -

            -04

            +

            -04

              -
            • Improve description of processing of disclosures +
            • Improve description of processing of disclosures
            -

            -03

            +

            -03

              -
            • Clarify that other specifications may define enveloping multiple Combined Formats for Presentation +
            • 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 +
            • 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 +
            • Clarify requirements for the combined formats for issuance and presentation
              • -
            • Added overview of the Security Considerations section +
            • Added overview of the Security Considerations section
              • -
            • Enhanced examples in the Privacy Considerations section +
            • Enhanced examples in the Privacy Considerations section
              • -
            • Allow for recursive disclosures +
            • Allow for recursive disclosures
              • -
            • Discussion on holder binding and privacy of stored credentials +
            • 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 +
            • 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) +
            • 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 +
            • Make sha-256 the default hash algorithm, if the hash alg claim is omitted
              • -
            • Use ES256 instead of RS256 in examples +
            • Use ES256 instead of RS256 in examples
              • -
            • Rename and move the c14n challenges section to an appendix +
            • 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) +
            • 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 +
            • Remove the notational figures from the Concepts section
              • -
            • Change salt to always be a string (rather than any JSON type) +
            • Change salt to always be a string (rather than any JSON type)
              • -
            • Fix the Document History (which had a premature list for -03) +
            • Fix the Document History (which had a premature list for -03)
            -

            -02

            +

            -02

              -
            • Disclosures are now delivered not as a JWT but as separate base64url-encoded JSON objects. +
            • 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. +
            • In the SD-JWT, digests are collected under a _sd claim per level.
              • -
            • Terms "II-Disclosures" and "HS-Disclosures" are replaced with "Disclosures". +
            • 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. +
            • 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 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. +
            • Examples are now pulled in from the examples directory, not inlined.
              • -
            • Updated and automated the W3C VC example. +
            • 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. +
            • 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) +
            • reverted back to hash alg from digest derivation alg (renamed to _sd_alg)
              • -
            • reformatted +
            • reformatted
            -

            -01

            +

            -01

              -
            • introduced blinded claim names +
            • introduced blinded claim names
              • -
            • explained why JSON-encoding of values is needed +
            • explained why JSON-encoding of values is needed
              • -
            • explained merging algorithm ("processing model") +
            • explained merging algorithm ("processing model")
              • -
            • generalized hash alg to digest derivation alg which also enables HMAC to calculate digests +
            • generalized hash alg to digest derivation alg which also enables HMAC to calculate digests
              • -
            • - _sd_hash_alg renamed to sd_digest_derivation_alg +
            • + _sd_hash_alg renamed to sd_digest_derivation_alg
              • -
            • Salt/Value Container (SVC) renamed to Issuer-Issued Disclosures (II-Disclosures) +
            • 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-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 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
              • -
            • clarified relationship between sd_hs_disclosure and SD-JWT +
            • clarified relationship between sd_hs_disclosure and SD-JWT
              • -
            • clarified combined formats for issuance and presentation +
            • clarified combined formats for issuance and presentation
              • -
            • clarified security requirements for blinded claim names +
            • clarified security requirements for blinded claim names
              • -
            • improved description of Holder Binding security considerations - especially around the usage of "alg=none". +
            • improved description of Holder Binding security considerations - especially around the usage of "alg=none".
              • -
            • updated examples +
            • updated examples
              • -
            • text clarifications +
            • text clarifications
              • -
            • fixed cnf structure in examples +
            • fixed cnf structure in examples
              • -
            • added feature summary +
            • added feature summary
            -

            -00

            +

            -00

              -
            • Upload as draft-ietf-oauth-selective-disclosure-jwt-00 +
            • Upload as draft-ietf-oauth-selective-disclosure-jwt-00
            -

            [[ pre Working Group Adoption: ]]

            -

            -02

            +

            [[ pre Working Group Adoption: ]]

            +

            -02

              -
            • Added acknowledgements +
            • Added acknowledgements
              • -
            • Improved Security Considerations +
            • Improved Security Considerations
              • -
            • Stressed entropy requirements for salts +
            • Stressed entropy requirements for salts
              • -
            • Python reference implementation clean-up and refactoring +
            • Python reference implementation clean-up and refactoring
              • -
            • - hash_alg renamed to _sd_hash_alg +
            • + hash_alg renamed to _sd_hash_alg
            -

            -01

            +

            -01

              -
            • Editorial fixes +
            • Editorial fixes
              • -
            • Added hash_alg claim +
            • Added hash_alg claim
              • -
            • Renamed _sd to sd_digests and sd_release +
            • Renamed _sd to sd_digests and sd_release
              • -
            • Added descriptions on Holder Binding - more work to do +
            • Added descriptions on Holder Binding - more work to do
              • -
            • Clarify that signing the SD-JWT is mandatory +
            • Clarify that signing the SD-JWT is mandatory
            -

            -00

            +

            -00

              -
            • Renamed to SD-JWT (focus on JWT instead of JWS since signature is optional) +
            • Renamed to SD-JWT (focus on JWT instead of JWS since signature is optional)
              • -
            • Make Holder Binding optional +
            • Make Holder Binding optional
              • -
            • Rename proof to release, since when there is no signature, the term "proof" can be misleading +
            • Rename proof to release, since when there is no signature, the term "proof" can be misleading
              • -
            • Improved the structure of the description +
            • Improved the structure of the description
              • -
            • Described verification steps +
            • Described verification steps
              • -
            • All examples generated from python demo implementation +
            • All examples generated from python demo implementation
              • -
            • Examples for structured objects +
            • Examples for structured objects
            diff --git a/iso-frustrated-by-iso/draft-ietf-oauth-selective-disclosure-jwt.txt b/iso-frustrated-by-iso/draft-ietf-oauth-selective-disclosure-jwt.txt index 2d8cc414..1ac6f6a8 100644 --- a/iso-frustrated-by-iso/draft-ietf-oauth-selective-disclosure-jwt.txt +++ b/iso-frustrated-by-iso/draft-ietf-oauth-selective-disclosure-jwt.txt @@ -5,10 +5,10 @@ Web Authorization Protocol D. Fett Internet-Draft Authlete Intended status: Standards Track K. Yasuda -Expires: 21 June 2025 Keio University +Expires: 20 July 2025 Keio University B. Campbell Ping Identity - 18 December 2024 + 16 January 2025 Selective Disclosure for JWTs (SD-JWT) @@ -47,11 +47,11 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 21 June 2025. + This Internet-Draft will expire on 20 July 2025. Copyright Notice - 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 @@ -116,6 +116,7 @@ Table of Contents 9.9. Forwarding Credentials 9.10. Integrity of SD-JWTs and SD-JWT+KBs 9.11. Explicit Typing + 9.12. Key Pair Generation and Lifecycle Management 10. Privacy Considerations 10.1. Unlinkability 10.2. Storage of User Data @@ -215,9 +216,9 @@ Table of Contents binding when presented to the Verifier. It comprises the following: - * A facility for associating an SD-JWT with a key pair - * A format for a Key Binding JWT (KB-JWT) that proves possession - of the private key of the associated 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 + possession of the private key of the associated key pair * A format extending the SD-JWT format for the combined transport of the SD-JWT and the KB-JWT @@ -249,15 +250,16 @@ Table of Contents The Disclosure is used to calculate a digest for the respective claim. The term Disclosure refers to the whole base64url-encoded string. - Key Binding: Ability of the Holder to prove legitimate possession of - an SD-JWT by proving control over a private key during the - presentation. When utilizing Key Binding, an SD-JWT contains the - public key corresponding to the private key controlled by the - Holder (or a reference to this public key). - Key Binding JWT (KB-JWT): A JWT for proving Key Binding as defined - in Section 4.3. A Key Binding JWT is said to "be tied to" a - particular SD-JWT when its payload includes a hash of the SD-JWT - in its sd_hash claim. + 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 + 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 + included in the SD-JWT payload, and also contains a hash of the + SD-JWT in its sd_hash claim. A JWT for proving Key Binding as + defined in Section 4.3. 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. @@ -287,7 +289,7 @@ Table of Contents | | +------------+ | - Presents SD-JWT+KB + Presents SD-JWT or SD-JWT+KB including selected Disclosures | v @@ -321,7 +323,7 @@ Table of Contents 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 + 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. @@ -446,9 +448,9 @@ Table of Contents ~~~ - 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 @@ -1088,8 +1090,8 @@ Table of Contents InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG - MkhaUSJ9fX0.KoZGuv5lw09OSCaDPWsw1blPSkvUOHNpe3mmj6ZZJsWf8ch9Bn1KGdKW - Ox1tY111cfzdxi0ezk5VjUyBqD24nQ + MkhaUSJ9fX0.rvsNKVN_VkKbr7ESx7Km-PQSiwKXDGWbtHjWGITfA25G9uLFIS8piVjB + YpcoPA8ml7ga9cLhXBh2FWWB2xYZDg Adding the Disclosures produces the SD-JWT: @@ -1109,8 +1111,8 @@ Table of Contents InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG - MkhaUSJ9fX0.KoZGuv5lw09OSCaDPWsw1blPSkvUOHNpe3mmj6ZZJsWf8ch9Bn1KGdKW - Ox1tY111cfzdxi0ezk5VjUyBqD24nQ~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgI + MkhaUSJ9fX0.rvsNKVN_VkKbr7ESx7Km-PQSiwKXDGWbtHjWGITfA25G9uLFIS8piVjB + YpcoPA8ml7ga9cLhXBh2FWWB2xYZDg~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgI mdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZh bWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWl sIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZW5IZGhR @@ -1148,18 +1150,18 @@ Table of Contents InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG - MkhaUSJ9fX0.KoZGuv5lw09OSCaDPWsw1blPSkvUOHNpe3mmj6ZZJsWf8ch9Bn1KGdKW - Ox1tY111cfzdxi0ezk5VjUyBqD24nQ~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgI + MkhaUSJ9fX0.rvsNKVN_VkKbr7ESx7Km-PQSiwKXDGWbtHjWGITfA25G9uLFIS8piVjB + YpcoPA8ml7ga9cLhXBh2FWWB2xYZDg~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgI mZhbWlseV9uYW1lIiwgIkRvZSJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFk ZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5 IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMi fV0~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~eyJhbGciOiAiRVMyNTYiLCA idHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodH - RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3MzQ1NTQyMDYsICJzZF - 9oYXNoIjogInRyUGlYZkNiRVBXQWlHeUtCZHdKMzNZbnJuNnRFejRaMDV6aU9qLWdRYm - cifQ.lA-YiuO3z0MRIU8Eec8b93psLm4O2uU58CzncqJu5s0iKjMeoQFPu5vL2qijieA - 4lXWGTQsd_8wWI2K5wQcIQA + RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3MzcwNTExMDAsICJzZF + 9oYXNoIjogIlRWcjJ4QjZRTy15QlRxN25kczU0djB0Zlh1bFRuamFqallVRnRQTGNISk + EifQ.uYbouVfj5T2iKaQVAlmf3By4Pcx8AS8ZdTgORWlXbu12V1MBxlOt-KAAUEq2AKq + vA4FFfxu-l9cXthstylLpEw The following Key Binding JWT payload was created and signed for this presentation by the Holder: @@ -1167,8 +1169,8 @@ Table of Contents { "nonce": "1234567890", "aud": "https://verifier.example.org", - "iat": 1734554206, - "sd_hash": "trPiXfCbEPWAiGyKBdwJ33Ynrn6tEz4Z05ziOj-gQbg" + "iat": 1737051100, + "sd_hash": "TVr2xB6QO-yBTq7nds54v0tfXulTnjajjYUFtPLcHJA" } If the Verifier did not require Key Binding, then the Holder could @@ -1438,7 +1440,8 @@ Table of Contents recursively included in the contents of other Disclosures). The Holder or the Verifier MUST perform the following (or equivalent) - steps when receiving an SD-JWT: + steps when 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 Disclosures (if any). @@ -1524,8 +1527,17 @@ Table of Contents 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. + 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 + extract the payload. + 2. Ensure that the contents of claims in the payload are acceptable + (depending on the application; for example, check that any values + the Holder can check are correct). + For presentation to a Verifier, the Holder MUST perform the following - (or equivalent) steps: + (or equivalent) steps (in addition to the checks described in + Section 7.1 performed after receiving the SD-JWT): 1. Decide which Disclosures to release to the Verifier, obtaining proper consent if necessary. @@ -1548,7 +1560,7 @@ Table of Contents 7.3. Verification by the Verifier 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 + SD-JWT or an SD-JWT+KB, in addition to the checks described in Section 7.1, Verifiers need to ensure that * if Key Binding is required, then the Holder has provided an SD- @@ -1566,7 +1578,8 @@ Table of Contents (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 and a Key Binding JWT. - 4. Process the SD-JWT as defined in Section 7.1. + 4. Process the SD-JWT as defined in Section 7.1 to validate the + presentation and extract the payload. 5. If Key Binding is required: 1. Determine the public key for the Holder from the SD-JWT (see Section 4.1.2). @@ -1661,8 +1674,8 @@ Table of Contents Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", - "signature": "7F8WwZOBl5pTvKalfYaxF6aaJ6UtO6uPzySe2FZfQpG6DBG8Upjj - C1Ai9kAaJ85O11JomjKRKf47CGA2kF6MBA" + "signature": "y1Zqi908WOXZfYxUEbxv1T0-o9rkNUOcFSJ1vpMUiCLoI7H0cfd8 + IMIn0lqSo6Jx63KxEuN5z0GhwYO_cICOnw" } The following is an SD-JWT+KB with two Disclosures: @@ -1677,10 +1690,10 @@ Table of Contents ], "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25j ZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW - 1wbGUub3JnIiwgImlhdCI6IDE3MzQ1NTQyMDYsICJzZF9oYXNoIjogIm9KMUZr - WkxNVnp1WTc3cE5hOTBoeWNGSk1UcjAzcUNfWV9kWDJkZnplQ0UifQ.fTH2vYQ - 2oaVDwnAfUKoTcFzY1wWIEeYumus0ZDuCZrU0E-mOq5tJ8Z5-GmLQ3DJFQTrKC - XgfBQ21KQSNc8rpPw" + 1wbGUub3JnIiwgImlhdCI6IDE3MzcwNTExMDAsICJzZF9oYXNoIjogIkRzVTE4 + TTR5VnVIcEE4YUJTT1VEZWZaWlE0SXg4dGJFd29rOFgzdzJyYUkifQ.R6p9nmo + dd8E058MhMrADzXEMkPmOE6oX6n4jIPyuTCn2urkT2jixOOtY9RaokTRFyAGqD + 86TLOpLt2LOmubqkg" }, "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV @@ -1694,8 +1707,8 @@ Table of Contents Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ", "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", - "signature": "7F8WwZOBl5pTvKalfYaxF6aaJ6UtO6uPzySe2FZfQpG6DBG8Upjj - C1Ai9kAaJ85O11JomjKRKf47CGA2kF6MBA" + "signature": "y1Zqi908WOXZfYxUEbxv1T0-o9rkNUOcFSJ1vpMUiCLoI7H0cfd8 + IMIn0lqSo6Jx63KxEuN5z0GhwYO_cICOnw" } 8.3. General JSON Serialization @@ -1732,15 +1745,15 @@ Table of Contents "kid": "issuer-key-1", "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJu b25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaW - VyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3MzQ1NTQyMDYsICJzZF9oYXNo - IjogIkFHOXp6OTlMaG9OZzd3ZmItX3Z4VGlRcTRLeTAxRWQtQVpwQ1FNcC - 1IdjgifQ.pOqrUkS0i7mDwqcojUQFe5zjQYifBqvAaf96KoAjrdU_lSp1w - WJXOcWq0LeuFhkz0qUiKJGhV8FWVaXhbOQTFw" + VyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3MzcwNTExMDAsICJzZF9oYXNo + IjogIjFzWGdqM1k4TzM0NkFBb1FaaFVjN3N5S0VYZ0RLWjNrUXA1SzJURE + 5ydjQifQ.52_3LkkD8mJMmMSlyhVvi7F7tan8OfJ6UEwHX4E01y7CVahWU + xpQb7CyqH2lQ78hiWDMyhKDrZW0RC9UunTasg" }, "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", - "signature": "HSkWy4Zq8ushfemxzo7KMrID3zjc9rgCqu1DTc2HEMXxYdLP - 5B87o8gcjEjXIuKuKgupQ9B4vhMSKRV-G-uKmw" + "signature": "4lCKThsJc4_gOs8qF8VmO0JcZcpxeZAxH0SmsSPBYcHwurCp + -Us7mA8ytbXuVk66ddAb8vIz5YU8gFoGwonbiQ" }, { "header": { @@ -1748,8 +1761,8 @@ Table of Contents }, "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0", - "signature": "ZaLsMdMJ5T9462El3TM02cFrZCcohyS2Y9Ez-6eumi94GY0n - fiMqWimSOQIgNuUXBEatoRkCpQW2A9plf0X6uA" + "signature": "n0E5ztl6M2W1GPRKU2hs-qBQoloXb0aWvBO0NEhlZb_URmKm + lLN0v6wdK3mHwZ7PaiExiy9Hm0F_lKR-T1I3wQ" } ] } @@ -1782,7 +1795,7 @@ Table of Contents 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. + Holder of the credential. 9.1. Mandatory Signing of the Issuer-signed JWT @@ -1889,11 +1902,11 @@ Table of Contents 9.5. Key Binding Key Binding aims to ensure that the presenter of an SD-JWT credential - is actually the legitimate 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. + 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 credential was issued by a particular Issuer, but the credential @@ -2043,6 +2056,26 @@ Table of Contents type of the SD-JWT payload can also be used to distinguish different types of JSON objects, or different kinds of JWT Claim Sets. +9.12. Key Pair Generation and Lifecycle Management + + 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: + + * Secure Generation: Using cryptographically secure methods and + random number generators. + * Secure Storage: Protecting private keys from unauthorized access. + * Lifecycle Management: Ensuring secure key rotation, revocation, + and disposal as needed. + + Appropriate key management is essential, as any compromise can lead + to unauthorized disclosure or forgery of SD-JWTs. + 10. Privacy Considerations 10.1. Unlinkability @@ -2067,17 +2100,22 @@ Table of Contents * Presentation Unlinkability: A Verifier should not be able to link two presentations of the same credential. - * Verifier/Verifier Unlinkability: Two colluding Verifiers should - not be able to learn that they have received presentations of the - same credential. + * Verifier/Verifier Unlinkability: The presentations made to two + different Verifiers should not reveal that the same credential was + presented (e.g., if the two Verifiers collude, or if they are + forced by a third party to reveal the presentations made to them, + or data leaks from one Verifier to the other). * Issuer/Verifier Unlinkability (Honest Verifier): An Issuer of a - credential should not be able to know that a user presented the - credential to a certain Verifier that is not behaving maliciously. - * Issuer/Verifier Unlinkability (Colluding/Compromised Verifier): An - Issuer of a credential should not be able to tell that a user - presented the credential to a certain Verifier, even if the - Verifier colludes with the Issuer or becomes compromised and leaks - stored credentials from presentations. + credential should not be able to know that a user presented this + credential unless the Verifier is sharing presentation data with + the Issuer accidentally, deliberately, or because it is forced to + do so. + * Issuer/Verifier Unlinkability (Careless/Colluding/Compromised/ + Coerced Verifier): An Issuer of a credential should under no + circumstances be able to tell that a user presented this + credential to a certain Verifier. In particular this includes + cases when the Verifier accidentally or deliberately shares + presentation data with the Issuer or is forced to do so. In all cases, unlinkability is limited to cases where the disclosed claims do not contain information that directly or indirectly @@ -2088,11 +2126,13 @@ Table of Contents Verifier, the two Verifiers should not be able to determine that they were interacting with the same user. - Issuer/Verifier unlinkability with a colluding or compromised - Verifier cannot be achieved in salted-hash based selective disclosure - approaches, such as SD-JWT, as the issued credential with the - Issuer's signature is directly presented to the Verifier, who can - forward it to the Issuer. + 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. 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 @@ -2146,13 +2186,13 @@ Table of Contents attackers to impersonate Holders unless Key Binding is enforced and the attacker does not have access to the Holder's cryptographic keys. - 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. + respective Disclosures. Holders SHOULD store SD-JWTs only in encrypted form, and, wherever possible, use hardware-backed encryption in particular for the @@ -2162,9 +2202,14 @@ Table of Contents possible. After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT - or the respective Disclosures if they contain privacy-sensitive data. - It may be sufficient to store the result of the verification and any - user data that is needed for the application. + or the respective Disclosures. It may be sufficient to store the + result of the verification and any user data that is needed for the + application. + + 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. 10.3. Confidentiality during Transport @@ -2474,6 +2519,14 @@ Table of Contents . + [NIST.SP.800-57pt1r5] + Barker, E. and NIST, "Recommendation for key + management:part 1 - general", NIST Special Publications + (General) 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5, + May 2020, + . + [OIDC.IDA] Lodderstedt, T., Fett, D., Haine, M., Pulido, A., Lehmann, K., and K. Koiwai, "OpenID Connect for Identity Assurance 1.0", 24 July 2024,