On Sun, Oct 16, 2022 at 6:01 PM Tobias Looker <[email protected]> wrote:
> > The verifier of a VC needs to know that the entity presenting the > credential is the same as the subject that the issuer issued the credential > to. Can you provide an example of how the verifier is assured of that > without revealing a public key or a DID or some constant, correlatable > identifier? Specifically: > > To the contrary can you expand on how revealing a DID or public key to the > verifier alone provides this assurance? > If the DID or public key is constant for a given signature, and I reveal that to two verifiers, that seems like it allows the verifiers to link the credentials pretty trivially, right? Just by checking that the same DID or the same public key was presented in two interactions. And this is true even if the signature on the credential is different in the two interactions. In other words, suppose the VC signature covers (attributes, DID/Pubkey); then two presentation interactions would present: A: subset(attributes), DID/Pubkey, ZKP1 of signature over (attributes, DID/Pubkey), proof of possession of DID/Pubkey B: subset(attributes), DID/Pubkey, ZKP2 of signature over (attributes, DID/Pubkey), proof of possession of DID/Pubkey It seems to me that all of the elements in those presentations can vary **except for the DID/Pubkey**. Because that's how the subject is represented, so it can't vary between issuance and presentation. And because you have that constant correlator, the interactions are linkable, even though everything else is randomized. (You could do something like having a bucket of DIDs/Pubkeys that are selectively disclosed in different interactions. But this doesn't help: You only get a fixed number per credential, and you have to burn one per presentation, so you eventually have to go back to the issuer and refresh. And has been discussed elsewhere on this list, if you can go back to the issuer and refresh, you don't need the fancy ZKP signatures.) --RLB
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
