[OAUTH-WG] Re: Second WGLC for SD-JWT

[Denis <[e-mail]>]

*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]