See my points (2) and (3) in my reply to this type of suggestion on the larger original thread: https://mailarchive.ietf.org/arch/msg/jose/wxlAl9zc03HTWYptQChdO1-KBRE/
Other points were made on that thread also. The approach you're suggesting also does not support building ZK-based predicate proofs which many of us believe are an important foundational piece of privacy technology we want to support the adoption of. Jer On Thu, Jul 28, 2022 at 3:40 PM Richard Barnes <[email protected]> wrote: > Trying to collect some of the "couldn't you just" threads from the JWP > thread into a semi-coherent straw-man. > > First, I claim that it is straightforward to implement token issuance and > presentation where the presentations are (a) linkable, (b) holder-bound, > and (c) allow selective disclosure. For example, one could use the draft > OpenID spec for issuing Verifiable Credentials [1], with "did:key" subjects > for holder binding [2] and something like SD-JWT for selective disclosure > [3]. For presentation with selective disclosure, you just present the > credential and PoP, together with whichever claims you want to expose. > > Supposing such a system exists, consider the following scheme: > > 1. At issuance time, the holder executes the issuance protocol N times, > each time with a fresh random subject key pair and fresh blinding of the > selective disclosable claims. > 2. As a result, the holder obtains N credentials with different subject > public keys and different signatures > 3. The holder presents each credential exactly once > 4. The holder goes back to step (1) when they need a new pile of > credentials > > It seems like this trivial scheme meets most of the requirements I've seen > expressed so far: > > * The credentials are not linkable with each other by the verifier(s) to > whom they are presented > * The issuer doesn't know anything about the verifier > * The issuer doesn't have to be online at redemption time > > The things I suspect some people will object to are (a) that the issuer > can link all the credentials, and (b) that the issuer and the verifier see > the same object. But I'm not sure I've seen it clearly expressed why these > would be a problem. (And to the degree they are, cf. PrivacyPass [4].) > > Anyway, it seems like the above system achieves the stated goals of > unlinkability and selective disclosure, with no fancy cryptography or new > JSON structs required aside from the SD stuff. What critical requirement > is this missing that would motivate a significant new engineering effort? > > Thanks, > --Richard > > [1] > https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html# > [2] https://w3c-ccg.github.io/did-method-key/ > [3] > https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/ > [4] https://datatracker.ietf.org/wg/privacypass/ > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
