> 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 <dick.ha...@gmail.com> 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 <m...@danielfett.de> 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. :-) >> >> >>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
