Issuer identity in selective disclosure cases

[martinthomson]

The term "selective disclosure" covers a range of sins, but when it comes to use in the browser, the most interesting is perhaps the use of zero-knowledge proofs, which can provide strong unlinkability properties. Well... if certain conditions are met.

There are selective disclosure cases where verifier-verifier linkability is a near certainty because the bits of the signature are exposed. I can't conceive of any case where that makes sense to support on the web. Thankfully, obtaining fresh credentials from the issuer can avoid that problem in most cases.

However, verifier-issuer linkability is often a property of those same cases. This might be equally concerning and motivate the use of zero-knowledge proofs, which can provide verifier-issuer unlinkability.

However, there is still the question of the anonymity set size. Even in a zero-knowledge system, the information that is revealed (e.g., person is over 18, person has a given trait, etc...) is still present.

The revealed information generally has fairly obvious properties. Managing that risk is probably a user interaction question. "Do you want to give this website your passport details?" is a question with fairly obvious privacy implications relative to "do you want to reveal that you are licensed to drive?"

However, the present API shape also reveals the identity of the issuer. That's not strictly required, but it is how things work presently.

The fact that someone holds a credential from a particular issuer carries information in a far less obvious way. If there are many issuers, then it is possible that the choice of issuer could be more of a privacy risk than the information that is more directly revealed.

This is probably not something that people think about generally. Wallets generally don't hold a huge number of credentials or have a huge diversity of providers. But this is the web and there are lots of potential providers. If these credentials are going to be used for age verification, maybe it shouldn't be possible to learn where someone obtained the necessary certification.

[kdenhartog]

To add to this, in certain circumstances inferential information can be derived based on how issuance plays out.

For example, in the state of Iowa you can visit any of the 99 counties to renew a drivers license. If the digital equivalent of these are issued by each county rather than by the state a verifier would be able to infer more precise information about the approximate location of the user just based on the issuer. This is just one example where issuance of credentials can lead to further inference of information that can only be resolved via responsible coordination of issuers which is far more difficult in a distributed fashion. Furthermore, this is just a single credential type for a particular issuance model. It's highly unlikely that we'll be able to develop a set of heuristics to determine when emergent information can be inferred based on issuer in a generalized case.

[martinthomson]

Iowa is a big place, but even revealing that someone is likely from Iowa is more than is appropriate in the key cases we are talking about (fraud mitigation, age verification).

[jogu]

There is some text about this in the VCI privacy considerations: https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#name-identifying-the-credential- (we need to add a privacy considerations to the VP spec too, there's an issue open for that).

If these credentials are going to be used for age verification, maybe it shouldn't be possible to learn where someone obtained the necessary certification.

I think we need to be careful to not use overly generic terms - I am pretty sure that some age verification use cases legally require the verifier to know where the assertion about the age is coming from but it probably gets complex and I'm not sure what are good terms to use to describe the different use cases.

I think there's some relevant discussion here https://github.com/WICG/digital-credentials/issues/126 and there was talk about a presentation scheduling a presentation on a suggested way to do this with zero knowledge proofs on a future WICG call.

[Sakurann]

whether the issuer of the credential is revealed to the verifier or not (e.g. whether some kind of zero-knowledge mechanism is used) is at the credential format/securing layer, and not even protocol-on-top-of-this-API-layer. Is the proposal to allow only the credential formats with some kind of zero-knowledge mechanism (not sure it is possible, but trying to understand the goal/proposal in this issue)..?

[martinthomson]

My goal is to ensure that the browser has the means to distinguish between cases that might reveal more information than might seem obvious. That is, in the above example, revealing that someone has an Iowa drivers license when the goal is to prove that a certain age target is achieved.

Ultimately, I might even consider passing such a request to a wallet to be irresponsible, such that it might be best to block that sort of thing.

[jogu]

I think blocking requests at the browser level (except in a case of known bad behaviour by a verifier) would be a step too far, particularly if the user is giving informed consent. I would even go as far as saying that in an ecosystem where the wallet and verifier are sufficiently well regulated, it would be very wrong for the browser to start blocking requests.

Carving out certain very specific exceptions (e.g. where the user's age is really the only thing the verifier will end up needing to know about the user and there's a different easy way to achieve the age verification to a sufficient level of assurance for the use case) might be okay but may also be difficult for the browser to recognise.

[martinthomson]

"Informed consent" has become something of a harmful fiction: see https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4333743 for a pretty comprehensive dismantling of the notion as far as privacy goes. https://w3ctag.github.io/privacy-principles/ isn't bad either.

From my perspective, there is a substantive difference between how a wallet might operate on the web as opposed to other contexts. Not having the browser engaged, even if the process only involves "informed consent", would be dangerous. Though I would go further: there are some uses of identity that require different guardrails when engaging on the web. The expectations there are different than in other contexts.

If something is difficult for a browser to recognize, how is a non-technical person expected to make a good, "informed" decision?

[jogu]

If something is difficult for a browser to recognize, how is a non-technical person expected to make a good, "informed" decision?

To me, "Can a general purpose browser recognise now much information a verifier already holds about the user or will obtain in the near future and recognise whether a particular digital identity request might reveal unintended information about the user" is quite a different question from "does a user know their intent in interacting with a verifier and can a wallet regulated in that ecosystem correctly inform the user of what they're sharing".