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

[Denis <[e-mail]>]

*All,*

*Below are my comments:*

*1.Introduction*

**

*The introduction is too long and far from being crystal clear.

Text proposal:

This document specifies the encoding of digital credentials issued by a
digital credential issuer (Issuer) that allows an holder application
(Holder) placed under the control of an End-User to selectively disclose
to a Verifier claims contained in it.

In this document, digital credentials are encoded as JSON Web Signature
(JWS) [RFC7515] structures with JSON [RFC8259] objects as the payload.
JSON Web Token (JWT) [RFC7519] is a very prevalent application of JWS with
a JSON payload.

When requesting a digital credential to an Issuer, the Holder CAN ask the
Issuer to reveal a set of claims while obfuscating another set of claims.
"Claims" here refers to both object properties (name/value pairs) as well
as 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

When talking to a Verifier, the Holder CAN choose to selectively disclose
some hidden claims by sending a subset of the disclosed claims.

The resulting structure is called: SD-JWT + Sel.Claims

When requesting a digital credential to an Issuer, the Holder CAN
demonstrate to the Issuer that the request originates from a secure
cryptographic 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.

The Holder CAN then add a key-binding JWT, called KB-JWT, that allows to
add further claims and to integrity protect the "SD-JWT + Sel.Claims"
structure. In this way, the Verifier is able to make sure that the
"SD-"JWT + Sel.Claims + KB-JWT" structure originates from a Holder that
includes a secure cryptographic application with specific characteristics.
The strength of the binding is dependent upon the characteristics of the
secure cryptographic application. Such characteristics include the
generation of key pairs, their protection as well as additional 
characteristics
able to counter collaborative or collusions attacks between End-Users.

2.Terms and Definitions

(...)

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).

Key Binding:Ability of an Holder to demonstrate to a Verifier either
the knowledge of a private key corresponding to a public key
contained in a SD-JWT or the ability to obtain a cryptographic result
performed using that private key.

_Explanations_: It is a Proof of Knowledge (PoK), it is not a Proof of 
Possession (PoP).
Who possesses the private key is unknown. Even when the key is 
controlled by an End-user,
the End-user can decide to perform cryptographic computations with the 
private key f
or the benefit of one or more End-Users. If the set of claims does not 
allow to uniquely
identify the End-user, he cannot be caught.

Key Binding JWT (KB-JWT):A JWT for proving Key Binding as defined
in Section 5.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.

Referring to a subsequent Section is not adequate for a definition.
The definition should be self-understandable.

Key Binding JWT (KB-JWT):A JWT that allows a Holder 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 or
during a time period; and allows the Verifier to make sure that
these limitations are enforced by an entity that has the knowledge
of a private key corresponding to a public key contained in the
SD-JWT.

Issuer:An entity that creates SD-JWTs.

Replace with:

Issuer:An entity that creates SD-JWTs and Disclosures.

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.

Replace with:

Holder:An application supported by some 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, the Holder application is placed under
the control of an End-User.

_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. Their characteristics are fundamental to
successfully achieve or not "key binding".

Verifier:An entity that requests, checks, and extracts the claims
from an SD-JWT with its respective Disclosures.

Replace with:

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.

Add:

End-User: an individual assumed to have the control of a Holder.

Correct Figure 1 as below:

3.Flow Diagram

+------------+
||
|Issuer|
||
+------------+
|
Issues SD-JWT + All.Disclosures
|
v
+------------+
||
|Holder|End-User
||
+------------+
|
Presents SD-JWT + Sel.Disclosures + KB-JWT
|
v
+-------------+
||+
|Verifiers||+
||||
+-------------+||
+-------------+|
+-------------+

Figure 1: SD-JWT Issuance and Presentation Flow
(...)

5.SD-JWT and SD-JWT+KB Data Formats

An SD-JWT is composed of

*an Issuer-signed JWT, and
*zero or more Disclosures.

No. The Disclosures are outside the Issuer-signed JWT.

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.

No. The string "SD-JWT+KB" should be replaced by "SD-JWT + KB-JWT".

(...)

5.1.Issuer-signed JWT

An SD-JWT has a JWT component that MUST be signed using the Issuer's
private key.It MUST NOT use the none algorithm.

The payload of an SD-JWT is a JSON object according to the following
rules:

