WICG
Prevent increased centralization of trust via strict Verifier requirements when presenting a credential
As noted in our formal objection, we're concerned that the the introduction of digital credentials on the Web will increase the centralization of trust on the web. Here's the initial concern:
Increased centralization through subtle tradeoffs
On the topic of centralization, since most of these systems are built around the “digitization of trust, the approach most commonly used is to effectively digitize the trust we have in institutions and map that onto the Web. For example, the concept of a proof of personhood credential would not be trusted if it can be only self-attested. Instead, that proof is considered trusted only if it comes from a known and trusted third-party issuer. The implication of “digitization of trust” is it will lead to further centralization on the Web, just as we’ve seen with similar centralization of single sign-on systems (a limited number of providers handling the majority of use cases). This begs the question: what additional harms arise from these tradeoffs of centralizing trust in a limited number of institutions? Is further centralization of trust a net gain for the Web?
Additional centralization is also likely to occur due to the “trust” needed around wallets, as users may modify or share their credentials in a way that undermines the trust of the system. For example, if a user were to share their credential and keys (or have them stolen) then it would allow someone other than the subject of the digital credential to present it, thereby leading to impersonation attacks. The commonly suggested approach to addressing impersonation attacks is to require the keys be secured by the operating system (often backed by secure enclaves) and have the wallet software certified. But this introduces a tradeoff: it centralizes around a limited set of “trusted” operating systems and wallets that won’t allow the user to control or modify the wallet software, credentials, or keys to their desires. This ultimately undermines a user’s ability to control the software they run on their devices. In effect, this reintroduces the same issues we were faced with by the Web Environment Integrity proposal, but in slightly varied forms. We believe the Web should not be endorsing this level of centralization, as it will undermine user agency in what users can do with their devices and what software should run on it by prioritizing issuers and verifiers above users.
This issue is to track those concerns and develop technical mitigations or limitations on the API to balance this concern with appropriate usage.
See also #84 for the requirements of issuers on the wallets they issue into.
(Maybe there are separate issues about the implications of verifiers deciding which wallets are acceptable and the restrictions those wallets might put on users.)
Yeah, let's reframe this one to be specific to the restrictions that verifiers can place on holder software. In that case too, we'll want to consider residual effects that could be inferred by the verifier based on behaviors of the issuers.
For example, if the verifier knows a particular credential has issuer requirements around how the credential is held by the wallet then the verifier can infer aspects of the device even if not revealed by the API. This is basically the same problem as the following comment:
Especially because doing so will likely lead to side effect abuses. Just one example of this would be that a site would require the supply of an mDL credential not because they care about the attested data, but rather because it supplies a non explicit assertion that the software and hardware being used are integrity protected which is not what this API is designed for.