Hello, Multiple issuers creating a single credential is not stock BBS, although I'm sure there is a paper out there somewhere on it.
It is possible to show a signature with a commited key (my SAC 2021 paper, or invoke SNARK but see the corrections that came out from other authors as well) and then show equality of commited values. This is orthogonal to the method of showing the commitment is in the credential. However, these methods have all the same drawbacks you mention for BBS. if you're suggesting showing in the clear the TEE identity key, then we need frequent reissuance to preserve unlinkability. This has availability impacts. Furthemore issuer-holder matters. Sincerely, Watson On Mon, Sep 23, 2024 at 12:02 AM Denis <denis.i...@free.fr> wrote: > > 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 <m...@danielfett.de> 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 -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
