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

[Denis <[e-mail]>]

Batches of digital credentials prevent collaborating Verifiers to link 
accesses from the same End-User.

However, there is another advantage which would be worthwhile to 
mention: getting the benefits of BBS+ ... without its drawbacks
(poor performances, large key sizes, large memory sizes, high 
computational power required, not "green" and not resistant to quantum 
attacks).

There exist use cases where claims contained in digital credentials 
issued by different Issuers need to be presented to one Verifier.

Using BBS +, when a Holder requests a digital credential to several 
digital credential issuers, for each request, it uses a different 
blinded link secret
and hence each issued digital credential will contain a different 
blinded link secret. This value does not allow anybody to correlate 
digital credentials
issued by different digital credential issuers for the same Holder.

An important benefit of the use of link secrets is the ability for a 
Holder to demonstrate to a Verifier that credentials issued by different 
digital credential issuers
were indeed issued to the same Holder.

When using the "traditional SD-JWT" model, the Holder generates one key 
pair for each Issuer. In this way, a digital credential issued by the 
Issuer A
cannot be linked between collaborative Verifiers to a digital credential 
issued by the Issuer B. So far, so good.

Now, let us suppose that Issuer A is a government, while Issuer B is a 
University. An End-User would like to demonstrate to a Verifier
that that he lives in California and that he got one diploma (among 
several) from the University.

For that specific use case, the Holder will generate one new key pair 
and use the same private key to request a digital credential from each 
Issuer.
The two issued digital credentials will contain the same public key and, 
using the corresponding private key, the Holder will be able to demonstrate
to one Verifier that the two presentations of the digital credentials 
originate from the same Holder.

Since that key pair will only be used once towards a single Verifier, a 
linkage between different collaborative Verifiers using the framing of 
the claims is not possible.

This means that you can have your cake and it eat !

Obviously, this means that the key pair SHALL be generated by a TA 
running in a TEE that is part of the Holder (application).
Both Issuers and Verifiers MUST be able to know these characteristics. 
See one of my earlier comments:

    The key pair SHALL be generated by a secure cryptographic
    application that is part of the Holder and the characteristics
    of that application SHALL be included in SD-JWT using the claim
    "scac" (secure cryptographic application characteristics).

Section 5.1.2 (Key Binding) currently states:

    It is out of the scope of this document to describe how the Holder 
key pair is established.

This section should be reconsidered and rewritten.

Denis

> 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]