Hi Neil,
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).
1) If some people are willing to support the Verifier/Verifier
unlinkability property, the document should provide more guidance
since a solution that does not use advanced cryptographic schemes is at
hand. Otherwise, the fact that the Verifier/Verifier
unlinkability property is not supported should be advertised in Section
1.1. "Feature Summary".
2) If you just issue normal JWTs with subsets of claims matching
anticipated selective disclosure cases, the burden is rather the same
for the Holder:
it needs to generate a different key pair for every SD-JWT. As soon as a
SD-JWT will be used towards a Verifier, it should be discarded
so that it cannot be reused towards another Verifier. This approach
might quadruple the number of JWTs to ask in advance.
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.
The point is not to use selective disclosure on claims that prevent
certain attacks.
Since these claims are used only once, they can be made unlinkable.
Denis
-- Neil
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
