Does pseudo-anonymity require the issuer to cooperate?

[stonematt]

This question came up in our use cases call in issue w3c/vc-use-cases#10

How explicit should we be in the DM about issuer’s role in creating ZKP credentials for things like withholding “name” as discussed in the use cases section 3.5.
https://w3c.github.io/vc-use-cases/#professional-credentials -- see the Paula example in item C.5 Social authority.

in other words, can I say “I’m in control of credential X in which I’m the subject, but you can’t know who I really am”

[stevenrowat]

I'm uncertain exactly what is being suggested here. Perhaps an example will help?

Suppose I want to publish a story about Country X, of which I'm a citizen, and state in the story that I'm a citizen, backed up by a VC corroborating this, but also use a pseudonym to avoid dangerous repercussions on me and my family.

But the problem is that Country X is the place that would issue my VC stating that I'm a citizen, and would be the issuer, and would be required to back up the VC at the DID level. So the question is:
Do they have to agree that I can publish pseudonymously? Or is there a way that I can do it anyway, using Zero Knowledge Proofs, and even the government of Country X won't know who they've corroborated in the VC?

Is that what you're asking?

If so, interesting question, and I don't know the answer, but I hope somebody does.

[dlongley]

Or is there a way that I can do it anyway, using Zero Knowledge Proofs, and even the government of Country X won't know who they've corroborated in the VC?

I think that if the government really wants to know then they will know. They can choose a scheme that allows them to know or employ sufficient resources to track usage via some side channel data.

For example, the ZKP schemes I've seen require a public key from the issuer. If the issuer uses a different public key for every credential they issue then they can track when the public key is retrieved or, if they can't easily do that, they can collude with (or "persuade") the verifier to learn when the credential is used (particularly if this is all happening in the same country).

[jandrieu]

It will be relatively trivial for an issuer to construct even ZKP proofs that support third party correlation, even accidentally. For instance, you can have a ZKP that proves your driver's license # without revealing date of birth or address. It's a fine use of ZKP if you care about rental companies getting unnecessary PII, but it doesn't do anything to help with correlating you across rental establishments via your driver's license #.

To make things worse, even with good, well-intentioned data modeling practices, there are often plenty of ways to de-anonymize ZKP credentials. Consider it a corollary of the law of unintended consequences. You only have to mess up once for links to be made.

