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
