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

[Dick Hardt <[e-mail]>]

Where is the guidance going to live for the issuer and holder for batch
issuance?

Just as there is guidance on salt entropy, digest algorithms etc. I suggest
it be clear to implementers what the best practice is.

For example, is each credential one time use? Does the holder need to track
which verifiers received which credentials?

The objective is defeated if the same verifier receives all the different
credentials. A likely situation where the user regularly uses a credential
for access.

As mentioned in another thread, I consider batch issuance a hack, and that
it will likely be defeated *if* there is value to an attacker in
correlating the user across apps.

/Dick

On Tue, Sep 24, 2024 at 12:07 PM Daniel Fett <mail=
[e-mail]> wrote:

> A few points:
>
> * Batch credential issuing is completely transparent to the user.
>
> * The selection is done by the Wallet, before presentation.
>
> * It doesn't need to be random, the Wallet can just select the next
> credential.
>
> -Daniel
> Am 21.09.24 um 17:53 schrieb Tom Jones:
>
> that doesn't answer the question about users randomly selecting some to
> store and some to reject.  This seems to me like user private information.
> As is most of the feedback to the issuer from the wallet.
> Peace ..tom jones
>
>
> On Sat, Sep 21, 2024 at 7:30 AM Daniel Fett <mail=
> [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]
>>
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>