The best anti-censorship techniques mean not only diligent data modeling (which is under the issuer's control) but also judicious use of those credentials and affiliated data and meta-data. Ultimately, it's an economic question of how much trouble it is worth it to support a certain level of anonymity (both for holders and issuers) versus the economic cost and value for third-parties wishing to de-anonymize. If you're the target of a billion dollar manhunt (think Osama Bin Laden), then ZKP VCs are only a small part of your challenge. If you want to pseudonymously post to Post Secret about childhood trauma and want a ZKP proving you were on the Valley High School soccer team in 2018, the economics are substantially different.

[stevenrowat]

If you're the target of a billion dollar manhunt (think Osama Bin Laden), then ZKP VCs are only a small part of your challenge. If you want to pseudonymously post to Post Secret about childhood trauma and want a ZKP proving you were on the Valley High School soccer team in 2018, the economics are substantially different.

So, to my understanding so far, it's a continuum in which the bulk of small- and medium-scale uses, about specific incidents or people, won't be worth going after.

This would imply, I think, to the OP (stonematt) question, that the answer is, yes, there will be a large number of places for it to be provided by the issuer, and it should be included in the Data Model as a possibility, explicitly. Though probably it will be optional and up to a specific DID Method to implement this.

Does this seem correct?

It also, to my mind, is interesting to talk about the middle-range cases on the continuum, where it's a complicated judgement call how to proceed (for both the issuer and the subject/holder). I've thought of one:

Pseudo-anonymity credentials for nationally-accedited doctor criticising their own State specialty.

Background:
Doctor X holds a valid M.D., recognized by the American Medical Association.
Doctor X also holds a specialist degree in her home state, Ohio, for pediatrics, which is issued by the Ohio Pediatrics State Examining Board (OPSEB).
Doctor X has learned of several unfortunate and shady connections between other members of her specialty in Ohio and pharmaceutical manufacturer Q.

Problem:
Doctor X wishes to publish some of what she knows, without naming any names but making it clear that there's a problem between her Ohio pediatric specialty and manufacturer Q. She decides to publish a summary of the situation, pesudonymously, but with a VC establishing herself as an expert in the field.

Depending on ZKPs and DIDs, it seems she could post pseudonymously, and:
A. Merely identify herself as an M.D. (VC from the A.M.A.)
B. Identify herself as an M.D. (A.M.A) and a member of "some state" pediatrics specialty (VC from OPSEB, without state being named)
C. Identify herself as an M.D. (A.M.A.) and a member of the Ohio pediatrics specialty (VC from OPSEB).

Which of these options she would choose to do would perhaps depend on the continuum of how easy pseudo-anonymity is to track. That is, "A" might be the safest, since presumably the A.M.A. would be supportive since she's tracking down corruption in a local specialty. "C" might be the most dangerous, since the OPSEB might contain people who are vidictive or comprominsed, who wish to track her down. However, it might be that all these options are safe, if it's so difficult to track pseudo-anonymity that neither the A.M.A. nor the OPSEB would engage in it. (Plus, if they did and were caught, it would be extremely embarrassing for them, which is another factor).

It occurs to me that perhaps this could be included as a DID use case, if it covers something that isn't already in the use cases.

Opinions?

[stonematt]

I think the answer to this is yes - the issuer will issue a VC that supports ZKP. The holder will not have the authority or capability to decompose and share discreet attributes of a claim unless the issuer enables that. If that's the case, we can close this issue.

[stevenrowat]

I think the answer to this is yes - the issuer will issue a VC that supports ZKP. The holder will not have the authority or capability to decompose and share discreet attributes of a claim unless the issuer enables that.

Does this mean that a holder can't use their citizenship in Nation X pseudonymously unless Nation X has previously deemed ZKPs OK? Similarly, in the case of the State Medical Board example, Doctor X can't claim membership in the Medical Board via a VC, yet make a pseudonymous statement, unless the State Medical Board has previously OK's such ZKP VCs? And so on, for all issuers?

This may be the best solution available, but it does seem to make it difficult on whistleblowers in particular.

OTOH, I can see that many issuers will refuse to issue a VC at all if they think it might be used pseudonymously. Seems like a thorny problem.

[TzviyaSiegman]

This is related to a concern I have about section 10.8 Principle of Minimum Disclosure. I believe that it is easy to misunderstand the DM with the misconception that minimum disclosure is the default and/or controllable by the subject. I think it would be a good idea to spell out more explicitly what steps need to be taken (e.g. ZKP, hashing hashed credentials) to make mimimum disclosure possible.

[ChristopherA]

@TzviyaSiegman > I think it would be a good idea to spell out more explicitly what steps need to be taken

+1

I think there are a number of interesting scenarios here around Minimum Disclosure, that are completely separate from cryptographic selective disclosure/attribute blinding/zkp and anti-correlation capabilities, and should be.

You note "the misconception that minimum disclosure is the default and/or controllable by the subject" — I've run into this too. The subject who is also holding the claim should be able to minimize sending it in some way, both automated under some type of algorithm or interactive protocol, but and also under direct user control. If you are a holder /= subject, you should be held to a high standard. And there are things that issuers can/should/must do as well to help subjects and holders to be able to minimize their disclosure.

[kdenhartog]

This was discussed in the maintenance working group. @brentzundel believes he can write up a PR to address this one.

[iherman]

The issue was discussed in a meeting on 2021-06-14

• no resolutions were taken

View the transcript

3.5. Does pseudo-anonymity require the issuer to cooperate

See github issue #209.

Gerhard Oosthuizen: Hi everyone. Unfortunately have to drop off. Nice meeting you. Will do some pre-reading of issues before our next session to be able to contribute more.

Kyle Den Hartog: +1 to that Brent

Manu Sporny: Agree with that text that brent just said

Brent Zundel: it would be appropriate to add text to the Zero Knowledge proofs section

David Chadwick: maybe the scope of this issue is larger, to what extent can an issuer control the discloser a holder has

Brent Zundel: assign brent to the issue, an idea of how to move forward with it

Manu Sporny: agreed with the original text - but consider one use case: witness issuers

Manu Sporny: +1 to giving brent a shot at the text :)

