SD-JWT document has a clearly defined scope and one can implement “something useful”that is meant to be in scope by reading only SD-JWT document.
Also please see my other response about SD-JWT not being meant only for issuer-holder-verifier model. There might be usages of SD-JWT outside that model that do not need batch issuance. Like, theoretically, using sd-JWT as a content of an access token for whatever reason. Once again, “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”. On Tue, Sep 24, 2024 at 11:10 AM Dick Hardt <[email protected]> wrote: > I understood your point. :) > > As a reader, I had no idea I was supposed to look elsewhere for guidance > on either unlinkability, explicit typing, or decoy digests. > > My other point is the document should stand on its own and not require > other documents to do something useful. > > On Tue, Sep 24, 2024 at 10:01 AM Kristina Yasuda <[email protected]> > wrote: > >> 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 <[email protected]> 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 < >>> [email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 -- [email protected] To unsubscribe send an email to [email protected]