1.The payload MAY contain the _sd_alg key described in
Section 5.1.1.
2.The payload MAY contain one or more digests of Disclosures to
enable selective disclosure of the respective claims, created and
formatted as described in Section 5.2.
3.The payload MAY contain one or more decoy digests to obscure the
actual number of claims in the SD-JWT, created and formatted as
described in Section 5.2.5.
4.The payload MAY contain one or more non-selectively disclosable
claims.
5.The payload MAY contain the Holder's public key(s) or
reference(s) thereto, as explained in Section 5.1.2.
6.The payload MAY contain further claims such as iss, iat, etc. as
defined or required by the application using SD-JWTs.
7.The payload MUST NOT contain the reserved claims _sd or ...
except for the purpose of transporting digests as described
below.

The payload MUST contain the claim name "scac".

oClaim Name: "scac"
oClaim Description: Secure cryptographic application characteristics

This is a new claim name that shall be registered by IANA.

This claim allows the Verifier to know the characteristics of the secure 
cryptographic application
that has been used to request to an Issuer a SD-JWT with All.Disclosures.

In practice, it indicates the characteristics of a Trusted Application 
running in a TEE under a Trusted OS.

Without that information that Verifier would be unable to know the 
characteristics of the most important element
from the Holder (application).

5.1.2.Key Binding

(...)

Note that, as was stated in [RFC7800], if an application needs to
represent multiple proof-of-possession keys in the same SD-JWT, one
way to achieve this is to use other claim names, in addition to cnf,
to hold the additional proof-of-possession key information.

Change the last line into:

to hold the additional proof-of-knowledge key information.

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.

Not really. The secure cryptographic application which is part of the
Holder application SHALL generate the pair. This is a key point for using
key binding. The private key from the key pair MUST NOT be exportable,
unless specifically authorized (in particular for Holder back-up purposes).

Remove this paragraph and replace it with:

The key pair SHALL be generated by a secure cryptographic application that
is part of the Holder and the characteristics of that application SHALL be
included in SD-JWT using the claim "scac".

5.2.1.Disclosures for Object Properties

Section 5.2.2 (Disclosures for Array Elements) contains a consideration
that should also be applied to section 5.2.1 (Disclosures for Object 
Properties).

Add the following text:

The Issuer MUST 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. 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.

5.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.

Requiring a nonce allows to prevent replays.However, there exists some
cases where the same SD-JWT should be usable by a set of Verifiers during
some period of time.This case is currently not supported, but should be
allowed.The main idea is to use EITHER a "nonce" OR "aud" + "nbf"
+ "exp". Note that **when a "nonce" is being used, **"aud" is NOT REQUIRED.

Change into:

*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: OPTIONAL.The intended receiver of the Key Binding JWT.
When the nonce claim is not present, the aud claim SHAL be present.
How the value is represented is up to the protocol used and out
of scope of this specification.

-nonce: OPTIONAL.Ensures the freshness of the signature.
When the nonce claim is not present, the aud, nbf and exp claims
SHALL be presentThe 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.

-nbf : OPTIONAL. Indicates the beginning of the validity period of
the KB-JWT. When the nonce claim is not present, the nbf claim
SHALL be present.

-exp : OPTIONAL.Indicates the end of the validity period of
the KB-JWT. When the nonce claim is not present, the exp claim
SHALL be present.

-sd_hash: REQUIRED.The base64url-encoded hash value over the
Issuer-signed JWT and the selected Disclosures as defined
below.


5.3.2.Validating the Key Binding JWT

The Verifier MUST ensure that the key with which it validates the
signature on the Key Binding JWT is the key specified in the SD-JWT
as the Holder's public key.For example, if the SD-JWT contains a
cnf value with a jwk member, the Verifier would parse the provided
JWK and use it to verify the Key Binding JWT.

This description is insufficient.
What about EITHER "nonce OR "aud" + "nbf" + "exp" ?

(...)

8.1.Verification of the SD-JWT

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
*all Disclosures are valid and correspond to a respective digest
value in the Issuer-signed JWT (directly in the payload or
recursively included in the contents of other Disclosures).

The Holder or the Verifier MUST perform the following (or equivalent)
steps when receiving an SD-JWT:

1.Separate the SD-JWT into the Issuer-signed JWT and the
Disclosures (if any).
2.Validate the Issuer-signed JWT:
1.Ensure that a signing algorithm was used that was deemed
secure for the application.Refer to [RFC8725], Sections 3.1
and 3.2 for details.The none algorithm MUST NOT be
accepted.
2.Validate the signature over the Issuer-signed JWT per
Section 5.2 of [RFC7515].
3.Validate the Issuer and that the signing key belongs to this
Issuer.
4.Check that the _sd_alg claim value is understood and the hash
algorithm is deemed secure (see Section 5.1.1).

