Address Metadata-Driven Correlation

[awoie]

From PING review w3cping/privacy-request#121 (comment):

Chosen profiles of claims format, claims semantics, proof format, or various other metadata defined as extension points like in section 5 can act as a mechanism to fingerprint the holder in a way that can reduce the K-anonymity even when selective disclosure mechanisms are used. Let's say a signature scheme or language used in claims is specific to a particular region but no location information is provided. Then it's possible for a verifier to infer the location of the subject not only based on who the issuer is, but also based on the selected format chosen by the issuer and/or holder for verifiable presentation generation. The Verifiable credential specification should encourage the reuse of common claims and proofs formats in order to reduce this metadata as a vector of correlation. This can either be highlighted via section 7.13, but would likely be better highlighted as an additional subsection of section 7.

[iherman]

The issue was discussed in a meeting on 2023-08-23

• no resolutions were taken

View the transcript

3.6. Address Metadata-Driven Correlation (issue vc-data-model#1244)

See github issue vc-data-model#1244.

Manu Sporny: I don't know what normative language we could add to address the issue.
… I think it's good advice, but I don't think a normative statement is appropriate.

Ted Thibodeau Jr.: Privacy considerations aren't necessarily about normative language. They're considerations.

griffin-again-again: griffin-again-again has joined #vcwg.

[iherman]

The issue was discussed in a meeting on 2023-09-15

• no resolutions were taken

View the transcript

3.5. Address Metadata-Driven Correlation (issue vc-data-model#1244)

See github issue vc-data-model#1244.

Brent Zundel: This is another type of variation on previous issue... don't know if path forward on this is much different from what we just talked about. Happy to hear thoughts from group on this item.

Nick Doty: When we have non-essential properties that can vary, if we have recommended set of thoe properties, everyone can follow them, users can be in single anonymity set -- do you need variation in these things, or can there be recommendation of "everyonen that does credential in this style, use these parameters"?

Kristina Yasuda: Yes, not sure I agree, don't know how realistic this is -- even if federated identity, information about user can be in SAML assertion, and each representation can be a standard, but we can't force everyone to use same VC to do the same thing -- unfortunately, there are disputes on how to express credential at multiple levels -- how is plain text about user claims being represented, what cryptsuites are used, at every level there are almost religious debates on what the best way to do this, don't want to touch this.

Brent Zundel: With the VC model, and notion of selective disclosure on presentation, every issued VC is ideally following -- for example DL, on issuance side, we have commonality on structure and data provided. Requring presentation of subset of credential even on metadata part of it other than few that we've already agreed to. I'm not sure what we can do about this issue.

Manu Sporny: this one's tricky. I think what Nick is asking for: ina perfect world we could establish best practices for certain credentials. e.g., an age verification credential should have a correlatable issuer and should only express a large bucket age range.
… and the WG could work to create an age-verification credential template with that information. We're not chartered for that yet, so we will need to use security and privacy condsiderations sections. We do have a sections that strongly encourages data minimization, i.e., selective disclosure.

Joe Andrieu: The model for validation in VCs does require issuer to be correlatable to see if particular identifier is someone they should trust -- if I want to see if someone can drive, I can't take self-issued VC -- that's something that's baked into the model, we can't get past that part of correlation.

Nick Doty: This is helpful, the verifier only has some list of people that they trust in order for system to be functional, understood.

Joe Andrieu: +1 to group mechanisms to mitigate correlation of issuers.

Nick Doty: We can say if you can "group" that trust in some way, that can help user in some way -- so issuer corelation dosn't happen. About formats, if you're going to try to group issuers, you could group these other things -- that should be the recommendation, grouup issuers, but also focus on grouping attributes -- unify formats so you can't track it back to original issuer.

Kristina Yasuda: what we have put in SD-JWT and have received positive feedback "To mitigate this issue, a group of issuers may elect to use a common Issuer identifier.".

Brent Zundel: that's helpful, we have good path forward.

Kristina Yasuda: We've written something similar for SD-JWT, but can't do that tomorrow, can eventually do that.

Brent Zundel: ok, assigning kristina.

[iherman]

The issue was discussed in a meeting on 2023-09-26

• no resolutions were taken

View the transcript

2.4. Address Metadata-Driven Correlation (issue vc-data-model#1244)

See github issue vc-data-model#1244.

Kristina Yasuda: So this one, I was about to do the PR today, should be marked ready for PR. This one is fine.

[iherman]

The issue was discussed in a meeting on 2023-11-15

• no resolutions were taken

View the transcript

3.2. Address Metadata-Driven Correlation (issue vc-data-model#1244)

See github issue vc-data-model#1244.

Brent Zundel: Who can take this work?

Sebastian Crane: I think these ones from the PING review seem to be very similar and I think they should be addressed in a cohesive manner. In the security world one often has faux attacks to gauge the security of a system. Privacy can be different, especially because of aggregate data concerns. Having some kind of mock attack would be good for showing correlating data issues, but the full extent won't be known until production.
… Lots of academic papers about correlating data and we could apply the work here.

[msporny]

PR #1355 has been raised to address this issue. This issue will be closed once PR #1355 has been merged.

[msporny]

PR #1355 has been merged, closing.