[Discussion] Integrate with web wallets?

[RByers]

CHAPI went through great effort to integrate with both native and web wallets, as do other similar APIs like PaymentRequest. At the moment we've focused here mostly on native wallet integration.

At a minimum I think we need to convince ourselves that a V1 API could be compatibly extended to support web-based wallets.

[dlongley]

A significant consideration should be what advice to give to verifiers (aka relying parties) who want to support or continue supporting accepting credentials from Web Wallets ... if the new API only supports native wallets.

[RByers]

Makes sense. Even if the new API supports web wallets out of the gate, I'm sure we're going to see inconsistent uptake of the new api from wallets of all types (some taking longer than others, probably some deciding not to support it at all), right? Also not all web users will have a browser that supports the API for some time. So in any case I think the general advice to verifiers will be to follow the integration advice of the wallets they wish to support to maximize their reach, right?

…

On Tue, Oct 31, 2023 at 5:22 PM Dave Longley ***@***.***> wrote: A significant consideration should be what advice to give to verifiers (aka relying parties) who want to support or continue supporting accepting credentials from Web Wallets ... if the new API only supports native wallets. — Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJYTI2AYVOXQ7XVG7C2XDDYCFTYBAVCNFSM6AAAAAA6YKMJSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBYGA2TKMBZGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dlongley]

Makes sense. Even if the new API supports web wallets out of the gate, I'm sure we're going to see inconsistent uptake of the new api from wallets of all types (some taking longer than others, probably some deciding not to support it at all), right?

Yeah, I agree. However, I think this is less about the fact that there will be a period of time (if this effort is successful) where the uptake is inconsistent and more about whether the incentives will align to ensure that that inconsistency can be eventually overcome.

Something important to consider here is that the user's specific wallet choice ("brand") should be unknown or irrelevant to the RP (at least for many use cases in this space). This means RPs have to rely on feature or capability detection to resolve inconsistencies -- and RPs will want to support as many wallets as they can to maximize their user base (or to at least minimize user frustration, which in turn, has the same aim).

It's been highlighted in other issues here that it's not an ideal UX for a user to choose a wallet... only to find out that it can't provide the credentials the RP wants. The same is true of opening a selector just to find out that you need to use another one to see your Web wallet.

If an RP can't tell whether a selector API will support Web wallets or not -- or if it's clear that one approach will not support it, but another will, then this creates perverse (or undesirable) incentives. We do not want RPs to avoid using this new browser API because it can't seamlessly provide both a good UX and some options users want -- nor do we want to disincentivize Web wallets.

Trying to solve for this partitioning problem may result in people proposing additional helper APIs that can lead to fingerprinting / other privacy concerns. This may generate a similar level of work and discussion -- and perhaps a more complex API -- than tackling the problems required to support Web wallets. In other words, the partitioning, if introduced as an effort/time-saving measure, may not actually save that much effort/time -- unless a serious effort isn't also put into ensuring future support for Web wallets.

It may not be an easy thing to delay Web wallet support and still produce, in the end, an ecosystem that has well-adopted both Web wallets and this new browser API. It is important not to set these two things up in competition with one another.

So in any case I think the general advice to verifiers will be to follow the integration advice of the wallets they wish to support to maximize their reach, right?

I actually pretty strongly disagree with this -- because that driving mechanism is the source of significant problem(s) we're trying to solve (well articulated here: https://github.com/fedidcg/FedCM/issues/240#issue-1187417925). Having that sort of incentive drive the market is exactly what I think we want to avoid. It's ultimately harmful to user choice and competition in the space. A major goal is to ensure RPs don't have to think at all about specific wallets ("brands").

[TomCJones]

in the beginning of the web the web site had to rely on the user-agent string to make their content work on all browsers. I expect we will need to go thru that process with wallets as well. There appears to be no effort to create something like the browser specs for wallets, so there is no single standard for wallets to adopt. Just a bunch of API specs. So the situation is even worse now that in the early days of the web.

[OR13]

I'd like to see web wallets supported.

It would allow me to test the browser APIs this CG incubates, I don't think Android or iOS should be required to present credentials to websites, and APIs that are only usable from Android or iOS reminds me a bit of ActiveX / Flash... which I do miss, but it seems like we've moved on from them as the web platform has improved, and continues to improve.

[timcappalli]

@OR13 it is largely out of scope for this specific effort as an extension or PWA would need a separate API for registering with the browser.

We have a similar challenge with passkey providers running as browser extensions and there's potential to solve them together. Ultimately the goal would be to have them register with the platform, so they're not silo'd to a browser. That could be direct or via some form of browser mediation/proxy.

Hoping to start some more formal discussions around this in the new year.

[marcoscaceres]

I'm wondering if we can declare this out of scope for "v1"? Seems we have enough challenges to solve as it is.

We should, of course, be writing this in terms of abstract "credential provider" (what is in w3c-fedid/FedCM#57). That's what we did for Payment Request (PR): the PR API only defines the qualities of a payment handler, but doesn't say anything about it being a native handler/app or a web app. It just says that a handler must behave in some conforming manner.

[timcappalli]

Yes, I believe on one of the calls there was loose consensus that this would be out of scope for v1 as it would align closer to the credential provider work described here: #38 (comment)

[samuelgoto]

I'm wondering if we can declare this out of scope for "v1"

Yeah, I think it is reasonable to leave it out of scope for "v1", but I do think we should think enough about it to make sure we don't corner ourselves.

I'm specifically interested in understanding how this design reconciles with the Credential Manager API.

For example, if we expose a navigator.credentials.requestIdentity() method, are we going to then expose a navigator.credentials.storeIdentity() method when we have to handle this? And, at that point, would we have duplicated navigator.credentials.get() and navigator.credentials.store()?

[marcoscaceres]

we going to then expose a navigator.credentials.storeIdentity() method when we have to handle this?

I don't think we would because .store() stores a Credential instance, of which DigitalCredential is easily distinguishable.

The problem with .get() was not being able to easily distinguish between the different dictionary types without duck-typing.

However, let's move that discussion back to w3c-fedid/FedCM#61 otherwise we risk moving this issues off topic.

For defining "credential provider", we should figure out what the qualities are, like:

• it presents a UI for a user to select a credential.
• the user can abort the selection process and not make a choice.
• the API can bring down the UI via the abort signal.

Anything else?