Add Privacy Considerations section on "Unnecessary Correlation". #160
Conversation
msporny
requested review from
npdoty,
dlongley,
jandrieu,
longpd,
iherman,
dmitrizagidulin,
TallTed,
David-Chadwick,
simoneonofri,
decentralgabe,
brentzundel and
KDean-GS1
|
|
||
| <p> | ||
| When these global identifiers are used in [=presentations=] that utilize | ||
| [=selective disclosure=] or [=unlinkable disclosure=], they can violate privacy |
There was a problem hiding this comment.
It seems that respec cannot locate the [=unlinkable disclosure=] term. This should be handled
There was a problem hiding this comment.
I added a terminology placeholder in the VCDM spec yesterday so that we can refer to it (since that spec has had the concept of unlinkable disclosure since v1.0). It takes 6 hours for the terminology database to update after the TR spec is published.
It looks like, since yesterday, the terminology database successfully updated and the link works now: https://www.w3.org/TR/vc-data-model-2.0/#dfn-unlinkable-disclosure
I tried to pick something uncontroversial for the definition (that was based on the existing text in the specification).; I expect that we'll want to bikeshed the definition in VCDM v2, which would be a purely editorial change.
index.html
Outdated
| <p> | ||
| In some cases, when [=presenting=] a [=verifiable credential=] that contains | ||
| other global identifiers (such as a driver's license identification number), | ||
| using other global identifiers for the status list information does not cause |
There was a problem hiding this comment.
| using other global identifiers for the status list information does not cause | |
| then using other global identifiers for the status list information does not cause |
index.html
Outdated
| </p> | ||
|
|
||
| <p> | ||
| For more information on other types of correlation that is possible, |
There was a problem hiding this comment.
| For more information on other types of correlation that is possible, | |
| For more information on other types of correlation that are possible, |
index.html
Outdated
| require them to know the current status of a credential, and the holder might | ||
| then consent to revealing that information or might refuse to do so for a given | ||
| transaction. In all cases, both [=issuers=] and [=verifiers=] are urged to | ||
| ensure that the use of global identifiers is avoided when a particular exchange |
There was a problem hiding this comment.
Issuers cannot know what exchanges a holder might participate in, in future, and therefore this sentence does not make sense
There was a problem hiding this comment.
It makes sense with respect to modeling and securing mechanism considerations. Issuers should choose VC models that omit global identifiers when possible or enable selective disclosure of them. In short, issuers have to issue VCs that support selective disclosure in order for holders to be able to make use of them.
There was a problem hiding this comment.
@dlongley Whilst your comment makes sense, it does not change the sentence that does not make sense with respect to the issuer.
There was a problem hiding this comment.
suggest change
| ensure that the use of global identifiers is avoided when a particular exchange | |
| ensure that the use of global identifiers is avoided. |
index.html
Outdated
| require them to know the current status of a credential, and the holder might | ||
| then consent to revealing that information or might refuse to do so for a given | ||
| transaction. In all cases, both [=issuers=] and [=verifiers=] are urged to | ||
| ensure that the use of global identifiers is avoided when a particular exchange |
There was a problem hiding this comment.
| ensure that the use of global identifiers is avoided when a particular exchange | |
| ensure that the use of global identifiers is avoided |
index.html
Outdated
| then consent to revealing that information or might refuse to do so for a given | ||
| transaction. In all cases, both [=issuers=] and [=verifiers=] are urged to | ||
| ensure that the use of global identifiers is avoided when a particular exchange | ||
| does not require correlation. |
There was a problem hiding this comment.
| does not require correlation. | |
| in order to prevent correlation. |
index.html
Outdated
| require them to know the current status of a credential, and the holder might | ||
| then consent to revealing that information or might refuse to do so for a given | ||
| transaction. In all cases, both [=issuers=] and [=verifiers=] are urged to | ||
| ensure that the use of global identifiers is avoided when a particular exchange |
There was a problem hiding this comment.
I'd suggest this instead:
| ensure that the use of global identifiers is avoided when a particular exchange | |
| ensure that the use of global identifiers can be avoided when a particular exchange |
I think this should cover "enabling" holders to make the selective disclosure choices they'd prefer to make when future exchanges arise where the global identifiers don't need to be disclosed.
There was a problem hiding this comment.
The text that I object to is
In all cases, .. [=issuers=] .. are urged to
ensure that the use of global identifiers is avoided when a particular exchange
does not require correlation.
the reason being that issuers do not know what exchanges the holder may participate in, and therefore which might or might not require correlation
There was a problem hiding this comment.
If an issuer is providing a selectively disclosable VC, they don't need to know how the holder might use it. The verifier knows what information they need and they will ask for it. It's up to the holder to provide that information or refuse to provide it, based on a use-case-by-use-case or per-transaction basis.
We can use a layered approach here by telling the issuer that:
- By default, make everything selectively disclosable if they're supporting selective disclosure. This helps the holder maximize their privacy by making /everything/ selectively disclosable by default.
- If they so choose, the issuer can (on top of the default guidance) make a determinination that, under no circumstance, do they ever want fields X, Y, and Z selectively disclosable.
None of that requires the issuer to know how the holder might use the VC.
/cc @npdoty and @kdenhartog to get their thoughts on this general guidance for selective disclosure. If this sticks, we'll want to move it into the VCDM. In fact, a lot of this guidance we're giving in the BBS Cryptosuite and the Bitstring Status List specs belongs in the VCDM.
There was a problem hiding this comment.
Whilst I agree with what you say above, the sentence I object to does not reflect this. So can we edit the sentence please so that it does reflect this e.g.
In all cases, [=verifiers=] are urged to
ensure that the use of global identifiers is avoided when a particular exchange
does not require correlation. Similarly [=issuers=] that support selective disclosure
should make everything selectively disclosable by default in order to help the holder
maximize their privacy in future exchanges.
Please edit the above as you wish
|
The issue was discussed in a meeting on 2024-04-03
View the transcript3.2. Add Privacy Considerations section on "Unnecessary Correlation". (pr vc-bitstring-status-list#160)See github pull request vc-bitstring-status-list#160. Manu Sporny: The other one is a general heads up that there are PRs that are being raised both in the BBS crypto suite and the Bitstring status list for preventing unnecessary correlation. Gabe Cohen: Manu, would you like to open an issue and tag VC-JOSE-COSE editors to sync up on language. Manu Sporny: I think that'll happen automatically when we raise the PR. So I think we can go straight there. |
Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
Editorial, multiple reviews, changes requested and made, no objections, merging. |
This PR is an attempt to address issue #142 and #147 by providing some guidance on when it's appropriate to use status lists that contain globally unique identifiers and when status lists should be selectively disclosable.
/cc @zoracon
Preview | Diff