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 <[email protected]> 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 [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
