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

[Daniel Fett <[e-mail]>]

Am 13.11.24 um 17:56 schrieb Tom Jones:
> The core problem here is that SD-JWT has been oversold and included in 
> OID4VP for the EUDIW

SD-JWT is not "included" in OpenID4VP. It is a format-agnostic 
specification.

In the EUDI ARF, OpenID4VP and SD-JWT were selected as suitable 
specifications.


> where it has no discernible value addressing issues of interest to a 
> gov't issued cred, which, by definition, is not self-sovereign. The 
> primary issue then is where the SD-JWT is used, which Fett makes 
> clear, is not fixable.
>
> I presented a solution to the DID CCG nearly 5 years ago (2018-12-12) 
> and was told by Chris Allen that they agreed not to address age 
> verification "because it was too hard." Since the wallet must be 
> trusted for the EUDIW, SD-JWT is of no value in that use case.

I'm not sure I can follow your thoughts here.


> Perhaps the security section could warn people that unlinkability is 
> not possible in principle

That's what the spec does. "Issuer/Verifier unlinkability with a 
colluding or compromised Verifier cannot be achieved in salted-hash 
based selective disclosure approaches, such as SD-JWT"


> and remove SD from the OID4VP?

See above.

-Daniel


>
> Peace ..tom jones
>
>
> On Wed, Nov 13, 2024 at 8:33 AM Daniel Fett 
> <mail=[e-mail]> wrote:
>
>
>     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]
>     _______________________________________________
>     OAuth mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> OAuth mailing list [e-mail]
> To unsubscribe send an email [e-mail]