But is what they implement secure? We added lots of appendices to TLS 1.3 to help authors of under standards understand what they had to say to get a secure result.
Adding unactionable mitigations doesn't help anyone including the authors of the other documents you think will define this. On Tue, Sep 24, 2024, 2:19 AM Kristina Yasuda <yasudakrist...@gmail.com> wrote: > 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 <dick.ha...@gmail.com> 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 < >> yasudakrist...@gmail.com> 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 <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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
