Ensuring support for open platforms

[DemiMarie]

Right now, the only wallets I am aware of are:

• Identity documents containing smart cards, which are at least sometimes usable on open platforms via various drivers, but which are not used in the United States at least.
• Mobile identity documents, which are tied to the secure hardware in a specific mobile device and sometimes restricted to specific operating systems.

This poses a potential risk to user freedom: if it is not possible to support digital credentials on open source operating systems, users risk being locked into proprietary platforms. Support for open source operating systems on mobile devices is often quite limited. Furthermore, wallets like Google Wallet restrict themselves to OSs that license Google Mobile Services.

[timcappalli]

The Digital Credentials API can be implemented in any browser. It is not restricted to any browser.

[DemiMarie]

If an open platform cannot implement a wallet, then this feature should not be exposed to the web. I'm not talking about browsers, but rather about the operating systems they run on.

[timcappalli]

If an open platform cannot implement a wallet, then this feature should not be exposed to the web. I'm not talking about browsers, but rather about the operating systems they run on.

Anyone can implement a wallet.

[DemiMarie]

Will that wallet be one that is trusted?

[dlongley]

@DemiMarie,

The Digital Credentials API is designed to work with the Verifiable Credentials (VC) ecosystem and others. In the VC ecosystem, verifier trust should not be in the wallet but in the issuer. Issuers can issue into any wallet (in an open wallet ecosystem). Users need to trust their wallets in a similar way that they trust their browsers: to act to protect their interests. Ideally, the verifier doesn't even know which wallet the user uses.

Verifiers, however, might need additional mechanisms to decide whether to accept the presentation of VCs by a particular holder (depending on the use case and VC(s) provided). This mechanism doesn't have to be one built on an assumption that a platform sufficiently restricts access to some counter-signing key belonging to the user and bound to the VC. Then the trust is, indeed, at least partly rooted in the platform. This isn't in the user's best interests and creates externalities that users end up paying for in an overly centralized (i.e., insufficiently open) ecosystem.

Requiring a counter-signature should be seen as a mechanism that helps protect the user (from credential theft), not the verifier, and therefore the user can make an appropriate choice of underlying platform, wallet, authenticator-device, and whatever else, on this basis. Again, ideally, the verifier wouldn't even know which of these were used -- they would only enforce checking the counter-signature (or accept a ZKP that proves such a counter-signature was used).

There are other mechanisms (e.g., cryptographic pseudonyms) that verifiers can trust to sufficiently limit sybil attacks without restricting the user's liberty and choice of platform and / or wallet.

Importantly, these considerations are all independent of the Digital Credentials API itself, which, as I understand it, presently has no opinion on any of the mechanism(s) used.

[timcappalli]

Importantly, these considerations are all independent of the Digital Credentials API itself, which, as I understand it, presently has no opinion on any of the mechanism(s) used.

Correct!