This is insufficient. Add:
     Verify that the Issuer can be trusted.
     Verify that the claim "scac"contains an appropriate value.

(...)

8.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.

(...)

10.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 sentences are incorrect.

Let us suppose that an End-User A 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 B
accepts to collaborate with the End-User A.The End-User A transmits the
nonce to the End-User B which provides to the End-User A a "SD-JWT
+ Sel.Disc. + KB-JWT". Then, the End-User A can take benefit of claims
that belong to the End-User B. 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 this mailing list on 07 November
2016. The ABC attack (the Alice and Bob Collusion attack).
See: 
https://mailarchive.ietf.org/arch/msg/oauth/UIsbsVtINPifrCjG7GDZM7FOi2g/.

A few extracts:

Whatever kind of cryptographic is being used, when two users
collaborate, a software-only solution will be unable to prevent
the transfer of an attribute of a user that possess it to another
user that does not possess it .

The use of a secure element simply 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.

Change into:

Key Binding aims to ensure that the presenter of a SD-JWT + Sel.Claims
+ KB-JWT to a Verifier has either the knowledge of a private key
corresponding to a public key contained in a SD-JWT or the ability to
obtain a cryptographic result performed using that private key.

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 the Holder prove the knowledge
of that private key when presenting an SD-JWT + Sel.Claims + KB-JWT
structure to a Verifier.

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.

With Key Binding, if two End-Users accept to collaborate, unless
additional characteristics are supported by the Holders, a credential
can voluntarily be transmitted by the legitimate Holder of a private
key to another Holder.

(...)

The following types of unlinkability are considered here:

*Presentation Unlinkability: A Verifier should not be able to link
two presentations of the same credential.

This sentence is incorrect. If it is the same credential, then it is always
possible to link the same credential.

Change into:

*Presentation Unlinkability: A Verifier should not be able to link
two presentations of the same set of claims, when that set does
not allow to unambiguously identify an individual.

*Verifier/Verifier Unlinkability: Two colluding Verifiers should
not be able to learn that they have received presentations of the
same credential.

Change into:

*Verifier/Verifier Unlinkability: Two colluding Verifiers should
not be able to link two presentations of the same set of claims,
when that set does not allow to unambiguously identify an individual.

*Issuer/Verifier Unlinkability (Colluding/Compromised Verifier): An
Issuer of a credential should not be able to tell that a user
presented the credential to a certain Verifier, even if the
Verifier colludes with the Issuer or becomes compromised and leaks
stored credentials from presentations.

_COMMENT_: If the Verifier is dishonest or compromised, it can contact 
the Issuer
and disclose the SD-JWT to the Issuer. Looking at the paragraph placed 
after the next paragraph,
the text states that this property cannot be supported when using 
SD-JWTs, so why is it mentioned ?
It should rather be deleted. FYI, that paragraph states:

Issuer/Verifier unlinkability with a colluding or compromised
Verifier cannot be achieved in salted-hash based selective disclosure
approaches, such as SD-JWT, as the issued credential with the
Issuer's signature is directly presented to the Verifier, who can
forward it to the Issuer.

The text continues with:

In considering Issuer/Verifier unlinkability, it is important to note
the potential for an asymmetric power dynamic between Issuers and
Verifiers.This dynamic can compel an otherwise honest Verifier into
collusion.For example, a governmental Issuer might have the
authority to mandate that a Verifier report back information about
the credentials presented to it.Legal requirements could further
enforce this, explicitly undermining Issuer/Verifier unlinkability.
Similarly, a large service provider issuing credentials might
implicitly pressure Verifiers into collusion by incentivizing
participation in their larger ecosystem.Deployers of SD-JWT must be
aware of these potential power dynamics, mitigate them as much as
possible, and/or make the risks transparent to the End-User.

A name should be given to that characteristic, for example:

*Issuer/Verifier Unlinkability (Verifier constrained by a national 
authority)

The text quoted above should be rearranged to described it.

11.3.Confidentiality during Transport

Change into:

11.3.Confidentiality and integrity during Transport

In the following text, change "confidentiality" into "integrity and 
confidentiality".

END OF COMMENTS

Denis

*
> All,
>
> As per the discussion in Vancouver, this is a WG Last Call for the 
> *SD-JWT *document.
> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-11.html
>
> Please, review this document and reply on the mailing list if you have 
> any comments or concerns, by *Sep 17th*.
>
> Regards,
>   Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list [e-mail]
> To unsubscribe send an email [e-mail]