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

[Daniel Fett <[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
>>     <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] 
>>>
>>
>>     _______________________________________________
>>     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 [e-mail]