[OAUTH-WG] Re: SD-JWT and Unlinkability

[Kristina Yasuda <[e-mail]>]

> there is no guidance on how many to issue, nor how a holder chooses when
to reissue the same ones
> the question about users randomly selecting some to store and some to
reject.

These are great points, however, just like JWT/JWS specifications do not
define how to manage the lifecycle of those, SD-JWT document is not a right
place to discuss them. What you call a "hack" is not meant to be fully
specified in SD-JWT document itself. Please review documents such as
OpenID4VCI to improve various aspects of batch (re)issuance.

On another note, and not sure this was your original point, but I can
recall that originally, we had a text in the document that there are other
ways to achieve verifier/verifier unlinkability, other than batch issuance,
mainly using advanced cryptography (aka ZKPs). Then, upon receiving
feedback that such text is not really actionable or implementable, because
it was not well established how to use ZKP with SD-JWTs, we removed
sentences alluding to the mechanisms that are not batch issuance.
However, I think that might be changing, looking at the work cryptographers
at Google have been demonstrating recently. I think we are eagerly waiting
for that work to be published and peer reviewed.
To sum up, I think we could add back into the SD-JWT document a sentence
saying there are ways other than batch issuance to achieve
verifier-verifier unlinkability.

Best,
Kristina


On Sat, Sep 21, 2024 at 5:56 PM Dick Hardt <[e-mail]> wrote:

> I understand it has become the accepted approach. It still comes across as
> a hack, and there is no guidance on how many to issue, nor how a holder
> chooses when to reissue the same ones.
>
> I'm amused by the decision to use implicit typing in a disclosure to save
> a few bytes, but we will send dozens of credentials to minimize the chance
> of linking :)
>
> On Sat, Sep 21, 2024 at 4:29 PM Daniel Fett <[e-mail]> wrote:
>
>> Hi Dick,
>>
>> Batch credential (not claims) issuing has become the default approach to
>> circumvent the inherent limitations of salted-hash-based credentials
>> formats. This was neither invented by us, nor is it unreasonable to ask
>> implementers to do it. Protocols such as OpenID4VCI support it.
>>
>> -Daniel
>> Am 21.09.24 um 06:42 schrieb Dick Hardt:
>>
>> Is it really going to be practical to batch issue claims, and have the
>> holder randomly choose between them on presentation?
>>
>> As an implementer, what is the right number of claims to be in a batch?
>>
>> This section of the draft reads as a hack to add a new capability
>> (unlinkability) to a mechanism that did not have that as a design objective.
>>
>> This is going to be like the "alg":"null" for SD-JWT. :-)
>>
>>
>>