Denis, I have the following responses inline marked as [DC] in the summary only (to save pages and pages of reading)
I have asked for two changes, which the authors have already published in a new draft. There is one issue/change that is in progress. Note: I still do not see where the typo occurs in this (very long) message chain. Deb Cooley Sec AD On Mon, Apr 14, 2025 at 1:21 PM Denis <denis.i...@free.fr> wrote: > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: - 'Selective Disclosure for JWTs > (SD-JWT)' > <draft-ietf-oauth-selective-disclosure-jwt-17.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to > thelast-c...@ietf.org mailing lists by 2025-04-14. Exceptionally, comments may > be sent to i...@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > > > > > > > > > > > > *The following comments are posted exceptionally to i...@ietf.org > <i...@ietf.org>, because previously I responded to the first and second WG > LC and I got no reply to my comments. After the second WG LC, I have posted > on github https://github.com/oauth-wg/oauth-selective-disclosure-jwt > <https://github.com/oauth-wg/oauth-selective-disclosure-jwt> 40 issues > numbered #482 until #522 that have not been responded. Then after 16 > comments: #546 to #562, that have not been responded either. Hence, many > of the comments that are posted today are not new comments. I believe that > some of them are substantive. I made a full review of the document (with > the exception of the appendices) and I will first present my 17 comments > shortly. A. As currently described, the protocol is insecure as it can be > subject to security attacks that have not been identified. * > > * The draft considers "colluding Verifiers and Issuers" but omits to > consider "colluding Holders and users" which can also exist. * > [DC] Not a new comment: Last time around I called this an implementation issue (holders w/ hardware key stores and such). Most of the key handling/storage/protection parts are covered in Section 9.12 which states that keys have to be protected across the lifecycle. No change required. > > * A detailed example of such an attack is provided. Key binding does not > provide a proof of *possession* of a private key (PoP) but only a proof of > *use* of a private key (PoU). The difference is quite important. Detailed > explanations are provided. * > [DC] Not a new comment. This is editorial at best. Use of a private key via signed message is a classic way of proving possession of that key for the last 35 years at least. Certainly, the entity that performs the signature possesses the key. No change required. * See comments 1, 2, 3, 4 and 5 under the topic **COLLUDING HOLDERS AND > USERS** and **under the topic* *KEY BINDING**.* > > > *B. As currently described, there is insufficient guidance in the draft > that allows to correctly implement a **Key Binding JWT* > > * replay detection mechanism. In general, two methods can be used, but the > draft does not allow to know which one has been selected by the Holder. The > processing by the Holder and by Verifier is insufficiently explained. See > comment 6 under the topic of REPLAY DETECTION OF a **Key Binding JWT* > *.* > [DC] Not a new comment: In fact, Section 7.3 #6 lays out the components to detect replay. To clarify, your position has shifted from not requiring iat to replacing the nonce with two separate fields (rdn and chal). *For the authors: Section 7.3, #6: protection/detection. > * C. **SD-JWT SUSPENSION OR REVOCATION IS MISSING* > * (See comment 7)* > *[DC] For the authors: The very first bullet of Section 7.1 states: “the Issuer-signed JWT is valid, i.e., it is signed by the Issuer and the signature is valid,..” Change to: “the Issuer-signed JWT is valid, i.e., it is signed by the Issuer, the signature is valid, and it is not suspended or revoked,…” > * D. **UNLINKABILITY** It is important to introduce the term "one**-time-use > digital **credential" (See **comment 8)* > *.* > [DC] as written now, a Holder can use a credential once. No change required. > > > *E. POST-QUANTUM RESISTANCE KEY BINDING ALGORITHMS * > > * I propose to add a new section that explains how one-time-use digital > credentials that include a public binding key * > *can support Post-Quantum resistant key binding algorithms. Even if the > document does not mandate the use of * > *any specific asymmetrical algorithm, this information can be useful for > implementers **as it is not widely shared* > *. **(See **comment 9).* > > [DC] This is not a new comment. This response is also not new: This draft does not specify the selection of the algorithm used for signing either SD-JWT or SD-JWT-KB. It does point to “digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry”, and it does specify that it MUST NOT be ‘NONE’. When the JOSE working group specifies post quantum signature algorithms, then they will be available to be used to sign SD-JWT. > > * F. VOCABULARY * > > *Since Figure 1 does not describe the interactions between the Holder > software and hardware and a human user* > *a Holder can only be the **"software and hardware" (**See **comment 10).* > > [DC] Again, not a new comment: The suggestion is pertinent for one possible implementation of the format. Keeping the format language clear and concise is important. > > * G. ARRAY ELEMENTS. Various comments (See comments 11 and 12).* > *[DC] 11. A potential for a slight change, in progress… [DC] 12. multiple nationalities are already mentioned/described in Section 4.2.6. No change required. > > > * H. KEY PAIR GENERATION AND LIFECYCLE MANAGEMENT (See a minor comment > 13).* > [DC] there is no mention of honest and dishonest owners in NIST SP 800-57 part 1, r5. How exactly does this lead to a false sense of security? No changes required. > > > * I. EDITORIAL COMMENTS (See comments 14 to 17).* > [DC] none of these require changes. Either they are clear already, the editor will correct grammar, colluding Verifiers are indeed adversaries, and integrity is already provided why is extra integrity protection required. > > > * ============================================================ **COLLUDING > HOLDERS AND USERS* > > * 1. * > *Collaborative attacks between colluding users and Holders * > > > > > > > > > > > > > > > > > > > > > > > > > > *Page 12 states: It is out of the scope of this document to describe > how the Holder 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 the key pair for the Holder, or Holder and Issuer MAY use pre- > established key material. The document does not also consider how the > protection of the *use* of the key pair should be done. Whether this > protection is "good", "weak" or inexistent has a great importance. As a > simple example, if the key pair can be exported from a Holder and then > imported into another Holder, then that other Holder will be able to use > the private key and get advantage of SD-JWTs that were under the control of > the first Holder. A more elaborated example is the ability for a Holder to > perform all the cryptographic computations that are necessary for another > Holder without releasing the value of the private key to that other Holder. > In that case, key binding does not provide a proof of *possession* of a > private key (PoP) but only a proof of *use* of a private key (PoU). > Collaborative attacks between "colluding user and Holders", which imply the > use of Holders specifically developed to cheat a Verifier should be > mentioned. This should also be addressed using an additional section under > section 9 (Security Considerations). **It is thus proposed to add a > section 9.13 about Collaborative attacks between **colluding users and > Holders* > > > > > *. The text change proposals for the others sections will be presented > afterwards. Text proposal: 9.13 Collaborative attacks between **colluding > users and Holders* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * If two users accept to collaborate, the Holder used by one user can > perform cryptographic computations for the benefit of another Holder. > For example, an application (i.e., a Holder) developed by a specialist > can be downloaded by each user. If that application is able to use the > private keys from an original Holder, the second Holder can perform > cryptographic computations for the benefit of another Holder. An > example scenario is as follows: a Holder A connects to a Verifier and > receives back a challenge and a list of claim types that it will need to > present to get an access. The Holder A forwards to a Holder B the > challenge received from the Verifier, the name of the Verifier and the > set of claim types and values that it wishes to present to the > Verifier. The Holder A receives back from the other Holder B the data > structure that the Holder A needs to present to get an access to that > Verifier. The Holder A forwards it to the Verifier and gets the access. > Another example scenario is as follows: if private keys can be > exported from the Holder with the user consent and then used by another > Holder, impersonation of the user can be achieved by the second Holder. > It is outside the scope of this document to specify how a Verifier > can know whether appropriate characteristics or properties are > effectively used by a Holder to ensure that collaborative attacks cannot > be performed between Holders. KEY BINDING 2. On page 4, the text states: * > > > > > > * To prevent attacks in which an SD-JWT is presented to a Verifier > without the Holder's consent, this specification additionally defines a > mechanism for binding the SD-JWT to a key under the control of the > Holder (Key Binding). When Key Binding is enforced, a Holder has to > prove possession of a private key belonging to a public key contained in > the SD-JWT itself. * > > > > > > > *The private key is only presumed to be under the control of the Holder. > The protocol does not allow to demonstrate that it is really the case, > since the characteristics of the Holder are unknown to the Verifier. A > Verifier can only check that a Holder has been able to *use* a private key > associated with a public key contained in a SD-JWT. * > > *Text change proposal: * > > > > > * This specification defines a mechanism for binding the SD-JWT to a > key that is presumed to be under the control of the Holder (Key > Binding). When Key Binding is enforced, a Verifier can check that a > Holder has been able to use a private key associated with a public key > contained in the SD-JWT. * > > > > * 3. On page 6, the text states: * > > > > > * 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 Binging only allows to demonstrate that a private key that is > associated with a public key placed into a SD-JWT has been correctly used. > It does not allow to known that the private key is indeed *possessed* by a > Holder, since characteristics of the Holder are unknown to the Verifier. * > > *Text change proposal: * > > > > > > > * Key Binding: Ability of the Holder to prove the ability to use a > private key associated with a public key contained in an SD-JWT > by using this private key during the presentation. When utilizing > Key Binding, an SD-JWT contains the public key corresponding to the > private key used by the Holder (or a reference to this public key). * > *4.** On page 43, section * > > > > > > > > *9.5. Key Binding states: 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. * > * It is well known that the wording "* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *prove possession of a private key" has been used for years. However, > strictly speaking the use of the word "possession" is incorrect. From a > Verifier point of view, a correct SD-JWT+KB proves the *use* of the private > key associated with a public binding key contained in a Key Binding JWT and > it does not necessarily prove the *possession* of it (See comment 1). This > private key can *EITHER* be used by the (legitimate) Holder *OR* can be > used by the Holder for the benefit of another Holder (see the example in > the previous comment). When using the protocols described in this document, > it is impossible for a Verifier to make the distinction between these two > cases. The document is implicitly considering (without never stating it) > that Holders and users are "honest", whereas this will not necessarily be > the case. The document considers "colluding Verifiers and Issuers" but does > not consider "colluding Holders and users" which can also exist. Therefore > this is a major security issue which has not been identified and that makes > this protocol insecure. A false sense of security might be inferred when > implementing this document. This should be said. Text change proposal: > An SD-JWT compatible with Key Binding contains a public key, or a > reference to a public key, that corresponds to a private key that can be > used by a Holder either for its own benefit or for the benefit of > another Holder. When presenting a key Binding JWT, the Verifier > requires that the Holder demonstrates the use of the private key. * > > > > * 5. On page 12. Section 4.1.2, the text states: * > > * It is out of the scope of this document to describe how the Holder > key pair is established. * > > > > *This text is fine. However, it would be useful to add that it is also out > of the scope of this document to describe how the private key is protected > and usable by the Holder under the control of the user. * > > *Text change proposal: * > > > * It is out of the scope of this document to describe how the Holder > key pair is established and how the private key is protected and usable > by the Holder under the control of the user. * > > * REPLAY DETECTION OF a **Key Binding JWT* > > * 6. Section * > > > > > > > > > > > > > > > > > *4.3. Key Binding JWT states: The Key Binding JWT MUST be a JWT > according to [RFC7519] and its payload MUST contain the following > elements: * (...) * in the JWT payload, - iat: REQUIRED. > The value of this claim MUST be the time at which the Key Binding > JWT was issued using the syntax defined in [RFC7519]. - > nonce: REQUIRED. Ensures the freshness of the signature. The > value type of this claim MUST be a string. How this value is > obtained is up to the protocol used and out of scope of this > specification. * > > * This description does not allow to interoperate in a secure fashion in > particular while reading section **7.3. Verification by the Verifier* > > > > > > *. How replay *detection* can be done is not described in the document. > Note: While replay *prevention* cannot be done, replay *detection* can be > done. Whatever technique is being used, the Verifier must maintain some > states during a time window. Two techniques can be used. Each one has > advantages and inconveniences. * > > > *If correctly implemented, both techniques provide the same replay attack > detection guarantees. The choice of the appropriate technique will be > context dependant. * > > > > > > > > > > > > > > > > > > *This means that the document should describe these two techniques. A > Verifier MUST support these two techniques. However, a Holder MAY only > support one of these two techniques. Note: The kind of data that will need > to be kept by the Verifier during the time window will be dependent upon > the technique being used. For each technique, the time window can be > different. These two techniques have been described in detail in the > following issued that was initially raised by Christian. > https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/104 > <https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/104> > In a client - server paradigm, there exist two mechanisms that are able to > *detect* replay attacks either: - using "unique numbers" generated and > sent by a client to a server, or - using "challenges" generated and > sent by a server to a client. Unique numbers which are generated by a > Holder shall be non-repeating for ever. In practice, such requirement can > be supported by using two parameters: * > > * - the time at which the **Key Binding JWT* > > > > > > > > > > > > * ("iat" claim) has been generated and - a random number ("rnd" claim) > that needs to be unique only during a short time-window. This means that > for using unique numbers, the Holder is required to support a clock > synchronised with UTC. Challenges generated by a Verifier need to be unique > only during a short time-window. This means that for using challenges, the > Holder is not required to support a UTC synchronised with UTC. This leads > to consider the following three claims: "iat", "rdn" (for random number) > and "chal" (for challenge). The text quoted at the beginning of this > comment should be changed into: * > > > > > > > > > > > > > > * The Key Binding JWT MUST be a JWT according to [RFC7519] and its > payload MUST contain the following elements: * (...) * in the JWT > payload, - iat: CONDITIONAL. The value of this claim MUST be the > time at which the Key Binding JWT was issued using the syntax > defined in [RFC7519]. - rdn: CONDITIONAL. Ensures the > freshness of the signature and allows to detect replays. The > value type of this claim MUST be a string generated by the Holder. > * > > > > * - chal: CONDITIONAL. Ensures the freshness of the signature and > allows to detect replays. The value type of this claim MUST be > a string generated by the Verifier. * > > > *EITHER, both the "iat" and the "rdn" claims MUST be present OR the "chal" > claim MUST be present. Then after, the text from **section **7.3. > Verification by the Verifier on p**age 35 * > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *would need to be fixed. Below is an extract from the current text: To > this end, Verifiers MUST follow the following steps (or equivalent): > 1. (...) 5. If Key Binding is required: 1. (...) > (...) 5. Check that the creation time of the Key Binding JWT, as > determined by the iat claim, is within an acceptable window. > 6. Determine that the Key Binding JWT is bound to the current > transaction and was created for this Verifier (replay > protection) by validating nonce and aud claims. Text change proposal: To > this end, Verifiers MUST follow the following steps (or equivalent): > 1. (...) 5. If Key Binding is required: 1. (...) > (...) 5. Determine that the Key Binding JWT is bound to the current > transaction and was created for this Verifier by validating > the aud claims. 6. Check that the Key Binding JWT is not > a replay of previously accepted JWT by checking first whether a* > * "rdn" claim or a "chal" claim is present. If none is > present, then * > > > *the Key Binding JWT shall be rejected. 7. If a * > *"rdn" claim is present, then the "iat" claim shall also be > present, otherwise the* > > * Key Binding JWT shall be rejected. The Verifier shall choose > a time-window to verify pairs of **"rdn" and "iat" claims and > maintain a list of* > > > > *validated pairs of "iat" and "rdn" claims. a) If > a received "iat" claim is outside of this time-window, > then the** Key Binding JWT shall be rejected* > > > > > > * and the Verifier should respond with an error. > b) If a received "iat" claim is inside this time window > and the values both of "iat" claim and of the associated > "rdn" claim are already present in the list of validated > pairs of "iat" and a "rdn" claims, then the* > * Key Binding JWT shall be rejected* > > > > > > > > * and the Verifier should respond with an error. > c) If a received "iat" claim is inside this time-window > and the values both of "iat" claim and of the > associated "rdn" claim are not already present in the > list of validated pairs of "iat" and a "rdn" claims, > and the associated "rdn" claim can successfully be used > to validate a **Key Binding JWT* > > > > > > > > > *, then the Verifier shall add the values both of "iat" > claim and the associated "rdn" claim into a list of > validated pairs of "iat" claim and "rdn" claim. > When the value of a "iat" claim from an entry falls > outside of the time-window, the Verifier can remove the > entry from the list. ** 8. If a **"chal" claim > is present, then the Verifier* > > > > > > * shall check whether the received challenge has previously > been generated and sent to a Holder. The Verifier shall > maintain a list of sent challenges to Holders during a > time-window chosen by itself. * > * a) If a received "chal" claim is not present in the list, > then the** Key Binding JWT shall be rejected* > > > * and the Verifier should respond with an error. > b) If a received "chal" claim is present in the list and* > * can be successfully used to validate a **Key Binding > JWT* > > > *, then the Verifier shall remove this value from the > list of challenges. Otherwise, the value must remain at * > > > > * least until the end of the time-window. > Note: In order to manage the removal of old challenges by > the Verifier, it is recommended that the Verifier locally > associates a time of issuance with each challenge.* > > *It is now necessary to fix the text from section * > > > > > > > > > > > > > > > > > > > > > > > > > > > *7.2. Processing by the Holder. Below is an extract from the current text: > (...) 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. 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. 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 selected Disclosures (see Section 4 for the format). > 4. If Key Binding is not required: 1. Send the SD-JWT to the > Verifier. 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 Key Binding JWT. 3. > Send the SD-JWT+KB to the Verifier. * > > > * It can be seen that in step 5, there is no guidance on how replay > detection should be handled by the Holder. * > > > > > *Text change proposal for step 5: 5. If Key Binding is required: > 1. Decide whether replay detection by the Verifier will be > checked using * > *"unique numbers" generated by the client or "challenges" > generated by the **Verifier* > *. Using "challenges" generated by the * > > > *Verifier will only be possible if a challenge has been > previously received from the Verifier. 2. If the Holder chooses to > use * > > > *"unique numbers", it shall be able to use a UTC clock and to > generate a random number, and shall place two values > respectively into the "iat" claim and the "rnd" claim.* > > * 3. If the Holder chooses to use * > > *"challenges", it shall place the received challenge into the > "chal" claim. * > > > > > * 4. Assemble the SD-JWT+KB by concatenating the SD-JWT and the > Key Binding JWT. 5. Send the SD-JWT+KB to the Verifier. * > > *SD-JWT SUSPENSION OR REVOCATION IS MISSING* > > * 7. Checking SD-JWT suspension or revocation is missing in section 7.1 > (**Verification > of the SD-JWT)* > > > * Steps 6 is currently described as follows: * > > * 6. Check that the SD-JWT is valid using claims such as nbf, iat, and > exp in the processed payload. If a required validity-controlling > claim is missing (see Section 9.7), the SD-JWT MUST be rejected.* > > > > > > > * None of the checks that are described is about the checking the status > of the SD-JWT, e.g., whether it has been suspended or revoked. Add the > following step: ** 7. Check that the status of the SD-JWT is valid,* > > > * e.g., whether it has been suspended or revoked. The way this can > be accomplished is out of the scope of this document. * > > *UNLINKABILITY* > > > > * 8. On page 48, the text states: * > > > > * Verifier/Verifier unlinkability and presentation unlinkability can be > achieved using batch issuance: A batch of credentials based on the > same claims is issued to the Holder instead of just a single > credential. The Holder can then use a different credential for each > Verifier or even for each session with a Verifier. * > > > > > > > > * This description is missing to indicate the major characteristic of a > SD-JWT when batch issuance is being used: each SD-JWT shall only be used > once. The batch includes a set of one-time-use SD-JWTs, each one with a > different content, including a public binding key when key binding is being > used. The term "**one** time-use digital **credential" should be added > into the text.* > > > > * Change proposal: * > * Verifier/Verifier unlinkability and presentation unlinkability can be > achieved using batch issuance: a batch of one* > *-time-use digital * > *credentials based on the same claims can be issued to the Holder > instead of just a single **digital * > *credential. The Holder can then use a different **digital * > *credential for each Verifier or even for each session with a > Verifier. * > > *One time-use SD-JWTs shall have a different content, including a > different public binding key when key binding is supported.* > > > > > > * POST-QUANTUM RESISTANCE KEY BINDING ALGORITHMS 9. It is proposed to add > a section about Post-Quantum resistance to section 9 (Security > Considerations). This text proposal comes from the observation that OTS > **(One-Time > Signatures) * > *algorithms are well suited to be used with **one**-time-use digital * > *credentials. * > > > > > * Text proposal: 9.15 Post-Quantum resistant key binding algorithms * > > > > > > > > * Implementations of SD-JWT rely on asymmetric cryptographic keys. > This document does not mandate the use of particular key binding > algorithm. It can be observed that Elliptic Curve Digital Signature > Algorithm (ECDSA) which offers a variant of the Digital Signature > Algorithm (DSA) which uses elliptic-curve cryptography, by construction, > cannot be resistant to Post-Quantum computers. Alternative algorithms > or techniques (e.g., ZKP) that would be **Post-Quantum resistant * > > > *are being explored. When using batches of **single time-use > **credentials > (see section * > *10.1), it is possible to use * > > > > > > > > > > > > > > > > > > > > *asymmetric key algorithms that are considered to be post-quantum > resistant. If the private "Binding Key“ is only used once, then the key > binding algorithm can Post-Quantum resistant. This will be the case when > using OTS (One-Time Signatures) and inserting the public key of a > Winternitz - One-Time Plus (WOTS+) algorithm into a one-time-use digital > credential. In case of a lack of Internet access, batches of "one-time > use digital credentials” should be requested in advance. > Interoperability is possible by choosing one (or more) out of seven > WOTS+ algorithm identifiers that have been registered by IANA. See: > https://www.iana.org/assignments/xmss-extended-hash-based > <https://www.iana.org/assignments/xmss-extended-hash-based>- > signatures/xmss-extended-hash-based-signatures.xhtml These algorithms > are described in [RFC8391], section 5.2 and in [SP 800-208] section 5. * > *VOCABULARY* > > > > * 10. On page 6, the text states: * > > > > > > > * Holder: 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. The document only defines a subset of > protocols between three entities. Figure 1 does not describe the > interactions between the Holder software and hardware and a human user.* > > > > * Text change proposal: * > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Holder: An entity that received SD-JWTs from the Issuer and > optionally holds the associated private keys and has control over > them. In the context of this document, the term refers to the > supporting software and hardware. ARRAY ELEMENTS 11. On page 14. Section > 4.2.2, the text states: For example, a Disclosure for the second element > of the nationalities array in the following JWT Claims Set: { > "nationalities": ["DE", "FR"] } could be created by first creating > the following array: ["lklxF5jMYlGTPUovMNIvCA", "FR"] The resulting > Disclosure would be: WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0 This > example is interesting, but is not fully privacy preserving. It allows to > know that a user has two nationalities. In order to be hide this > characteristic, a fixed number of values should be used instead by the > Issuer and when a user has less than this maximum number of nationalities, > some values would need to be duplicated. For example, if a maximum number > of nationalities is 3 and the user has only one nationality, the following > array should be used: { "nationalities": ["FR", "FR", "FR"] } > This issue should be mentioned here while the solution might be detailed > later on, e.g., in section 4.2.5. Decoy Digests. 12. On page 17. Section > 4.2.5. Decoy Digests, the text states: Decoy digests MAY be added both > to the _sd array for objects as well as in arrays. (...) To ensure > readability and replicability, the examples in this specification do not > contain decoy digests unless explicitly stated. Decoy digests work > differently whether they apply to the _sd array for objects or to an array. > This difference is not explained but should be explained. Duplicated values > in an array is a means to hide the number of really significant values in > an array. See the example above about: { "nationalities": ["FR", > "FR", "FR"] } This consideration should be added into section 4.2.6. > Recursive Disclosures. KEY PAIR GENERATION AND LIFECYCLE MANAGEMENT * > * 13. On page 46, Section * > > > > > > > > > > *9.12. Key Pair Generation and Lifecycle Management states: > 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]. * > > > * Following this Recommendation is certainly useful, but might lead to a > false sense of security. On Page 15 from [NIST.SP.800-57pt1r5], the Owner > (of a key or key pair) is defined as: * > > * "For a static key pair, the entity that is associated with the > public key and authorized to use the private key".* > > > > > > > > > > > * The entity that is associated with the public key and authorized to use > the private key may use the private key either in an "honest" way or in a > "dishonest" way. As long as the private key is used in an "honest way", > there is no problem, but in the context of this draft it is possible to > disclose a single claim without being identified. The use of private > binding keys should be restricted to "honest" appropriate applications. It > is proposed to add the following text at the end of section 9.12: While > best practices for an * > > *appropriate key management are essential, in the context of this > document, while necessary, they are insufficient. In particular, a * > *private binding key should only be usable by an "honest" appropriate > application. * > > > > * EDITORIAL COMMENTS * > > > * 14. EDITORIAL change: On page 6, the text states: * > > > > * Selectively Disclosable JWT (SD-JWT): A composite structure, > consisting of an Issuer-signed JWT (JWS, [RFC7515]) and zero or more > Disclosures, which supports selective disclosure as defined in this > document. * > * An * > > *SD-JWT is issued to a user. It would be useful to state that the claims > in the SD-JWT relate to a user that, later on, will be able to consent to > selectively disclose some claims. Hence the words "issued to a user" have > been added.* > > > > * Text change proposal: * > > > > > * Selectively Disclosable JWT (SD-JWT): A composite structure, > consisting of an Issuer-signed JWT (JWS, [RFC7515]) issued to a user > and zero or more Disclosures, which supports selective disclosure as > defined in this document. * > * 15. EDITORIAL change: On page 19, in **Section 4.3. Key Binding JWT* > * the text states: * > > > > > > > * This section defines the Key Binding JWT, which encodes a signature > over an SD-JWT by the Holder's private key. A Holder can have more that > one private key, hence the article "a" should be used instead of the > article "the". * > *Text change proposal: * > > > > > * This section defines the Key Binding JWT, which encodes a signature > over an SD-JWT by a Holder's private key. **16.** EDITORIAL change. On > page 47, section * > > > > > > *10.1. Unlinkability states: Unlinkability is a property whereby > adversaries are prevented from correlating credential presentations of > the same user beyond the user's consent. Without unlinkability, an > adversary might be able to learn more about the user than the user > intended to disclose, for example:* > > > > > > > * The use of the term "adversaries" looks odd as the entities are > collaborating or colluding but and are not adversaries. Change proposal: * > > > > * Unlinkability is a property whereby colluding Verifiers and/or > Issuers are prevented from correlating credential presentations of the > same user beyond the user's consent. Without unlinkability, colluding > parties might be able to learn more about the user than the user > intended to disclose, for example:* > > > *17.** EDITORIAL change.** On page 50, section 10.3.* > > *Confidentiality during Transport * > > > > > > > > > > > > > > > > > > > > > > > > > *Both confidentiality and integrity during Transport are essential. In > section 10.3, the text states: Usually, transport protocols for issuance > and presentation of credentials are designed to protect the confidentiality > of the transmitted data, for example, by requiring the use of TLS. This > specification therefore considers the confidentiality of the data to be > provided by the transport protocol and does not specify any encryption > mechanism. Confidentiality alone would be insufficient. It is necessary to > consider both confidentiality and integrity. Everybody is using TLS today > which supports both confidentiality and integrity. Change into: 10.3. > Confidentiality and integrity during Transport Usually, transport protocols > for issuance and presentation of credentials are designed to protect the > confidentiality and the integrity of the transmitted data, for example, by > requiring the use of TLS. This specification therefore considers the > confidentiality and the integrity of the data to be provided by the > transport protocol and does not specify any specific cryptographic > mechanism. This text is sufficient and the remaining of this section which > is copied below can be removed: * > > > > > > > * Implementers MUST ensure that the transport protocol provides > confidentiality if the privacy of user data or correlation attacks by > passive observers are a concern. To encrypt the SD-JWT when transmitted > over an insecure channel, implementers MAY use JSON Web Encryption (JWE) > [RFC7516 > <https://drafts.oauth.net/oauth-selective-disclosure-jwt/draft-ietf-oauth-selective-disclosure-jwt.html#RFC7516>] > by nesting the SD-JWT as the plaintext payload of a JWE. Especially, when > an SD-JWT is transmitted via a URL and information may be stored/cached in > the browser or end up in web server logs, the SD-JWT SHOULD be encrypted > using JWE. * > > *Denis* > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
