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

[Paul Bastian <[e-mail]>]

I couldn't agree more with Daniel here. SD-JWT is a common, general purpose data format. I would go so far to move most of the privacy requirement into SD-JWT VC and remove it from this draft. Neither JWTs nor X509 certificate nor most other IETF drafts talk about unlinkability not about the details and differences between issuer-rp and rp-rp unlinkability.

In my view, the draft is fine. I'd rather shift the wallet related considerations to the appropriate specification.

Best, Paul

13 Nov 2024 17:41:17 Daniel Fett <mail=[e-mail]>:

> 
> Am 11.11.24 um 15:58 schrieb Denis:
>> This message is copied to Deb Cooley, our SEC Area Director.
> 
> I see Hannes in the CC, but not Deb. Did you use BCC?
> 
> 
>> 
>> By developing this draft in OAuth Working group, the major problem is that the document focuses on a single protocol,
>> without having described the overall framework in which it will be used. This draft is not targeted to be exclusively used
>> in the context of the OAuth Framework. It is well-known that one of the targets is the EUDI wallet.
> 
> This document, which does not mainly describe a protocol, but data formats, is generic in nature and not limited to the EUDI wallet. In fact, it is not even limited to wallet-based identity systems, as has been discussed a number of times in this group.
> 
> Many of your suggestions below and in your proposed changes seem to be based on a misunderstanding about the scope of the work. Without protocols for issuing and presenting credentials (like OpenID4VC), SD-JWT cannot be used to built a wallet ecosystem.
> 
> 
>> 
>> The basic protocol does not support the Verifier-Verifier unlinkability property.The fact that the EUDI wallet, as described
>> in the ARF 1.4.1. does not support this property (despite the fact that the EU Regulation mandates this principle in Article 5a (16) (b)
>> from REGULATION (EU) 2024/1183 of 11 April 2024) should not be taken as an argument for not describing a variant of the protocol
>> using one-time use digital credentials.
> 
> As above - SD-JWT is a data format. It can be used for one-time use credentials, but the magic happens in a protocol.
> 
> 
>>  
>> A threat analysis has not been carried out for draft-ietf-oauth-selective-disclosure-jwt-13 (nor for the ARF 1.4.1).
> 
> Any threats identified and considered relevant have been addressed in the Security and Privacy Considerations sections.
> 
> 
>> 
>> The threat that apply to the "End-user, Holder, Issuer and Verifier" 4 roles model (note that I didn't used the wording
>> "Holder, Issuer and Verifier" 3 roles model) are specific and, when selective disclosure is used, the major threat is the
>> End-user collaborative attack against a Verifier. This threat is not mentioned in the Security Considerations section.
> 
> You keep bringing up End-user collaborative attacks since at least 2017 and we have discussed them in the context of the OAuth Security BCP WGLC and the DPoP WGLC. All I have to say on that topic has been said and I will not engage in any further discussion on it, as it doesn't seem to be a good use of my time.
> 
> 
>> 
>> I am proposing a way forward to defeat the collaborative End-Users attack by defining a new claim that I called "hcar"'
>> for "_h_older _char_acteristics". It should be defined as an array of characteristics. Using this claim, the Verifier will be able
>> to know a set of characteristics of the Holder.
> 
> Potentially originating in the misunderstanding mentioned above, this is not for SD-JWT to solve. Please take a look at what OpenID4VC can do with regards to guaranteeing properties of certain parties to other parties (wallet/key attestations etc.).
> 
>> 
>> In another area, I would like to mention an improvement that could be addressed using the "hcar"' claim  that would allow
>> to support both suspension and revocation checking, without using CRL-like mechanisms or OCSP-like mechanisms. (...)
> 
> This and all the parts I snipped out for brevity here depend on a number of considerations that have to be made for specific deployments, each having their own set of requirements and limitations. A mechanism like this could, if deemed useful, be added by the concrete deployment. It exceeds the scope of this basic data format to define such a mechanism.
> 
> -Daniel
> 
> 
>> 
>> Denis
>> 
>>> Hello Denis,
>>> 
>>> Thank you for your continued interest in this work,
>>> 
>>> One of the draft's co-editors has already reviewed the comments and worked to identify appropriate and actionable items, incorporating these into a pull request in the repository’s source document. This work is ongoing, but we are hopeful to be in a position to publish the new draft -14 revision soon.
>>> 
>>> Then, as I proposed during the session last Thursday, I suggest the WG proceed with submitting the draft to the IESG for publication while noting in the Shepherd Write-Up that Denis Pinkas has around forty unresolved comments. I believe it's completely reasonable at this point to declare the majority of that feedback as being "in the rough" with respect to WG consensus on the document content and desire to move it forward.
>>> 
>>> Thanks,
>>> Brian
>>> 
>>> 
>>> On Wed, Nov 6, 2024 at 10:38 AM Denis <[e-mail]> wrote:
>>>> 
>>>> 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:*
>>>>> …
>>>>> *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:
>>>>> *…
>>>>> *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:
>>>>> *…
>>>>> …
>>>>> *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:
>>>>> *…
>>>>> *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:
>>>>> *…
>>>>> *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 to demonstrate 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 on 20 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:
>>>>> *…
>>>>> *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-JWTs and 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-JWTs and 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/.
>>>>> 
>>>>> 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:
>>>>> *…
>>>>> *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:
>>>>> *…
>>>>> *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*
>>>>> 
>>>>>> …
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>> 
>>> /*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.*/
>> 
>> 
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]