Gregory Natran: in response to DavidC, caution to preventing users from disclosing, the information is theirs and there may be consequent issues with restrictions on the holder/subject

Brent Zundel: to throw conversation into a new PR and can continue the discussion
… anything that is not "deferv2" or "erratum" - please add a comment to the issue to describe what you feel the proper classification should be

[iherman]

The issue was discussed in a meeting on 2021-10-06

• no resolutions were taken

View the transcript

3.1. Does pseudo-anonymity require the issuer to cooperate? (issue vc-data-model#209)

See github issue vc-data-model#209.

Brent Zundel: I vaguely remember this conversation... several years ago. We talked about it a few months ago
… At the time I was confident I could write a PR to address this, but now reviewing it I no longer recall...

Kyle Den Hartog: ... We left it more vague... questions about pseudonymity... a cover clause to abstract around ZKPs...
… that the issuer must give you something you can derive from

Dave Longley: I think that is good and helpful... Letting people reading the spec know that if the issuer is not cooperating to do this, then you don't get it.
… The issuer has to offer you this feature, and not try to backdoor recreate correlation or collision
… The notion is that there is some trust in the issuer to cooperate in this scheme for it to work.

Kyle Den Hartog: This is the statement in the spec, that I think generally covers this: "The verifiable credential MUST contain a Proof, using the proof property, so that the holder can derive a verifiable presentation that reveals only the information than the holder intends to reveal."

Dave Longley: I think this should be stated in the spec

Ted Thibodeau Jr.: I recall the issue was about active participation by the issuer, rather than about making a derived credential of a credential one has in their hand

Dave Longley: One attack: even if the issuer is following these protocols... if the issuer is creating a different public key for every user they issue a credential to, they re-introduce a way to correlate and track users.
… Issuer should opt in, and must also decide not to track you

Kyle Den Hartog: I see that, think it could be added to the privacy section, not tie specifically to ZKPs only
… There are other ways an issuer could create pseudonymity... active issuer policies

Dave Longley: thanks brent

Ted Thibodeau Jr.: +1 kdenhartog's described editorial addition, whether done by kdenhartog or brent

Brent Zundel: I'll put a PR in, and we'll see if it's acceptable

[iherman]

The issue was discussed in a meeting on 2021-11-10

• no resolutions were taken

View the transcript

5.1. Does pseudo-anonymity require the issuer to cooperate? (issue vc-data-model#209)

See github issue vc-data-model#209.

Brent Zundel: related to PR #830.

See github pull request vc-data-model#830.

Brent Zundel: pr exists for this issue so it will automatically close when pr is merged.

[iherman]

The issue was discussed in a meeting on 2021-12-01

• no resolutions were taken

View the transcript

4.5. Does pseudo-anonymity require the issuer to cooperate? (issue vc-data-model#209)

See github issue vc-data-model#209.

See github pull request vc-data-model#830.

Brent Zundel: I raised a PR to address this, got some feedback, that PR has existed for 21 days, but not labeled properly -- waiting for PR to formally be accepted..
… Last thing I think Ted made, requested some changes, accepted your suggestions -- re-review would be good..

Ted Thibodeau Jr.: I'll look at that..