Pairwise DIDs and Verifiable Credentials

[davebryson]

Using this image: https://identity.foundation/peer-did-method-spec/#privacy-considerations What if Alice has a credential issued to her from the Government, that she'd like to use to prove something to her Bank connection? This won't work as each connection is bound to a different pairwise DID. Does this limit the use of Peer DIDs?

[dhh1128]

No.

Strategy 1 The verifiable presentation can be signed by both pairwise DIDs belonging to Alice (or, over DIDComm, the message will be encrypted with A.did@A:Bank, but signed by A.did@A:Gvt. This establishes the fact that they have a common controller.

Strategy 2 Alice gets the Gvt to issue to a A.did@A:Any instead of A.did@A:Gvt. Essentially this is strategy 1, except done at issuance time instead of verification time.

Strategy 3 In ZKP-land, the DID of the prover is irrelevant and is expected to vary in this way. You bind using the link secret (and possibly to other stuff like a biometric), not the DID.

[davebryson]

Thanks. The downside I can see to 1) is that it reveals your other DIDs, but maybe that's not an issue.
It may be beneficial for the spec to have some simple examples for this.

[mskd12]

It seems to me like Strategy 1 breaks privacy offered by the pairwise-ness as the Bank can link the two pairwise DIDs of Alice (Govt, Bank). Isn't one of the main point of peer DIDs to avoid this privacy leak?

[dhh1128]

@mskd12 , you are correct that Strategy 1 degrades privacy. I wouldn't advocate it as a general approach, for exactly this reason -- but it is always available in specific circumstances when needed and when privacy is negotiable.

I am mostly focused on Strategy 3.

I think most who don't use 3 will use 2 (which doesn't use peer DIDs, and which also has the privacy/correlation problem you've noted).

There is a 4th strategy, which is to prove the binding between the holder/prover and the credential using neither a link secret nor a controlled DID. This can be done with biometrics, for example, and there are several approaches to it that preserve privacy in various ways. See this doc for details.

[mskd12]

@dhh1128, thanks for the answer!

A followup question: do strategies 3, 4 essentially involve the use of anonymous credentials (e.g., CL signatures)? It'd be great if you can point me towards any spec / documentation laying out the current thinking with regards to the use of ZKPs (strategy 3 in particular).

[dhh1128]

@mskd12 , they involve ZKPs in one form or another. Anonymous credentials are the incarnation that I've worked on the most (and the only one that's shipping in production). You can see the low-level cryptographic implementation in Hyperledger Ursa, and a higher-level c-callable library with wrappers for Java, Node.js, python, and similar in Indy-SDK, but there are a couple alternative proposals now. One is from Mattr; the other is a recent announcement of work by Microsoft Research.

The general thinking about ZKPs and credentials (which would apply to all the approaches listed above) is perhaps best documented in a webinar that I gave. You may be able to skip parts of it that you already know. Here's a link and a rough table of contents:

https://youtu.be/bnbNtjsKb4k

section 1 (definition of ZKPs; clearing up some misconceptions about them) section 2 (ZKPs vs. ZKP-oriented creds) -- 21:20 section 3 (goals of ZKP-oriented creds) -- 25:07 section 4 (relationship to link secrets) -- 51:50 section 5 (where ZKPs don't make sense) -- 1:26:20