Web Wallets and modern Web Platform APIs

[samuelgoto]

Hey all,

I had a good chat with @ve7jtb, Mike Jones and @balfanz at IIW about ways in which the browser could help Web Wallets, and wanted to take notes here to kick off a discussion.

I'm a browser engineer involved in the design and development of the FedCM API, the Digital Credentials API and other less related identity APIs, like WebOTP. I'm only partially involved in WebAuthn, but I think you all have good coverage there.

Here are some whiteboard screenshots I took with some notes:

I don't particularly know exactly what's the best way to help here, but I wanted to stop by to say "hi" and to offer any browser help you may have. I personally believe that the web should be a platform that is capable for developers of all types of applications more generally, but more specifically Wallets.

Having said that, there is at least a couple of ways that I think I might be able to help, to get the ball rolling:

(a) On Desktop, Web verifiers discovering of your Web Wallet and
(b) On Android, Native verifiers discovering your Web Wallet

I don't know if (b) is necessary or useful, but wanted to offer just in case. I think this can work equally well on Chrome on Android, but let me focus on Chrome on Desktop for a second.

Here is a demo of what (a) may look like:

You should be able to try this yourself this in Chrome here, with code that's currently checked in (some, behind flags):

https://code.sgo.to/2024/10/30/openid4vp-over-fedcm.html

What I'm imagining is that, in your Web Wallet, you could call IdentityProvider.register() to register itself in the browser storage:

await IdentityProvider.register(/** your configURL here */);

The browser prompts the user for permission to add https://wwwallet.org/ to its registry. The string used isn't great, because it is intended to be used by OIDC IdP rather than OpenID4VP Holders, but that's an easy fix.

Later, when a user is going to a verifier, it can call navigator.credentials.get({identity: ...}) and ask for "any" wallet (or specific ones too).

await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: "any", // accepts any wallet
      type: "openid4vp", // that speak openid4vp
    }]
  }
});

The browser loops through every registered wallet, and sends a request with cookies to the wallet and asks for "give me all credentials you might have". With that, the browser is able to build the following credential selector across all wallets:

There are many variations of UX formulations here, but here is one example of what they could get:

Ultimately, though, I think you want this UX here instead, where the user can discover your wallet even before clicking on anything:

Up until here, because the selector is mediated by the browser, your wallet wouldn't know about the verifier, and the verifier wouldn't know about your wallet.

Upon the selection of a credential, your the browser sends the OpenID4VP request to your wallet, which it can choose to open a pop-up window to gather some user confirmation:

Upon confirmation, in a pop-up window that's controlled by your wallet, the wallet can call IdentityProvider.resolve() to return the OpenID4VP response back to the verifier, much like your native wallet would.

The verifier than is responsible for verifying the verifiable presentation:

Architecturally speaking, this prototype is happening with OpenID4VP over FedCM. FedCM is a browser API that is used as a binding to OAuth, and since OpenID4VP is an OAuth profile, it can serve as a binding to it. I can walk you through with what would be involved in using it, but wanted to first get a sense of the kinda of UX that it could provide before going much further.

Because FedCM is a browser-mediated UI, it can unify and reconcile well with WebAuthn and the Digital Credentials API. For example, I think it would be possible to add to the selector an option to get credentials from Android Wallets (e.g. via cross-device CTAP) in addition to Web Wallets (available locally on Desktop) in the same selector.

This leads to a good amount of open questions (e.g. what's the relationship between FedCM and Digital Credentials? how do matchers work? how do we combine the Digital Credentials call with the FedCM call?), but wanted to kick this off early to see if you all would have an interest in exploring taking advantage of modern browser Web Platform API -- as well as extending its shortcomings.

[nvoutsin]

A prototype with simplified and practical UX choices could serve as a starting point to explore this topic, with wwWallet functioning either as a web wallet or a PWA app

To the list of questions above, I would add another concerning the role boundaries between the wallet and the browser in the areas of access control and consent management. Unless we significantly narrow down the usage scenarios and credential types, this could become quite complex in regulated ecosystems where advisory or mandatory disclosure policies may apply.

Let’s start simple and see where this takes us.