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.
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
F. VOCABULARYI 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).
Since Figure 1 does not describe the interactions between the Holder software and hardware and a human userG. ARRAY ELEMENTS. Various comments (See comments 11 and 12).
a Holder can only be the "software and hardware" (See comment 10).
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 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.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
