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

[Denis <[e-mail]>]

Hi Kristina,

Today, most people have in mind the Issuer-Holder-Verifier model. Other 
use cases are hypothetic at the moment.

This document includes a privacy considerations section (section 11) and 
the guidance given in that section
about verifier-verifier unlinkability looks appropriate on pages 47 and 48.

You wrote:

    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.

Indeed, ZKP such as BBS or BBS+ could be used but the performances of 
such algorithms are rather poor
and their inconvenients are rather important. ZKP should not be 
recommended at this point of time.
Batch issuance of digital credentials is a much more practical solution.

However, one advantage of BBS and BBS+ is their ability to link digital 
credentials issued by different Issuers.
This topic is not currently addressed in the document because the base 
mechanism does not support it.

On September 23, I sent an email to the mailing list with the following 
topic:

    How to get the benefits of BBS+, without its drawbacks while using
    conventional cryptography ? (Was SD-JWT and Unlinkability)

This characteristic can be achieved using traditional cryptography *if 
and only if* that cryptography is supported by a specific
Holder hardware/software configuration as well as by specific protocols. 
Such guidance should be added into the Security Considerations section.

On September 18, I sent an email to the mailing list with the following 
topic:

    Re: WGLC for SD-JWT

At this time, I got no replies from the editors.

Denis

> 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-JWTdocument 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 [e-mail]