WICG / digital-credentials

Digital Credentials, like driver's licenses
https://wicg.github.io/digital-credentials/
Other
81 stars 9 forks source link

[Discussion] Integrate with web wallets? #38

Open RByers opened 1 year ago

RByers commented 1 year ago

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 commented 1 year ago

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 commented 12 months ago

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 https://github.com/WICG/identity-credential/issues/38#issuecomment-1788055095, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJYTI2AYVOXQ7XVG7C2XDDYCFTYBAVCNFSM6AAAAAA6YKMJSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBYGA2TKMBZGU . You are receiving this because you authored the thread.Message ID: @.***>

dlongley commented 12 months ago

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 commented 11 months ago

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 commented 10 months ago

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 commented 10 months ago

@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 commented 9 months ago

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 commented 9 months ago

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: https://github.com/WICG/digital-credentials/issues/38#issuecomment-1862928837

samuelgoto commented 9 months ago

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 commented 9 months ago

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:

Anything else?