> On 7 Nov 2023, at 15:50, Denis <[email protected]> wrote:
>
> Hi Neil,
>
>> On 7 Nov 2023, at 13:13, Denis <[email protected]
>> <mailto:[email protected]>> 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".
>
I think that part of it is fine as it is. It states the properties it does
support up-front and mentions things it doesn’t support in the security/privacy
considerations. That seems pretty standard practice. I wouldn’t object to the
authors adding text clarifying that to the summary, but it doesn’t seem
necessary to me.
> 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.
>
I’m not sure I follow this logic. You want to issue multiple single-use SD-JWTs
to ensure unlinkability, but think it’s too much to issue multiple normal JWTs?
Anyway, this is getting somewhat off the point. SD-JWTs as specified contain no
features to support unlinkability and this is clearly not a goal of the spec.
The fact that you might want it to be a goal doesn’t make it so.
>>
>>>
>>> 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.
>
Indeed, which is what I suggested. Watson Ladd suggested this would lead to
some kind of privacy leak, which you agreed with. I take it now that you don’t
agree with that, but instead agree with me that there are certain claims that
shouldn’t be selectively disclosable?
— Neil
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
