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-c...@ietf.org mailing lists by 2025-04-14. Exceptionally, comments may
be sent toi...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
*The following comments are posted exceptionally to i...@ietf.org,
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.
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. **
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**.
C. **SD-JWT SUSPENSION OR REVOCATION IS MISSING**(See comment 7)
D. **UNLINKABILITY**It is important to introduce the term
"one**-time-use digital **credential" (See **comment 8)**.
**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).*
*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).*
*G. ARRAY ELEMENTS. Various comments (See comments 11 and 12).
H. KEY PAIR GENERATION AND LIFECYCLE MANAGEMENT (See a minor comment 13).
I. EDITORIAL COMMENTS (See comments 14 to 17).
**
===========================================================================
**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 p**age 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:
*
*Implementers 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
<https://drafts.oauth.net/oauth-selective-disclosure-jwt/draft-ietf-oauth-selective-disclosure-jwt.html#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. *
**
***Denis*
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
