I had to read this a bunch of times, since you brought in a different draft than the one currently being discussed.
User collusion wrt signature: This has been the case for 35+ years as well. This is no different. Once user's collude, almost anything is possible.
I fear that you missed the reason why the current situation is different from what it was for 35+ years.
For more than 35 years, if a user A was giving away one of his
private keys to a user B, the user B was able to impersonate the
user A.
As user A will not know which operations the user B might do with
this key, this was a dangerous situation.
There are 53 definitions of the term "private key" in the ISO OBP. The one I find the most appropriate is the following:
private key
key of an entity's (3.38) asymmetric key pair that is kept secret and that should only be *used* by that entity
[SOURCE:ISO/IEC 9798-1:2010, 3.22]
ISO 22739:2024, 3.76
The one I consider incorrect is the following:
private key
key in an asymmetric key pair which is *known* only by that entity
ISO 11568:2023, 3.69
The user A does not need to know the value of a private key to
use it.
Instead of giving a private key away to a user B, the user A can
*use* it to perform some cryptographic computations for the
benefit of a user B.
In the case of impersonation, if the user A can know the content
(and thus the semantic) of the operation that the user B is
willing to perform,
the risk for the user A will be under control.
I hope that you know understand better the difference between PoP and PoU (despite the misuse of the acronym PoP during more than 10 years).
What is new in this draft is the fact that the draft is able to
support *one-time-use digital credentials* to implement the
verifier-verifier unlinkability.
We are no more in the area of impersonation. If the user A accepts
to perform the trick ( i.e., his Holder application performs some
cryptographic computations
for the benefit of a user B), he will NOT be identified. Bob can
then also perform the trick for the benefit of Belinda, Carla,
Debbie, Emma, etc ...
without being identified. While Bob would make the trick for Alice
for free, Bob would monetise his service for Belinda, Carla,
Debbie, Emma, etc ...
Is this SD-JWT a perfect technology? nope. Is it better than the current card carrying ID system (which is what we have here in the US)?
In every RFC, we mandate the presence of a "Security
considerations" section. Its role is to indicate the limitations
of the protocol.
Its role is not to hide its limitations. The limitations originate
from the following sentence in Section 4.1.2 :
"It is out of the scope of this document to describe how the
Holder key pair is established"
There is no sub-clause in the "Security considerations" section
that elaborates on this sentence.
As SD-JWT is NOT considering the characteristics of the Holder
application, the protocol CANNOT be secure. This should be
mentioned.
This means that, in the future, in order to become secure, SD-JWT
will need to be complemented *either* by incorporating other data
elements
into the protocol *or* by supporting an additional protocol
between the Holder and the Verifier (which would *not* be my
preferred choice).
At the moment, we only need to warn the implementers. We do not need to describe the solutions to the problem.
I would certainly say that it has the ability to protect a user's privacy better than a card with all manner of ID information on it.
Please let me know when you design (and document in a draft) the perfect system.
First of all, there will not be a single "99,9999 % prefect"
solution able to address user collaborative attacks.
However, all these solutions will need to share a common point: to
be implemented as TAs running under a TEE.
Only Trusted Applications (TAs) running in an environment
different from the RichOS will be capable to defeat the ABC attack
(Alice and Bob Collusion attack).
What is the current situation ?
Most smartphones (if not all) support a TEE, e.g., using Arm’s
TrustZone technology ® or Apple Secure Enclave ®.
The hardware is there, but smartphone manufacturers are unwilling
to let third-party app developers to add their own app, such as a
“Digital Identity Wallet”.
Third-party app developers can’t add either into the TEE engine
their own cryptographic algorithms, such as WOTSP-SHAKE_256.
Some smartphone manufacturers deliver a TA that supports an
interface compliant with the GlobalPlatform Card Specifications.
Such interface does support WOTS+ algorithms and does not allow to
defeat the ABC attack (as it only protects the knowledge
and the export of the keys, but does not control which
applications can use them).
What would be needed ? A "Trusted Application Manager" (TAM)
capable to download “external” TAs from trusted sources.
This piece of software does not currently exist and (for
commercial reasons) will probably never exist.
At the moment, some smartphone manufacturers deliver a set of
pre-installed TAs developed by themselves.
So we are far away for specifying a protocol within the IETF that nobody, except smartphone manufacturers, will be able to implement.
Note (for those following along): I found this hugely useful to helping me understand the issues with selective-disclosure: https://lowentropy.net/posts/selective-disclosure/ (By Martin Thomson)
I browsed through this paper and I read the following text:
This argumentation is lacking to mention that salted hash selective disclosure relying only on digital signatures and hash functions that are post-quantum resistantQuantum computers
Some of these systems depend on cryptography that is only classically secure. That is, a sufficiently powerful quantum computer might be able to attack the system.
Salted hash selective disclosure relies only on digital signatures and hash functions, which makes them the most resilient to attacks that use a quantum computer.
However, many of the other systems described rely on some version of the discrete logarithm problem being difficult, which can make them vulnerable.
Predicting when a cryptographically-relevant quantum computer might be created is as hard as any other attempt to look into the future, but we can understand some of the risks.
already exist today and that, even if we do not mandate any cryptographic algorithm into the core of the document, it would be worthwhile to indicate into the Security
considerations section which ones, that have been approved by IETF and NIST, can readily be used ... but only in the context of one-time use digital credentials.
Such algorithms are unlikely to be described in the context of JOSE in general, as they will only be usable in the context of one-time-use digital credentials.
Denis
Deb
On Fri, May 2, 2025 at 10:07 AM Denis <denis.ietf@xxxxxxx> wrote:
Deb,
(Sigh)
Section 11.2. from draft-ietf-oauth-sd-jwt-vc states:
In general, Issuers are advised to choose vct values following data
minimization principles. For example, government Issuers issuing an
SD-JWT VC to their citizens to enable them to prove their age, might
consider using a vct value that does not allow third-parties to infer
additional personal information about the Holder, e.g., country of
residency or citizenship.
Let us use this example, where a SD-JWT VC only contains a claim stating that the citizen is over 18.
Let us now take the Verifier point of view.
When using Key Binding, the Verifier can verify that the private key corresponding to the public binding key placed
into the SD-JWT has been correctly ***used***.
However, when only using the data elements defined in this draft, that private key might have been used by the legitimate user
... for the benefit of another user. In that case, the Verifier will be confident that the other user (Alice) is over 18, whereas
e.g., she is only 12. As the legitimate user (Bob) will not be identified, nor authenticated, he can perform this exploit many times,
in particular, when using one-time use SD-JWTs ("not seen, not caught" will apply).
The *use* of the right key is one concern, however detection of replays by the Verifier is another concern.
In order to detect replays, let us assume that the Verifier provides a challenge to the Holder and
that this challenge must be included into the Key Binding Token.
The attack scenario is rather straightforward: Alice connects to a Verifier, asks and receives back a challenge.
She forwards the challenge to Bob and she asks him to include this challenge into a KB Token. Bob performs
the computation for the benefit of Alice. Alice presents the KB Token (and the SD-JWT) to the Verifier and
the Verifier can now be confident that she is over 18. She *used* the Key Binding mechanism, but she never
*possessed* the private key.
You wrote:
"Use of a private key via signed message is a classic way of proving possession of that key for the last 35 years at least.While signed messages have been used a classic way of proving possession of a private key for the last 35 years,
Certainly, the entity that *performs* the signature possesses the key".
this has been accomplished in the context of authentication, integrity or of electronic signatures. What has recently changed
is the use of a private key to selectively disclose claims in a way where the user is no more necessarily authenticated.
This offers new opportunities which did not exist before: collaborative attacks between users.
The entity that *presents* the signature to a Verifier and got it accepted by a Verifier does not necessarily* possess* the key.
NIST SP 800-57 leads to a false sense of security, because what is prescribed in this document, while useful and necessary, is insufficient:
The TEEP WG (Trusted Execution Environment Provisioning) is considering the use of Trusted Execution Environments and of Trusted Applications.
At the moment, the draft is not indicating any relationship with TEEs and TAs, whereas it should. Unless a part of the Holder *application* which is usually
called a "digital identity wallet" is run as a TA under a TEE, the protocol cannot be secure.
The TA (i.e. the Holder *application*) must support some properties that are outside the scope of this draft.
Key Binding, Proof of Possession (PoP), Proof of Use (PoU) and replay protection are strongly related to TEEP, TAs and TEEs.
Denis
Denis,
I have the following responses inline marked as [DC] in the summary only (to save pages and pages of reading)
I have asked for two changes, which the authors have already published in a new draft. There is one issue/change that is in progress.
Note: I still do not see where the typo occurs in this (very long) message chain.
Deb Cooley
Sec AD
On Mon, Apr 14, 2025 at 1:21 PM Denis <denis.ietf@xxxxxxx> wrote:
The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'Selective Disclosure for JWTs (SD-JWT)' <draft-ietf-oauth-selective-disclosure-jwt-17.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@xxxxxxxx mailing lists by 2025-04-14. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting.The following comments are posted exceptionally to iesg@xxxxxxxx, because previously I responded
to the first and second WG LC and I got no reply to my comments.
After the second WG LC, I have posted on github https://github.com/oauth-wg/oauth-selective-disclosure-jwt
40 issues numbered #482 until #522 that have not been responded. Then after 16 comments: #546 to #562,
that have not been responded either. Hence, many of the comments that are posted today are not new comments.
I believe that some of them are substantive.
I made a full review of the document (with the exception of the appendices)
and I will first present my 17 comments shortly.
A. As currently described, the protocol is insecure as it can be subject to security attacks that have not been identified.
The draft considers "colluding Verifiers and Issuers" but omits to consider "colluding Holders and users" which can also exist.
[DC] Not a new comment: Last time around I called this an implementation issue (holders w/ hardware key stores and such). Most of the key handling/storage/protection parts are covered in Section 9.12 which states that keys have to be protected across the lifecycle. No change required.A detailed example of such an attack is provided. Key binding does not provide a proof of *possession* of a private key (PoP)
but only a proof of *use* of a private key (PoU). The difference is quite important. Detailed explanations are provided.
[DC] Not a new comment. This is editorial at best. Use of a private key via signed message is a classic way of proving possession of that key for the last 35 years at least. Certainly, the entity that performs the signature possesses the key. No change required.
See comments 1, 2, 3, 4 and 5 under the topic COLLUDING HOLDERS AND USERS and under the topic KEY BINDING.
B. As currently described, there is insufficient guidance in the draft that allows to correctly implement
a Key Binding JWT replay detection mechanism. In general, two methods can be used, but the draft does not allow
to know which one has been selected by the Holder. The processing by the Holder and by Verifier is insufficiently
explained. See comment 6 under the topic of REPLAY DETECTION OF a Key Binding JWT.
[DC] Not a new comment: In fact, Section 7.3 #6 lays out the components to detect replay. To clarify, your position has shifted from not requiring iat to replacing the nonce with two separate fields (rdn and chal).
*For the authors: Section 7.3, #6: protection/detection.
C. SD-JWT SUSPENSION OR REVOCATION IS MISSING (See comment 7)
*[DC] For the authors: The very first bullet of Section 7.1 states: “the Issuer-signed JWT is valid, i.e., it is signed by the Issuer and the signature is valid,..” Change to: “the Issuer-signed JWT is valid, i.e., it is signed by the Issuer, the signature is valid, and it is not suspended or revoked,…”
D. UNLINKABILITY It is important to introduce the term "one-time-use digital credential" (See comment 8).
[DC] as written now, a Holder can use a credential once. No change required.
E. POST-QUANTUM RESISTANCE KEY BINDING ALGORITHMS
I propose to add a new section that explains how one-time-use digital credentials that include a public binding key
can support Post-Quantum resistant key binding algorithms. Even if the document does not mandate the use of
any specific asymmetrical algorithm, this information can be useful for implementers as it is not widely shared.
(See comment 9).[DC] This is not a new comment. This response is also not new: This draft does not specify the selection of the algorithm used for signing either SD-JWT or SD-JWT-KB. It does point to “digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry”, and it does specify that it MUST NOT be ‘NONE’. When the JOSE working group specifies post quantum signature algorithms, then they will be available to be used to sign SD-JWT.
F. VOCABULARY
Since Figure 1 does not describe the interactions between the Holder software and hardware and a human user
a Holder can only be the "software and hardware" (See comment 10).[DC] Again, not a new comment: The suggestion is pertinent for one possible implementation of the format. Keeping the format language clear and concise is important.
G. ARRAY ELEMENTS. Various comments (See comments 11 and 12).
*[DC] 11. A potential for a slight change, in progress…
[DC] 12. multiple nationalities are already mentioned/described in Section 4.2.6. No change required.
H. KEY PAIR GENERATION AND LIFECYCLE MANAGEMENT (See a minor comment 13).
[DC] there is no mention of honest and dishonest owners in NIST SP 800-57 part 1, r5. How exactly does this lead to a false sense of security? No changes required.
I. EDITORIAL COMMENTS (See comments 14 to 17).
[DC] none of these require changes. Either they are clear already, the editor will correct grammar, colluding Verifiers are indeed adversaries, and integrity is already provided why is extra integrity protection required.
_______________________________________________
============================================================
COLLUDING HOLDERS AND USERS
1. Collaborative attacks between colluding users and Holders
Page 12 states:
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.
The document does not also consider how the protection of the *use* of the key pair should be done.
Whether this protection is "good", "weak" or inexistent has a great importance.
As a simple example, if the key pair can be exported from a Holder and then imported into another Holder,
then that other Holder will be able to use the private key and get advantage of SD-JWTs that were under
the control of the first Holder.
A more elaborated example is the ability for a Holder to perform all the cryptographic computations
that are necessary for another Holder without releasing the value of the private key to that other Holder.
In that case, key binding does not provide a proof of *possession* of a private key (PoP)
but only a proof of *use* of a private key (PoU).
Collaborative attacks between "colluding user and Holders", which imply the use of Holders specifically developed
to cheat a Verifier should be mentioned.
This should also be addressed using an additional section under section 9 (Security Considerations).
It is thus proposed to add a section 9.13 about Collaborative attacks between colluding users and Holders.
The text change proposals for the others sections will be presented afterwards.
Text proposal:
9.13 Collaborative attacks between colluding users and Holders
If two users accept to collaborate, the Holder used by one user can
perform cryptographic computations for the benefit of another Holder.
For example, an application (i.e., a Holder) developed by a
specialist can be downloaded by each user. If that application is
able to use the private keys from an original Holder, the second
Holder can perform cryptographic computations for the benefit of
another Holder.
An example scenario is as follows: a Holder A connects to a
Verifier and receives back a challenge and a list of claim types that
it will need to present to get an access. The Holder A forwards to
a Holder B the challenge received from the Verifier, the name of the
Verifier and the set of claim types and values that it wishes to
present to the Verifier. The Holder A receives back from the other
Holder B the data structure that the Holder A needs to present to get
an access to that Verifier. The Holder A forwards it to the Verifier
and gets the access.
Another example scenario is as follows: if private keys can be
exported from the Holder with the user consent and then used by
another Holder, impersonation of the user can be achieved by the
second Holder.
It is outside the scope of this document to specify how a Verifier
can know whether appropriate characteristics or properties are
effectively used by a Holder to ensure that collaborative attacks
cannot be performed between Holders.
KEY BINDING
2. On page 4, the text states:
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.
The private key is only presumed to be under the control of the Holder.
The protocol does not allow to demonstrate that it is really the case,
since the characteristics of the Holder are unknown to the Verifier.
A Verifier can only check that a Holder has been able to *use* a private key
associated with a public key contained in a SD-JWT.
Text change proposal:
This specification defines a mechanism for binding the SD-JWT to
a key that is presumed to be under the control of the Holder (Key
Binding). When Key Binding is enforced, a Verifier can check that
a Holder has been able to use a private key associated with a
public key contained in the SD-JWT.
3. On page 6, the text states:
Key Binding: Ability of the Holder to prove 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 Binging only allows to demonstrate that a private key that is associated with a public key
placed into a SD-JWT has been correctly used. It does not allow to known that the private key
is indeed *possessed* by a Holder, since characteristics of the Holder are unknown to the Verifier.
Text change proposal:
Key Binding: Ability of the Holder to prove the ability to use a
private key associated with a public key contained in an SD-JWT
by using this private key during the presentation. When
utilizing Key Binding, an SD-JWT contains the public key
corresponding to the private key used by the Holder (or a
reference to this public key).
4. On page 43, section 9.5. Key Binding states:
Key Binding aims to ensure that the presenter of an SD-JWT credential
is actually the 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.
It is well known that the wording "prove possession of a private key" has been used for years.
However, strictly speaking the use of the word "possession" is incorrect.
From a Verifier point of view, a correct SD-JWT+KB proves the *use* of the private key associated
with a public binding key contained in a Key Binding JWT and it does not necessarily prove
the *possession* of it (See comment 1).
This private key can *EITHER* be used by the (legitimate) Holder *OR* can be used by the Holder
for the benefit of another Holder (see the example in the previous comment).
When using the protocols described in this document, it is impossible for a Verifier to make
the distinction between these two cases.
The document is implicitly considering (without never stating it) that Holders and users are "honest",
whereas this will not necessarily be the case.
The document considers "colluding Verifiers and Issuers" but
does not consider "colluding Holders and users" which can also exist.
Therefore this is a major security issue which has not been identified and that makes this protocol insecure.
A false sense of security might be inferred when implementing this document. This should be said.
Text change proposal:
An SD-JWT compatible with Key Binding contains a public key, or a
reference to a public key, that corresponds to a private key that
can be used by a Holder either for its own benefit or for the benefit
of another Holder. When presenting a key Binding JWT, the Verifier
requires that the Holder demonstrates the use of the private key.
5. On page 12. Section 4.1.2, the text states:
It is out of the scope of this document to describe how the Holder
key pair is established.
This text is fine. However, it would be useful to add that it is also out of the scope of this document
to describe how the private key is protected and usable by the Holder under the control of the user.
Text change proposal:
It is out of the scope of this document to describe how the Holder
key pair is established and how the private key is protected and
usable by the Holder under the control of the user.
REPLAY DETECTION OF a Key Binding JWT
6. Section 4.3. Key Binding JWT states:
The Key Binding JWT MUST be a JWT according to [RFC7519] and its
payload MUST contain the following elements:
* (...)
* 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].
- 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.
This description does not allow to interoperate in a secure fashion
in particular while reading section 7.3. Verification by the Verifier.
How replay *detection* can be done is not described in the document.
Note: While replay *prevention* cannot be done, replay *detection* can be done.
Whatever technique is being used, the Verifier must maintain some states during a time window.
Two techniques can be used. Each one has advantages and inconveniences.If correctly implemented, both techniques provide the same replay attack detection guarantees.
The choice of the appropriate technique will be context dependant.This means that the document should describe these two techniques.
A Verifier MUST support these two techniques. However, a Holder MAY only support one of these two techniques.
Note: The kind of data that will need to be kept by the Verifier during the time window will be dependent
upon the technique being used. For each technique, the time window can be different.
These two techniques have been described in detail in the following issued that was initially raised by Christian.
https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/104
In a client - server paradigm, there exist two mechanisms that are able to *detect* replay attacks either:
- using "unique numbers" generated and sent by a client to a server, or
- using "challenges" generated and sent by a server to a client.
Unique numbers which are generated by a Holder shall be non-repeating for ever.
In practice, such requirement can be supported by using two parameters:- the time at which the Key Binding JWT ("iat" claim) has been generated and
- a random number ("rnd" claim) that needs to be unique only during a short time-window.
This means that for using unique numbers, the Holder is required to support a clock synchronised with UTC.
Challenges generated by a Verifier need to be unique only during a short time-window.
This means that for using challenges, the Holder is not required to support a UTC synchronised with UTC.
This leads to consider the following three claims: "iat", "rdn" (for random number) and "chal" (for challenge).
The text quoted at the beginning of this comment should be changed into:
The Key Binding JWT MUST be a JWT according to [RFC7519] and its
payload MUST contain the following elements:
* (...)
* in the JWT payload,
- iat: CONDITIONAL. The value of this claim MUST be the time at
which the Key Binding JWT was issued using the syntax defined
in [RFC7519].
- rdn: CONDITIONAL. Ensures the freshness of the signature and
allows to detect replays. The value type of this claim MUST be
a string generated by the Holder.
- chal: CONDITIONAL. Ensures the freshness of the signature and
allows to detect replays. The value type of this claim MUST be
a string generated by the Verifier.
EITHER, both the "iat" and the "rdn" claims MUST be present OR the "chal" claim MUST be present.
Then after, the text from section 7.3. Verification by the Verifier on page 35 would need to be fixed.
Below is an extract from the current text:
To this end, Verifiers MUST follow the following steps (or
equivalent):
1. (...)
5. If Key Binding is required:
1. (...)
(...)
5. Check that the creation time of the Key Binding JWT, as
determined by the iat claim, is within an acceptable window.
6. Determine that the Key Binding JWT is bound to the current
transaction and was created for this Verifier (replay
protection) by validating nonce and aud claims.
Text change proposal:
To this end, Verifiers MUST follow the following steps (or
equivalent):
1. (...)
5. If Key Binding is required:
1. (...)
(...)
5. Determine that the Key Binding JWT is bound to the current
transaction and was created for this Verifier by validating
the aud claims.
6. Check that the Key Binding JWT is not a replay of previously
accepted JWT by checking first whether a "rdn" claim or a "chal"
claim is present. If none is present, then the Key Binding JWT
shall be rejected.
7. If a "rdn" claim is present, then the "iat" claim shall also
be present, otherwise the Key Binding JWT shall be rejected.
The Verifier shall choose a time-window to verify pairs of
"rdn" and "iat" claims and maintain a list of validated pairs
of "iat" and "rdn" claims.
a) If a received "iat" claim is outside of this time-window,
then the Key Binding JWT shall be rejected and the
Verifier should respond with an error.
b) If a received "iat" claim is inside this time window
and the values both of "iat" claim and of the associated
"rdn" claim are already present in the list of validated
pairs of "iat" and a "rdn" claims, then the Key Binding
JWT shall be rejected and the Verifier should respond
with an error.
c) If a received "iat" claim is inside this time-window
and the values both of "iat" claim and of the
associated "rdn" claim are not already present in the
list of validated pairs of "iat" and a "rdn" claims,
and the associated "rdn" claim can successfully be used
to validate a Key Binding JWT, then the Verifier shall
add the values both of "iat" claim and the associated
"rdn" claim into a list of validated pairs of "iat" claim
and "rdn" claim.
When the value of a "iat" claim from an entry falls
outside of the time-window, the Verifier can remove the
entry from the list.
8. If a "chal" claim is present, then the Verifier shall check
whether the received challenge has previously been generated
and sent to a Holder. The Verifier shall maintain a list of
sent challenges to Holders during a time-window chosen by
itself.
a) If a received "chal" claim is not present in the list,
then the Key Binding JWT shall be rejected and the
Verifier should respond with an error.
b) If a received "chal" claim is present in the list and
can be successfully used to validate a Key Binding JWT,
then the Verifier shall remove this value from the list
of challenges. Otherwise, the value must remain at
least until the end of the time-window.
Note: In order to manage the removal of old challenges
by the Verifier, it is recommended that the Verifier
locally associates a time of issuance with each challenge.
It is now necessary to fix the text from section 7.2. Processing by the Holder.
Below is an extract from the current text:
(...)
For presentation to a Verifier, the Holder MUST perform the following
(or equivalent) steps (in addition to the checks described in
Section 7.1 performed after receiving the SD-JWT):
1. Decide which Disclosures to release to the Verifier, obtaining
proper consent if necessary.
2. Verify that each selected Disclosure satisfies one of the two
following conditions:
1. The hash of the Disclosure is contained in the Issuer-signed
JWT claims
2. The hash of the Disclosure is contained in the claim value of
another selected Disclosure
3. Assemble the SD-JWT, including the Issuer-signed JWT and the
selected Disclosures (see Section 4 for the format).
4. If Key Binding is not required:
1. Send the SD-JWT to the Verifier.
5. If Key Binding is required:
1. Create a Key Binding JWT tied to the SD-JWT.
2. Assemble the SD-JWT+KB by concatenating the SD-JWT and the
Key Binding JWT.
3. Send the SD-JWT+KB to the Verifier.
It can be seen that in step 5, there is no guidance on how replay detection should be handled by the Holder.
Text change proposal for step 5:
5. If Key Binding is required:
1. Decide whether replay detection by the Verifier will be
checked using "unique numbers" generated by the client or
"challenges" generated by the Verifier. Using "challenges"
generated by the Verifier will only be possible if a
challenge has been previously received from the Verifier.
2. If the Holder chooses to use "unique numbers", it shall be
able to use a UTC clock and to generate a random number, and
shall place two values respectively into the "iat" claim and
the "rnd" claim.
3. If the Holder chooses to use "challenges", it shall place the
received challenge into the "chal" claim.
4. Assemble the SD-JWT+KB by concatenating the SD-JWT and the
Key Binding JWT.
5. Send the SD-JWT+KB to the Verifier.
SD-JWT SUSPENSION OR REVOCATION IS MISSING
7. Checking SD-JWT suspension or revocation is missing in section 7.1 (Verification of the SD-JWT)
Steps 6 is currently described as follows:
6. Check that the SD-JWT is valid using claims such as nbf, iat, and
exp in the processed payload. If a required validity-controlling
claim is missing (see Section 9.7), the SD-JWT MUST be rejected.
None of the checks that are described is about the checking the status of the SD-JWT,
e.g., whether it has been suspended or revoked.
Add the following step:
7. Check that the status of the SD-JWT is valid, e.g., whether it has
been suspended or revoked. The way this can be accomplished is out
of the scope of this document.
UNLINKABILITY
8. On page 48, the text states:
Verifier/Verifier unlinkability and presentation unlinkability can be
achieved using batch issuance: A batch of credentials based on the
same claims is issued to the Holder instead of just a single
credential. The Holder can then use a different credential for each
Verifier or even for each session with a Verifier.
This description is missing to indicate the major characteristic of a SD-JWT
when batch issuance is being used: each SD-JWT shall only be used once.
The batch includes a set of one-time-use SD-JWTs, each one with a different content,
including a public binding key when key binding is being used.
The term "one time-use digital credential" should be added into the text.
Change proposal:
Verifier/Verifier unlinkability and presentation unlinkability can be
achieved using batch issuance: a batch of one-time-use digital
credentials based on the same claims can be issued to the Holder
instead of just a single digital credential. The Holder can then use
a different digital credential for each Verifier or even for each
session with a Verifier. One time-use SD-JWTs shall have a different
content, including a different public binding key when key binding
is supported.
POST-QUANTUM RESISTANCE KEY BINDING ALGORITHMS
9. It is proposed to add a section about Post-Quantum resistance to section 9 (Security Considerations).
This text proposal comes from the observation that OTS (One-Time Signatures) algorithms are well suited
to be used with one-time-use digital credentials.
Text proposal:
9.15 Post-Quantum resistant key binding algorithms
Implementations of SD-JWT rely on asymmetric cryptographic keys.
This document does not mandate the use of particular key binding
algorithm.
It can be observed that Elliptic Curve Digital Signature Algorithm
(ECDSA) which offers a variant of the Digital Signature Algorithm
(DSA) which uses elliptic-curve cryptography, by construction, cannot
be resistant to Post-Quantum computers. Alternative algorithms or
techniques (e.g., ZKP) that would be Post-Quantum resistant are being
explored.
When using batches of single time-use credentials (see section 10.1),
it is possible to use asymmetric key algorithms that are considered
to be post-quantum resistant. If the private "Binding Key“ is only
used once, then the key binding algorithm can Post-Quantum resistant.
This will be the case when using OTS (One-Time Signatures) and
inserting the public key of a Winternitz - One-Time Plus (WOTS+)
algorithm into a one-time-use digital credential.
In case of a lack of Internet access, batches of "one-time use digital
credentials” should be requested in advance.
Interoperability is possible by choosing one (or more) out of seven
WOTS+ algorithm identifiers that have been registered by IANA.
See: https://www.iana.org/assignments/xmss-extended-hash-based-
signatures/xmss-extended-hash-based-signatures.xhtml
These algorithms are described in [RFC8391], section 5.2 and in
[SP 800-208] section 5.
VOCABULARY
10. On page 6, the text states:
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.
The document only defines a subset of protocols between three entities.
Figure 1 does not describe the interactions between the Holder software and hardware
and a human user.
Text change proposal:
Holder: An entity that received SD-JWTs from the Issuer and
optionally holds the associated private keys and has
control over them. In the context of this document, the term
refers to the supporting software and hardware.
ARRAY ELEMENTS
11. On page 14. Section 4.2.2, the text states:
For example, a Disclosure for the second element of the nationalities
array in the following JWT Claims Set:
{
"nationalities": ["DE", "FR"]
}
could be created by first creating the following array:
["lklxF5jMYlGTPUovMNIvCA", "FR"]
The resulting Disclosure would be:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0
This example is interesting, but is not fully privacy preserving. It allows to know that a user has two nationalities.
In order to be hide this characteristic, a fixed number of values should be used instead by the Issuer and
when a user has less than this maximum number of nationalities, some values would need to be duplicated.
For example, if a maximum number of nationalities is 3 and the user has only one nationality, the following array should be used:
{
"nationalities": ["FR", "FR", "FR"]
}
This issue should be mentioned here while the solution might be detailed later on, e.g., in section 4.2.5. Decoy Digests.
12. On page 17. Section 4.2.5. Decoy Digests, the text states:
Decoy digests MAY be added both to the _sd array for objects as
well as in arrays.
(...)
To ensure readability and replicability, the examples in this
specification do not contain decoy digests unless explicitly stated.
Decoy digests work differently whether they apply to the _sd array for objects or to an array.
This difference is not explained but should be explained.
Duplicated values in an array is a means to hide the number of really significant values in an array.
See the example above about:
{
"nationalities": ["FR", "FR", "FR"]
}
This consideration should be added into section 4.2.6. Recursive Disclosures.
KEY PAIR GENERATION AND LIFECYCLE MANAGEMENT
13. On page 46, Section 9.12. Key Pair Generation and Lifecycle Management states:
Implementations of SD-JWT rely on asymmetric cryptographic keys and
must therefore ensure that key pair generation, handling, storage,
and lifecycle management are performed securely.
While the specific mechanisms for secure key management are out of
scope for this document, implementers should follow established best
practices, such as those outlined in NIST SP 800-57 Part 1
[NIST.SP.800-57pt1r5].
Following this Recommendation is certainly useful, but might lead to a false sense of security.
On Page 15 from [NIST.SP.800-57pt1r5], the Owner (of a key or key pair) is defined as:"For a static key pair, the entity that is associated with the public key and authorized to use the private key".
The entity that is associated with the public key and authorized to use the private key may use the private key
either in an "honest" way or in a "dishonest" way.
As long as the private key is used in an "honest way", there is no problem, but in the context of this draft
it is possible to disclose a single claim without being identified. The use of private binding keys should be
restricted to "honest" appropriate applications.
It is proposed to add the following text at the end of section 9.12:
While best practices for an appropriate key management are essential,
in the context of this document, while necessary, they are
insufficient. In particular, a private binding key should only be
usable by an "honest" appropriate application.
EDITORIAL COMMENTS
14. EDITORIAL change: On page 6, the text states:
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.
An SD-JWT is issued to a user. It would be useful to state that the claims in the SD-JWT
relate to a user that, later on, will be able to consent to selectively disclose some claims.
Hence the words "issued to a user" have been added.
Text change proposal:
Selectively Disclosable JWT (SD-JWT): A composite structure,
consisting of an Issuer-signed JWT (JWS, [RFC7515]) issued to
a user and zero or more Disclosures, which supports selective
disclosure as defined in this document.
15. EDITORIAL change: On page 19, in Section 4.3. Key Binding JWT the text states:
This section defines the Key Binding JWT, which encodes a signature
over an SD-JWT by the Holder's private key.
A Holder can have more that one private key,
hence the article "a" should be used instead of the article "the".
Text change proposal:
This section defines the Key Binding JWT, which encodes a signature
over an SD-JWT by a Holder's private key.
16. EDITORIAL change. On page 47, section 10.1. Unlinkability states:
Unlinkability is a property whereby adversaries are prevented from
correlating credential presentations of the same user beyond the
user's consent. Without unlinkability, an adversary might be able to
learn more about the user than the user intended to disclose, for
example:
The use of the term "adversaries" looks odd as the entities are collaborating or colluding
but and are not adversaries.
Change proposal:
Unlinkability is a property whereby colluding Verifiers and/or
Issuers are prevented from correlating credential presentations of
the same user beyond the user's consent. Without unlinkability,
colluding parties might be able to learn more about the user than
the user intended to disclose, for example:
17. EDITORIAL change. On page 50, section 10.3. Confidentiality during Transport
Both confidentiality and integrity during Transport are essential.
In section 10.3, the text states:
Usually, transport protocols for issuance and presentation of credentials are designed
to protect the confidentiality of the transmitted data, for example, by requiring the use of TLS.
This specification therefore considers the confidentiality of the data to be provided
by the transport protocol and does not specify any encryption mechanism.
Confidentiality alone would be insufficient. It is necessary to consider both confidentiality and integrity.
Everybody is using TLS today which supports both confidentiality and integrity.
Change into:
10.3. Confidentiality and integrity during Transport
Usually, transport protocols for issuance and presentation of credentials are designed
to protect the confidentiality and the integrity of the transmitted data, for example,
by requiring the use of TLS.
This specification therefore considers the confidentiality and the integrity of the data
to be provided by the transport protocol and does not specify any specific cryptographic mechanism.
This text is sufficient and the remaining of this section which is copied below can be removed:
DenisImplementers MUST ensure that the transport protocol provides confidentiality
if the privacy of user data or correlation attacks by passive observers are a concern.
To encrypt the SD-JWT when transmitted over an insecure channel, implementers MAY use
JSON Web Encryption (JWE) [RFC7516] by nesting the SD-JWT as the plaintext payload of a JWE.
Especially, when an SD-JWT is transmitted via a URL and information may be stored/cached
in the browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE.
OAuth mailing list -- oauth@xxxxxxxx
To unsubscribe send an email to oauth-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
