On 7 Nov 2023, at 13:13, Denis <denis.i...@free.fr> wrote:
> 
> 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 .

The very first sentence of that section clearly states that SD-JWTs can be 
linked. The fact that it also mentions other things you can do, entirely 
orthogonal to the use of SD-JWT, doesn't contradict that, it rather reinforces 
it. (As I've said previously when SD-JWT was first proposed, if you are willing 
to issue a batch of credentials then you don't need SD-JWT at all: just issue 
normal JWTs with subsets of claims matching anticipated selective disclosure 
cases. In all the concrete use-cases I've seen, this is not a large number of 
combinations).

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

The point of these kinds of security constraints (which are indeed mostly 
constraints and not claims), is to prevent certain attacks. Such as restricting 
the time-window in which a token can be used, so that if it is stolen there is 
a limit to how long it can be abused. The "attacker" here could be a third 
party that intercepts/phishes the token, or it could be a malicious Verifier, 
etc. If these constraints can be selectively disclosed then they are utterly 
useless in preventing the attacks they are designed to stop: time-limited 
tokens become unlimited time usage, key-bound tokens become bearer tokens, and 
single-use tokens become multiple-use. To say this is a *spectacularly* bad 
idea is an understatement. 

-- Neil



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to