And my point is that SD-JWT document is a wrong place to look for such actionable language. The intention is not and should not be to define a stand alone batch issuance protocol in SD-JWT document.
What we can do is to add a text saying more clearly that the details of batch issuance are defined elsewhere and what kind of details need to be defined in that document. Best, Kristina On Tue, Sep 24, 2024 at 9:22 AM Dick Hardt <dick.ha...@gmail.com> wrote: > My feedback is that the current language on batch issuance is not > actionable, and that this document should stand on its own > > If the reader is supposed to take guidance from other documents, then you > should refer to those other documents, but I would have that in addition to > specific guidance. > > On Mon, Sep 23, 2024 at 10:03 PM Kristina Yasuda <yasudakrist...@gmail.com> > wrote: > >> > 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
