[OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues have been created on github

[Denis <[e-mail]>]

As I got no response to my comments sent to the OAuth mailing during the 
first WG LC, as well as during the second WG LC,
I have posted today 41 issues on github. They are numbered from #482 
until #522.

See: 
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues?page=1&q=is%3Aissue+is%3Aopen

To respond, please use the numbering #482 until #522 of the issues that 
have been posted on github.
One major advantage is that every issue has now a header. Some text 
proposals have been slightly reworded.

Denis

> *Daniel, Kristina and Brian,*
> *
> You will find below 42 comments. Most of them have been sent during 
> the first Last Call,
> but none has been addressed. **Each text change proposal is numbered 
> from 1 to 42.*
> *
> The main comments were sent on T**uesday, 17 September 2024 under the 
> subject: "**Re: WGLC for SD-JWT".
> See: 
> https://mailarchive.ietf.org/arch/msg/oauth/sVks-Tf_XM6SLcdccIAX29n_Ui4/
>
> *
> *The introduction has been changed. My comments on the introduction 
> have been revised and adapted to it.
> **
> 1.**The second sentence of the second paragraph mentions:*
>
>     *In this model, a JWT containing many claims is issued to an
>     intermediate party, who holds the JWT (the Holder).*
>     **
>
> ***COMMENT: In the introduction, it is important, to make the 
> difference between the Holder, which is an *application*,
> and the individual (i.e. End-User) who is assumed to have the control 
> of that application. The use of the word "entity"
> is to broad and does not capture this difference. An individual may 
> consent to an operation that the Holder can perform.
> A Holder does not "consent".
>
> This difference is well noticed later on in clause 7.2:
> *
>
>     *7.2.Processing by the Holder*
>     *(...)*
>     *For presentation to a Verifier, the Holder MUST perform the *
>     *following (or equivalent) steps:*
>     **
>     *1.Decide which Disclosures to release to the Verifier,*
>     **obtaining proper End-User consent* if necessary.*
>     **
>
> *In the introduction, it is also important to mention that "claims" 
> refers both to object properties
> name/value pairs) and to array elements. The current text does not 
> mention it.
>
> Replace by:
>
> In this model, a JWT can contain both regular claims and selectively 
> disclosable claims that are issued
> an End-User who is assumed to have the control of a Holder.
>
> When requesting a digital credential to an Issuer, the End-User using 
> his Holder CAN ask the Issuer
> to include a set of claims while obfuscating other claims. "Claims" 
> here refers both to object properties
> (name/value pairs) and to array elements.The Issuer then produces two 
> elements:
>
> - a SD-JWT that contains both regular claims and digests of
> selectively-disclosable claims,
>
> - a set of regular claims for the selectively-disclosable claims.
>
> The resulting structure is called: SD-JWT + All.Claims
>
> **2.**The third sentence of the second paragraph mentions:
>
> The Holder can then present the JWT to different verifying parties
> (Verifiers), that each may only require a subset of the claims in the
> JWT.
>
> Replace by:
> *
>
>     *When talking to a Verifier, the Holder CAN choose to selectively
>     disclose some obfuscated claims
>     by sending a subset of the disclosed claims.*
>
>     *The resulting structure is called: SD-JWT + Sel.Claims*
>
> *3.**The fifth paragraph mentions:*
> *
> *
> *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.It usually does so by signing over a data
> structure containing transaction-specific data, herein defined as the
> Key Binding JWT.An SD-JWT with a Key Binding JWT is called SD-
> JWT+KB in this specification.
>
> COMMENT: Key Binding is not performed to prevent attacks without the 
> "Holder's consent".
> In fact, key binding will be ineffective if the End-User consents to 
> perform a collaborative attack
> against a Verifier for the profit of another individual ... unless the 
> Holder supports
> specific characteristics that will be able to prevent such 
> collaborative attacks. Once again,
> a Holder is an *application*, i.e., it is not a human being.
>
> Key Binding only demonstrates the knowledge a private key 
> corresponding to a public key contained in a SD-JWT.
> It does not demonstrate the *possession* of a key.
>
> A key binding is performed:
> *
>
>     *(a) when requesting a SD-JWT to an Issuer, while *
>     *(b) the demonstration of that key binding is performed to a
>     Verifier at the presentation time.*
>
> *Replace by:
>
> When requesting a digital credential to an Issuer, the Holder CAN
> demonstrate to the Issuer that the request originates from an
> application that supports specific characteristics. In that case,
> the Holder CAN include in his request a public key and demonstrate
> to the Issuer the knowledge of the corresponding private key.
>
> When presenting a SD-JWT to a Verifier, the Holder CAN
> then add a key-binding JWT, called KB-JWT, that allows to integrity
> protect the "SD-JWT + Sel.Claims" structure. In this way, the
> Verifier will be able to verify that the "SD-JWT + Sel.Claims"
> structure and the KB-JWT " originate from a Holder that supports
> specific characteristics.
>
> The strength of the key binding is dependent upon the characteristics
> of the Holder.Such characteristics include the generation of
> key pairs, their protection as well as additional characteristics in
> particular to demonstrate its ability to counter collaborative or
> collusions attacks between End-Users.
>
> COMMENT: It is important to state upfront that key binding is not 
> simply a cryptographic operation.
> That cryptographic operation will be ineffective if the Holder permits 
> the legitimate End-User
> to use private keys contained in the Holder for the benefit of another 
> individual.
>
> Unless the Verifier is able to know the characteristics of the Holder 
> by using *information present in the SD-JWT*,
> the key binding mechanism can be easily defeated. The information that 
> shall be placed in the SD-JWT is currently
> missing and should be added. See a later comment about a new claim 
> called "hcahr" claim (i.e. holder characteristics).
>
> **
> **4.**Last sentence from the fifth paragraph on page 5:
> *
>
>     *An SD-JWT with a Key Binding JWT is called SD-JWT+KB in this
>     specification.*
>     **
>
> *Since the end result is the concatenation of two JWTs, it would be 
> more appropriate to call the structure SD-JWT+KB-JWT. *
> *This change should be done everywhere in the document.
>
> Change into:
>
> An SD-JWT with a Key Binding JWT is called SD-JWT + KB-JWT in this 
> specification.*
> *
> However the description of the "**SD-JWT+KB composite structure" is so 
> unclear (so the next comments),
> that this change might be inappropriate. In any case, please clarify.*
> **
>
> *5.**Item 1 from Section 1.1. (Feature Summary) states:
>
> 1.1.Feature Summary
>
> This specification defines two primary data formats:
>
> 1.SD-JWT is a composite structure enabling selective disclosure of
> its contents.It comprises the following:
>
> *(...)
> *(...)
> *A format extending the JWS Compact Serialization, allowing for
> the combined transport of the Issuer-signed JSON data
> structure and the disclosable data items
> *An alternate format extending the JWS JSON Serialization, also
> allowing for transport of the Issuer-signed JSON data
> structure and disclosure data
>
> At the time of reading these two sentences, they are not understandable.
> These sentences should be rephrased so that that the motivations 
> behind them can become understandable
> Please clarify.*
> *
> 6**.**Item 2 from Section 1.1. (Feature Summary) states:
>
> 2.SD-JWT+KB is a composite structure enabling cryptographic key
> 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 format extending the SD-JWT format for the combined transport of 
> the SD-JWT and the KB-JWT*
> *The whole description is not understandable.*
> *
> *
> *What is this "facility" ? See the comment 8 for a text change proposal.*
> *
> *
> ***7.**Item 2 from Section 1.1. (Feature Summary) states
>
> 2.SD-JWT+KB is a composite structure enabling cryptographic key
> binding when presented to the Verifier.It comprises the
> following:
>
> *(...)
> *A format for a Key Binding JWT (KB-JWT) that proves possession
> of the private key of the associated key pair
>
> There is no "proof of possession". What is a "***format for* a Key 
> Binding JWT (KB-JWT)" ?*
> *
> This description is not understandable. **See the next comment for a 
> text change proposal.**
>
> **8.**Item 2 from Section 1.1. (Feature Summary) states
>
> 2.SD-JWT+KB is a composite structure enabling cryptographic key
> binding when presented to the Verifier.It comprises the
> following:
>
> *(...)
> *(...)
> *A format extending the SD-JWT format for the combined
> transport of the SD-JWT and the KB-JWT
>
> **This description is not understandable. While reading it, it is not 
> possible to understand
> where the **selective disclosures **have been placed.*
>
> *Section 4 provides more details. The wording **"SD-JWT+KB" for the 
> composite structure does look not to be adequate
> as in some cases the structure does not include the KB-JWT. Since this 
> structure is presented to the Verifier,
> the wording "presentation structure" is proposed as it would be more 
> neutral.*
> *
> *
> *It is thus proposed to replace the content of **the item 2 from 
> Section 1.1. by:***
> *
> *
> *   2.  a composite presentation structure enabling cryptographic key
>        binding when presented to the Verifier.  It **is composed of the
>        concatenation of**the following:
>
> *
> *           *  an SD-JWT,
>            *  one or more selected Disclosures, and
>            *  a Key Binding JWT **that allows todemonstrate to a Verifier
>               that a cryptographic result computed over the two previous
>               components using a private key corresponding to a public 
> key
>               present in a SD-JWT is correct**.*
> *
>        See more details in section 4.
> *
> *
> *
> *Everywhere in the document change "SD-JWT+KB" into "presentation 
> structure".*
> *
> 1.2.Conventions and Terminology
>
> **9.**The current definition of Selectively Disclosable JWT (SD-JWT) is:
>
> 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.It can contain both regular claims and digests
> of selectively-disclosable claims.
>
> **The "all Disclosures" are not part of the SD-JWT. It they were, they 
> would be signed
> and removing one of them would break the signature of the Issuer.
>
> Change into:
>
> Selectively Disclosable JWT (SD-JWT):A composite structure,
> consisting of an Issuer-signed JWT (JWS, [RFC7515]) that contains
> both regular claims and one or more digests of selectively-
> disclosable claims.When a SD-JWT is sent back to a Holder, all
> the disclosures corresponding to the selectively-disclosable
> claims are also returned. When a SD-JWT is presented to a
> Verifier, all or only a subset of the disclosures previously
> obtained by the Holder are presented to the Verifier.
>
> **10.**The current definition of key Binding is:
>
> 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).
>
> COMMENT: Talking of a "legitimate possession" is an abuse of language. 
> Who possesses the private key is unknown.
> Even when the key is controlled by a Holder, the End-User can decide 
> to perform cryptographic computations
> with the private key for the benefit of one or more End-Users. If the 
> set of claims does not allow to uniquely
> identify the End-User, the End-User cannot be caught. In that case, 
> the End-User can even monetize his services
> for the benefit of **e.g., **hundred or thousand of users.
>
> Replace this definition by:
>
> Key Binding:Ability to demonstrate to a Verifier that a
> cryptographic result computed over a data structure using
> a private key corresponding to a public key contained in a SD-JWT
> is correct.
>
> **11.**The current definition of Key Binding JWT is:
>
> 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.
>
> COMMENT: Referring to a subsequent Section is not adequate for a 
> definition.
> The definition should be understandable without the need to look at 
> another section.
> The KB-JWT does much more than the current description.
>
> Replace this definition by:
>
> Key Binding JWT (KB-JWT):A JWT that allows a Holder to disclose a
> set of claims that were obfuscated in a SD-JWT, to restrict the
> use of a SD-JWT to one or more designated Verifiers, to prevent
> the replay of a SD-JWT by a designated Verifier to non-designated
> Verifiers, to limit the use of the SD-JWT to a single exchange and
> that allows the Verifier to make sure that these limitations are
> enforced by a Holder that has the knowledge of a private key
> corresponding to a public key contained in the SD-JWT.
> **
> *
> *12.**The current definition of Issuer is:
>
> *
> *Issuer:An entity that creates SD-JWTs.
>
> Replace this definition by:
>
> Issuer:An entity that creates SD-JWTs and Disclosures.
> **
> *
> *13.**The current definition of Holder is:
>
> 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.
>
> COMMENT: It is important to make the difference between the (Holder)
> application supported by some hardware and the End-User that has the
> control of that (Holder) application. At a lower level of granularity,
> a (Holder) application can be composed of several hardware and software
> elements such as: TEE, Trusted OS, Trusted Applications, Rich OS,
> Untrusted Applications. These characteristics are fundamental to
> successfully achieve or not "key binding".
>
> Replace this definition by:
>
> Holder:An application supported by hardware that obtains SD-JWTs
> and Disclosures from an Issuer and is able to selectively
> disclose to a Verifier claims contained those SD-JWTs.In the
> context of this document, a Holder is placed under the control
> of an End-User.
>
> **14.**The current definition of Verifier is:
>
> Verifier:An entity that requests, checks, and extracts the claims
> from an SD-JWT with its respective Disclosures.
>
> Replace this definition by:
>
> Verifier:An entity that requests, receives a SD-JWT that contains
> selectively disclosable claims and uses Selective Disclosures to
> obtain one or more obfuscated claims._
> __
> _**15.**Add a definition for the term End-Use
>
> End-User: an individual assumed to have the control of a Holder.
> **
> 16.**Correct Figure 1 as below:
>
> 3.Flow Diagram
>
> +------------+
> ||
> |Issuer|
> ||
> +------------+
> |
> Issues: SD-JWT + All Disclosures
> |
> v
> +------------+
> ||
> |Holder|End-User
> ||
> +------------+
> |
> Presents: SD-JWT + **Selected Disclosures + **KB-JWT**
> |
> v
> +-------------+
> ||+
> |Verifiers||+
> ||||
> +-------------+||
> +-------------+|
> +-------------+
>
> Figure 1: SD-JWT Issuance and Presentation Flow*
> *
>
> **17.**Section 3.1.SD-JWT and Disclosures
>
> The third sentence of the second paragraph states:
>
> The Disclosures are sent to the Holder as part of the SD-JWT in the
> format defined in Section 4.
>
> The first sentence states:
>
> 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.
>
> Hence, the Disclosures are NOT included in the Issuer-signed SD-JWT.
>
> Change the third sentence of the second paragraph into:
>
> The Disclosures are sent to the Holder in addition to the SD-JWT.
>
> COMMENT: The format used to carry both the SD-JWT and the Disclosures 
> is unclear.
> **
> 18.**Section 3.2.
>
> 3.2.Disclosing to a Verifier
>
> To disclose to a Verifier a subset of the SD-JWT claim values, a
> Holder sends only the Disclosures of those selectively released
> claims to the Verifier as part of the SD-JWT.
>
> Change the third sentence of the second paragraph into:
>
> To disclose to a Verifier a subset of the SD-JWT claim values,
> in addition to the SD-JWT, a Holder sends only the Disclosures
> of those selectively released claims to the Verifier.
> **
> 19.**Section 3.3
>
> When a Verifier requires Key Binding, the Holder presents an SD-
> JWT+KB, consisting of an SD-JWT as well as a Key Binding JWT tied to
> that SD-JWT.The Key Binding JWT encodes a signature by the Holder's
> private key over
>
> *a hash of the SD-JWT,
> *a nonce to ensure the freshness of the signature, and
> *an audience value to indicate the intended audience for the
> document.
>
> Change:
>
> *a nonce to ensure the freshness of the signature, and
> *an audience value to indicate the intended audience for the
> document.
> into:
>
> *a nonce previously received from the Verifier to ensure the
> freshness of the signature, and
>
> *an audience value to indicate the intended Verifier for the
> document.
> **
> 20.**Section 4
>
> 4.SD-JWT and SD-JWT+KB Data Formats*
>
> **
> *Change the title into:
>
> *
> *    4.SD-JWT and presentation structure data formats*
> *
> *
> *An SD-JWT is composed of
>
> *an Issuer-signed JWT, and
> *zero or more Disclosures.
>
> No. The Disclosures, which are unsigned, are located outside the SD-JWT.
> *
> *
> *
> *Change into:
>
> A data structure for a SD-JWT with Disclosures is composed of:
>
> *an Issuer-signed JWT, and
> *one or more Disclosures.
>
> **21.**Section 4:
>
> An SD-JWT+KB is composed of
>
> *an SD-JWT (i.e., an Issuer-signed JWT and zero or more
> Disclosures), and
> *a Key Binding JWT.
>
> Change into:
>
> A **presentation structure **for a SD-JWT with Selected Disclosures 
> and with key binding
> is composed of:
>
> *an SD-JWT
> *one or more Selected Disclosures, and
> *a Key Binding JWT.
>
> **22.**Section 4.1:
>
> It is the Issuer who decides which claims are selectively disclosable
> and which are not.
>
> Change into:
>
> It is the Issuer which decides which claims can be selectively
> disclosed by the Holder and which claims are always disclosed.
>
> **23.****Section 4.2.2.Disclosures for Array Elements
>
> This section contains an interesting example for the use case when an 
> End-User has several nationalities.
> It is proposed to add another interesting example for the use case 
> where an individual is willing
> to demonstrate that he is above or/and under an age threshold limit.
>
> Note: This topic has already been advertised to the OAuth mailing list 
> on20 September 2024
> under the title: " Re: WGLC for SD-JWT" and the sub-title:
> *About disclosures for Array Elements versus disclosures of name/value 
> pair*.
>
> See: 
> https://mailarchive.ietf.org/arch/msg/oauth/EYlDtN8gg1--tsZ-AWolMjw4jAk/
>
> Draft of Annex - Ares(2024)5786783 "laying down rules for the 
> application of Regulation (EU)
> No 910/2014 of the European Parliament and of the Council as regards 
> person identification data
> and electronic attestations of attributes issued to European Digital 
> Identity Wallets" identifies
> the following two optional attributes: "age_over_18" and "age_over_13" 
> on page 3 in Table 2: Optional attributes.
>
> The threshold values depends upon the use case and vary country by 
> country.
> Some examples are: over 13, over 15, over 18, over 21, over 60, over 
> 65 but also under 25 (for social networks).
>
> Rather than defining more optional attributes, like "age_over_15", 
> "age_over_21", "age_over_60",
> "age_over_65" or "age_under_25", each time there will be a new need, 
> it is more adequate to define
> two array elements that will allow to support any age threshold value.
>
> This leads to define two arrays:
> *
>
>     *- "age_over", and*
>     *- "age_under".*
>
> *The Issuer may wish to make the whole "age_over" and/or "age_under" 
> field selectively disclosable
> and allow the Holder to make the entries within the "age_over" and/or 
> "age_under" array selectively disclosable.
>
> Add the following text:
>
> The disclosure of age threshold values is another example.Rather than 
> defining attributes,
> like "age_over_15", "age_over_21", "age_over_60", "age_over_65" or 
> "age_under_25", two array elements
> allow to support any age threshold value.
>
> Two examples are mentioned below :
>
> {
> "age_over": ["21", "13", "18", "15"]
> }
>
> A Disclosure for the second element of the "age_over" array in the 
> following JWT Claims Set could be created.
>
> {
> "age_under": ["25", "18"]
> }
>
> A Disclosure for the first element of the "age_under" array in the 
> following JWT Claims Set could be created.
>
> I let the co-editors of the document to complete this example.
> **
> *
> *24.**Section 5.1.2
>
> 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.
>
> COMMENT: The strength of the key binding mechanism is dependent about 
> the key generation process.
> For example, if the key pair can be freely exported or shared, then 
> the strength of the key binding mechanism
> becomes close to zero. A first condition (which will not be the single 
> one), shall be to use
> a secure cryptographic application which is part of the Holder 
> application to generate the key pairs.
>
> In order to appreciate the strength key binding mechanism, the 
> Verifier shall be made aware
> of the characteristics of the Holder. In order to avoid the use of a 
> specific protocol between the Holder and the Verifier
> that could leak information that would be usable to link different 
> accesses, a transitive trust scheme is preferred.
>
> At the moment where he Holder requests a SD-JWT to the Issuer, a 
> specific protocol between the Holder and the Issuer
> is used that allows the Issuer to know some of the characteristics of 
> the Holder.
> These characteristics can then be included in a specific claim of the 
> SD-JWT (i.e., a "hchar" claim).
>
> Remove this paragraph and replace it with:
>
> The key pair SHALL be generated by a trusted part of the Holder where 
> the characteristics of that application
> SHALL be included by the Issuer in SD-JWT using a specific claim 
> (i.e., a "hchar" claim). See clause 4.3.2.
>
> **25.**Section 4.2.1
>
> 4.2.1.Disclosures for Object Properties
>
> Section 4.2.2 (Disclosures for Array Elements) contains a consideration
> that should also be applied to section 4.2.1 (Disclosures for Object 
> Properties).
>
> Add the following text below the header of this section:
>
> The Issuer SHOULD hide the order of the obfuscated claims in the SD-JWT.
> To ensure this, it is RECOMMENDED to add decoy digests and to shuffle
> the digests included in the SD-JWT payload. See section 4.2.5 about
> Decoy Digests.It is also RECOMMENDED to use a fixed number of
> digests, so that the Verifier cannot deduce the value of an obfuscated
> claim name that won't be revealed.
> **
> 26.**Section 4.3
>
> 4.3.Key Binding JWT
>
> (...)
>
> The Key Binding JWT MUST be a JWT according to [RFC7519] and its
> payload MUST contain the following elements:
>
> *in the JOSE header,
> (...)
>
> *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].
>
> -aud: REQUIRED.The intended receiver of the Key Binding JWT.
> How the value is represented is up to the protocol used and out
> of scope of this specification.
>
> -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.
>
> -sd_hash: REQUIRED.The base64url-encoded hash value over the
> Issuer-signed JWT and the selected Disclosures as defined
> below.
>
> The time at which the Key Binding JWT was issued should not be REQUIRED.
> The use of the nonce is sufficient to prevent replay.
>
> Remove:
> -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].
>
> **27.**Section 4.3.2 (Validating the Key Binding JWT)
>
> Some validation steps are missing. They should correspond in 
> particular to the REQUIRED claims from clause 4.3:
>
> -aud: REQUIRED
> -nonce: REQUIRED
> -sd_hash: REQUIRED
>
> The presence of an additional claim which is currently not yet defined 
> should be done.
> The claim allows to know characteristics of the Holder.
>
> It is proposed to name this claim "hchar" for "holder characteristics".
>
> Add the following text:
>
> The Verifier MUST verify that the Key Binding JWT is a JWT
> according to [RFC7519] and that its payload contains the following
> elements:
>
> -aud: REQUIRED.It MUST correspond to an identifier or a name
> of the intended Verifier.
>
> -nonce: REQUIRED.It MUST correspond to value of the nonce that
> was sent by the Verifier and received by the Holder when the
> Holder made an access request to the verifier. The value type
> of this claim MUST be a string.
>
> -sd_hash: REQUIRED.The base64url-encoded hash value over the
> Issuer-signed JWT and the selected Disclosures.
>
> If the Verifier is willing to know the strength of the key binding 
> mechanism, the Verifier MUST verify
> that the payload of the Key Binding JWT contains the following element 
> and that it understands its meaning:
>
> -hchar: REQUIRED.This claim allows the Verifier to know
> specific characteristics of the Holder (holder characteristics),
> in particular whether some of these characteristics are able to
> counter Holder collaborative attacks against a Verifier.
>
> **28.**Section 7.1 (Verification of the SD-JWT)
>
> The text states:
>
> Upon receiving an SD-JWT, either directly or as a component of an SD-
> JWT+KB, a Holder or a Verifier needs to ensure that:
>
> *the Issuer-signed JWT is valid, i.e., it is signed by the Issuer
> and the signature is valid, and
>
> Change into:
>
> Upon receiving an SD-JWT, a Holder or a Verifier needs to ensure that:
>
> *the Issuer belongs to a set of Trusted Issuers using
> a certification path up to a trusted root,
>
> *the Issuer-signed JWT is valid, i.e., it is signed by a Trusted
> Issuer and the signature is valid, and
> **
> 29.**Section 7.1 (Verification of the SD-JWT)
>
> Some steps are missing.
>
> Section 4.1 in step 6 mentions:
>
> 6.The payload MAY contain further claims such as iss, iat, etc. as
> defined or required by the application using SD-JWTs.
>
> Corresponding verification steps should be added in section 7.1.
>
> After the following item:
>
> 3.Validate the Issuer and that the signing key belongs to this
> Issuer.
>
> Add the following item:
>
> 4.If required by the application using SD-JWTs, check that
> further claims such as iss, iat, nbf, exp, etc. are present
> and contain appropriate values.
> **
> 30.**Section 7.1 (Verification of the SD-JWT)
> *
> *
> Some other steps are missing.
>
> Add:
> 5.If required by the application using SD-JWTsand if the
> SD-JWT contains claims such as nbf or exp, verify that the
> current time lies between these two values.
>
> 6.If required by the application using SD-JWTsand if the
> previous verification succeeds, verify that the SD-JWT is
> not currently suspended, nor revoked.
>
> Note : The means to verify that the SD-JWT is not currently suspended, 
> nor revoked, are not defined in this document.
> **
> *
> *31.**Section 7.2
> *
> *
> *
> *7.2.Processing by the Holder
>
> 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.
>
> These sentences would mean that the Issuer would be in possession of 
> the private key able to sign the KB-JWT.
> It is much better to construct an architecture where the Issuer CANNOT 
> be in possession of the private key
> able to sign the KB-JWT.
>
> Remove these two sentences.
> **
> 32.**Section 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 8.1, Verifiers need to ensure that (...)
>
> The vocabulary should be aligned with the acronyms from Figure 1:
> SD-JWT Issuance and Presentation Flow.
>
> Change into:
>
> Upon receiving a presentation structure from a Holder, in the form of
>    either an SD-JWT + sel.disclosures or an SD-JWT + sel.disclosures + 
> SD-JKT,
>    in addition to the checks outlined in Section 8.1, Verifiers need to
> ensure that (...)
> **
> 33.**Section 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.
>
> Without Key Binding, a Verifier only gets the proof that the
> credential was issued by a particular Issuer, but the credential
> itself can be replayed by anyone who gets access to it.This means
> that, for example, after a credential was leaked to an attacker, the
> attacker can present the credential to any verifier that does not
> require a binding.But also a malicious Verifier to which the Holder
> presented the credential can present the credential to another
> Verifier if that other Verifier does not require Key Binding.
>
> These two paragraphs are incorrect.
>
> Let us suppose that an End-User B connects to a Verifier in order to
> perform an operation. The Verifier then returns a selection of issuer
> names, claim names and a nonce. Let us now assume that an End-User A
> accepts to collaborate with the End-User B.The End-User B transmits the
> nonce to the End-User A. The End-User A then provides a "SD-JWT +
> **Selected Disclosures + **KB-JWT to the End-User B. In this way, the 
> End-User B
> can take benefits of claims that belong to the End-User A. The 
> Verifier is not
> in a position to know who is "the legitimate Holder of the credential"
> ... unless the set of disclosed claims allows to unambiguously 
> identify the End-User.
>
> The collusion attack has been described on the OAuth mailing list on 
> 07 November 2016.
> The ABC attack (the Alice and Bob Collusion attack).
> See: 
> https://mailarchive.ietf.org/arch/msg/oauth/UIsbsVtINPifrCjG7GDZM7FOi2g/ 
> <https://mailarchive.ietf.org/arch/msg/oauth/UIsbsVtINPifrCjG7GDZM7FOi2g/>.
>
> A few extracts:
>
> Whatever kind of cryptographic is being used, when two users
> collaborate, a software-only solution will be unable to prevent
> the transfer of an attribute of a user that possess it to another
> user that does not possess it .
>
> The use of a secure element or of a Trusted Application (TA) running 
> in a TEE only protecting
> the confidentiality and the integrity of some secret key or private 
> key will be ineffective
> to counter the Alice and Bob collusion attack. Additional properties 
> will be required
> for the secure element or the Trusted Application (TA) running in a TEE.
>
> Change into:
>
> An SD-JWT compatible with Key Binding contains a public key, or a
> reference to a public key, that corresponds to a private key known by
> some entity.
>
> The Verifier requires that a Holder proves the knowledge
> of that private key when presenting an SD-JWT + **Selected Disclosures
>    +**KB-JWT structure to a Verifier.
>
> Key Binding aims to ensure that the presenter of a **SD-JWT +
> **Selected Disclosures +**KB-JWT structure**structure to a Verifier
>    has either the knowledge of a private key corresponding to a public 
> key
> contained in a SD-JWT or has had the ability to obtain a cryptographic
> result performed using that private key.*
>
> *Without Key Binding, a Verifier only gets the proof that the*
> *credential was issued by a particular Issuer, but the credential*
> *itself can be replayed by anyone who gets access to it. A **malicious
> Verifier to which the Holder presented the credential can also
> present the credential to another Verifier* *if that other Verifier does
> not require Key Binding.
> *
> *With Key Binding, if two End-Users accept to collaborate, unless *
> *specific characteristics are supported by the Holder, an **SD-JWT +
> **Selected Disclosures +**KB-JWT structure**structure can voluntarily 
> be computed
> and then transmitted by the legitimate Holder of a private key with
> the consent of the End-User to another Holder. Using the "hchar" claim,
> the Verifier will be able to know whether some of these
> characteristics are able to counter Holder collaborative attacks
> against a Verifier.
>
> **34.**New section 9.12. Presentation of claims issued by different 
> Issuers
>
> The text below reuses text sent on 23 September 2024 to the OAUth 
> mailing list under the topic:
> *
>
>     ***[OAUTH-WG] How to get the benefits of BBS+, without its
>     drawbacks while using conventional cryptography ?
>     (Was SD-JWT and Unlinkability)*
>
> *See: 
> https://mailarchive.ietf.org/arch/msg/oauth/X4fZ-RMAfcC_5vAxl_qAnSBu8T0/
>
> Add the following text:
>
> 9.12. Presentation of claims issued by different Issuers
>
> There exist use cases where claims issued by different Issuers need
> to be presented to one Verifier.For example, an End-User would like
> to demonstrate to a Verifier that that he lives in California using
> a SD-JWT issued by a governmental organization and that he got a
> specific diploma using a SD-JWT issued by a University.
>
> When using the regular SD-JWT mechanism, the Holder generates one
> key pair for each Issuer. In this way, a SD-JWT issued by an Issuer A
> cannot be linked between collaborative Verifiers to a SD-JWT issued
> by an Issuer B.
>
> For that specific use case, the Holder can generate a one-time one
> key pair and use the same private key to request a SD-JWT from each
> Issuer.
>
> The two issued SD-JWTs will contain the same public key and, using
> the corresponding private key, the Holder will be able to demonstrate
> to one Verifier that the two presentations of the SD-JWT originate
> from the same Holder.
>
> This means that the key pairs MUST be generated by a trusted
> component from the Holder, e.g., running in a TEE.Both Issuers and
> Verifiers MUST be able to obtain the characteristics of the trusted
> component from Holder to be confident that Holder indeed supports
> this scheme.
>
> Since that key pair will only be used once towards a single Verifier,
> a linkage between different collaborative Verifiers using the framing
> of the SD-JWT will not be possible.
>
> **35.**Section 10.1. (Unlinkability)
>
> 10.1.Unlinkability
>
> The word "unlinkability" is used with four different meanings or 
> flavours.
> The last two properties are called:
> *
>
>     *Issuer/Verifier Unlinkability (Honest Verifier), and*
>     *Issuer/Verifier Unlinkability (Colluding/Compromised Verifier)*
>     **
>
> *When reading these two long wordings, it is rather difficult to 
> understand their meaning
> and their differences.
>
> The current text is using twice the word "track".
>
> *Cooperating Verifiers might want to *track* users across services to
> build advertising profiles.
>
> *Issuers might want to *track* where users present their credentials
> to enable surveillance.
>
> In order to make the text more understandable, it is proposed to use 
> the terms "unlinkability" and "intrackability".
>
> Roughly speaking:
> *
>
>   * *Verifiers may attempt to *link* accesses performed by the Holders.*
>   * *Issuers may either be required by a national authority or be
>     willing to *track* accesses performed by their Holders.*
>
> *This leads to consider one section dedicated to "unlinkability"
> and another section dedicated to "intrackability".
>
> Text change proposal:
>
> 10.1.Unlinkability
>
> Unlinkability is a property whereby one or more Verifiers are
> prevented from correlating SD-JWT presentations from the same Holder.
>
> Without unlinkability, a Verifier might be able to learn more about
> the End-User intended to disclose, for example:
>
> *A single Verifier might want to count the number of accesses made
> by one Holder.
>
> *Collaborative Verifiers might want to learn that the same End-User
> made an access to their services.
>
> In all cases, unlinkability is limited to cases where the disclosed
> claims do not contain information that directly or indirectly
> identifies the End-User.For 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 End-User
> only discloses a birth date 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.
>
> The following types of unlinkability are considered here:
>
> *Single Verifier Unlinkability: incapability of one Verifier to
> learn that it got two or more accesses using different sessions
> from the same End-User or the same Holder.
>
> *Verifier/Verifier Unlinkability: incapability of two or more
> collaborative Verifiers to learn that they got accesses from
> the same End-User or the same Holder.
> These collaborative Verifiers may wish to know whether they got an
> access from the same End-User, without necessarily being able to
> identify him.
>
> Independently from the set of disclosed claims, one or more fields
> from the SD-JWT or of the KB-JWT may reveal that they relate either
> to the same the End-User or to the same Holder, and hence to the
> same End-User.In that case, if a first Verifier is able to
> identify the End-User and collaborates with a second Verifier
> which was unable to identifier the End-User, then the second
> Verifier will be able to identify the End-User.
>
> Single Verifier Unlinkability and Verifier/Verifier unlinkability
> can be achieved using batch issuance: a batch of SD-JWTs based on the
> same set of claims is issued to the Holder instead of just a single
> SD-JWT.The Holder can then use a different SD-JWT for each
> Verifier or even for each different session with a Verifier.
> New key binding keys and salts MUST be used for each SD-JWT in
> the batch to ensure that the Verifiers cannot link the SD-JWTs
> using these values.Likewise, claims carrying time information, like
> iat, exp, and nbf, MUST either be randomized within a time period
> considered appropriate (e.g., randomize iat within the last 24 hours
> and calculate exp accordingly) or rounded (e.g., rounded down to the
> beginning of the day).
>
> **36.**New Section 10.2 (Intrackability)
>
> Text addition proposal resulting from the split of section 10.1:
>
> 10.2.Intrackability
>
> Intrackability is a property whereby one or more Issuers are normally 
> prevented
> to learn by which Verifier(s) a SD-JWT that they have issued has been 
> consumed.
>
> The following types of intrackability are considered here:
>
> *Holder intrackability by one Issuer: incapability of an Issuer
> alone to learn to which Verifiers a SD-JWT that it has issued
> will be presented by a Holder.
>
> *Holder intrackability by both Issuers and Verifiers:
> incapability of one Issuer, with the help of one Verifier, to
> learn by which Verifier a SD-JWT that it has issued has been
> consumed.
>
> Holder intrackability by one Issuer is natively supported when using
> SD-JWTs since a SD-JWT does not contain an "aud" claim.
>
> Holder intrackability by both Issuers and Verifiers cannot be supported
> using SD-JWTs, as soon as a Verifier communicates the SD-JWT either to
> an authority upon its request that will then communicate it to the
> Issuer or deliberately communicates the SD-JWT to the Issuer.
>
> However, some mechanisms using zero-knowledge proofs (ZKP) may be able
> to support this property.
>
> It is important to note, for example, that a national authority can
> require to get an access to the audit logs from both a Verifier and
> an Issuer to know whether a same SD-JWT has been logged in both files.
>
> Since the Issuer "needs to know its customer" (KYC), national
> authorities may be able to identify an End-User who made an access
> to a Verifier.
>
> Section 10.X (Storage of User Data) RECOMMENDS that after
> verification, Verifiers SHOULD NOT store the SD-JWT.Depending upon
> the context of use, this recommendation should or should not be
> followed since there exist cases where such property will be non-
> desirable in particular to fight against crime or money laundering.
>
> **37.**Section 10.2
>
> 10.2.Storage of Signed User Data
>
> This section does not only consider the storage of *signed* user data,
> but also of user data that is *unsigned*.
>
> Change into:
>
> 10.2.Storage of User Data
> **
> 38.**Section 10.2
>
> Holders SHOULD store SD-JWTs only in encrypted form, and, wherever
> possible, use hardware-backed encryption in particular for the
> private Key Binding key.
>
> When a smartphone is used, a TEE can be used and the SD-JWTs can be 
> stored in it in clear text
> since the TEE is protected from the RichOS.Encrypted forms are not needed.
>
> Change into:
>
> Holders SHOULD store SD-JWTs and key pairs used for key binding only
> in a protected area such a Trusted Execution Environment (TEE) .
> **
> 39.**Section 10.2
>
> 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
> End-User data that is needed for the application.
>
> In practice, a SD-JWT contains regular claims and selectively 
> disclosable claims while Disclosures
> are sent separately. After verification, a Verifier needs to store any 
> End-User data
> that is needed for the application.
>
> Change into:
>
> After Verification, Verifiers SHOULD NOT store the SD-JWT, nor the
> KB-JWT. However, it may be necessary to store End-User data as needed
> for the application including regular claims and Disclosures.
>
> **40.**Section 10.3. (Confidentiality during Transport)
>
> Both confidentiality and integrity are important. Add integrity.
>
> Change into:
>
> 11.3.Confidentiality and integrity during Transport
>
> In the following text, change "confidentiality" into "integrity and 
> confidentiality".
>
> **41.**New Section 10.X (Issuer anonymity)
>
> This section should be placed before section 10.5 (Issuer Identifier)
>
> Add a new section:
>
> 10.X.Issuer anonymity
>
> Issuer anonymity: incapability of a Verifier, to learn from which
> Issuer a SD-JWT that has been presented by a Holder has been issued.
>
> Issuer anonymity cannot be supported using SD-JWTs, since a SD-JWT
> is signed by its Issuer using an asymmetric algorithm. However, some
> mechanisms using group signature or ring signatures may be able to
> support this property.
> **
> 42.**Section 10.5 (Issuer Identifier)
>
> The last paragraph of this section states:
>
> To mitigate this issue, a group of issuers may elect to use a common
> Issuer identifier.A group signature scheme outside the scope of
> this specification may also be used, instead of an individual
> signature.
>
> Given the proposal to add a section dedicated to "Issuer anonymity"
> this paragraph can be removed.
>
> Remove this paragraph.
>
> END OF COMMENTS
> *
> *
> Denis*
>
>> All,
>>
>> This is a *short second WG Last Call* for the *SD-JWT* document after 
>> the recent update based on the feedback provided during the first WGLC
>> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-13.txt
>>
>> Please, review this document and reply on the mailing list if you 
>> have any comments or concerns, by Oct 25th.
>>
>> Regards,
>>   Rifaat & Hannes
>>
>> _______________________________________________ OAuth mailing list -- 
>> [e-mail] To unsubscribe send an email to [e-mail] 
>