Hi Neil,
You wrote:
"Note that unlinkability is explicitly already not a goal for SD-JWT according to
section 12.4".
This is untrue:
12.4. Unlinkability
Colluding Issuer/Verifier or Verifier/Verifier pairs could link
issuance/presentation or two presentation sessions to the same user
on the basis of unique values encoded in the SD-JWT (Issuer
signature, salts, digests, etc.).
To prevent these types of linkability, various methods, including
but not limited to the following ones can be used:
- Use advanced cryptographic schemes, outside the scope of this
specification.
- *Issue a batch of SD-JWTs to the Holder to enable the Holder to
use a unique SD-JWT per Verifier*.
This only helps with Verifier/Verifier unlinkability.
This means using *single-use credentials *and issuing in advance
credentials batches, each one with a different holder-public key in it .
So, I generally agree with Watson.
Currently, the SPICE BoF /tentative /charter is considering
Verifier/Verifier unlinkability to be within the charter.
You also wrote:
Allowing an attacker to selectively disclose that a token has expired seems
problematic to say the least
Why an "attacker" ? This is not problem as soon as a SD-JWT is only used
once.
Denis
On 6 Nov 2023, at 16:43, Watson Ladd<watsonbl...@gmail.com> wrote:
On Mon, Nov 6, 2023 at 5:46 AM Neil Madden<neil.e.mad...@gmail.com> wrote:
How about the following:
—
An Issuer MUST NOT allow any security-critical claim to be selectively
disclosable. The exact list of “security-critical” claims will depend on the
application, and SHOULD be listed by any application-specific profile of
SD-JWT. The following is a list of standard claim names that SHOULD be
considered as security-critical by any SD-JWT Issuer:
* “iss” (Issuer)
* “aud” (Audience), although issuers may want to allow individual entries in
the array to be selectively-disclosable
* “exp” (Expiration Time)
* “nbf” (Not Before)
* “iat” (Issued At)
* “jti” (JWT ID)
In addition, the “cnf” (Confirmation Key) claim MUST NOT be selectively
disclosable.
---
<snip>
I think these fields can have significant unanticipated privacy
impacts. Expiry and issuance times can have very high entropy.
Can you expand on what you mean? What privacy threat do you envision? Note that
unlinkability is explicitly already not a goal for SD-JWT according to section
12.4.
Allowing an attacker to selectively disclose that a token has expired seems
problematic to say the least.
— Neil
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
