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

[Watson Ladd <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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 <
>> [e-mail]> 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 <[e-mail]> 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 <
>>>> [e-mail]> 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 <[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. :-)
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>