Requirements and Objectives

[tlodderstedt]

Hi all,

I have been told a couple of times the fundamental issue this group wants to solve is to find an alternative to custom schemes for invoking wallets. I agree with that objective as custom schemes are less secure than app/universal links and really brittle.

To understand what is needed one needs to take a look on what custom schemes are used for today in this context. In OpenID 4 VC we use custom schemes on the interfaces between verifiers & wallets and issuers & wallets to discover & invoke a wallet in cases where there could be multiple wallets serving the same purpose, typically in a certain ecosystem.

One example will be the EU's eIDAS wallet ecosystem. All the EUDI wallets will provide the same feature set through the same interfaces with the same formats as defined in the regulation and further detailed in ARF and implementing acts. As a verifier, I would like to talk to them without the need to write specific code for every of those wallets. I also need a mechanism to invoke one of the EUDI Wallets installed on the user's device. Custom schemes are today the only way to do that.

So in my opinion, if we want to replace custom schemes, we at least need to provide a mechanism resolving an alias representing a coherent set of wallets into one or more wallets for a certain user and device.

However, all the proposals submitted in this group go much further as they invent new protocols/APIs for requesting and presenting credentials. Why is that? There are protocol for that in the market already, e.g. OpenID 4 VC, RestAPI, DIDComm, CHAPI, ...

I think the first increment (one could call it MVP) should be an API resolving a symbolic name (e.g. "EUDIW") to URLs (or other types of addresses as used by the respective protocols). The benefit for the ecosystem is obvious, existing implementations of the before mentioned protocols could be improved very quickly. I would love if the user had the choice what wallet to use in case multiple wallets are installed on the device, it would be great if the user could install a wallet on demand instead of sending the flow to dev nil if no matching app is installed, user could open wallets with much more confidence as there would be some mechanism (like for app/universal links) to make sure only legit apps could claim a certain alias. Awesome!

A second step could be to define a browser APIs for credentials. However, to come up with a compelling solution, such an API (in my opinion) must cover the following features:

• credential format agnostic: it must support use of any credential format as there a lot of credential formats in the market and they should all be supported.
• presentation & issuance: issuers must find and invoke a wallet in the same way as a verifier. A comprehensive solution therefore must support both sides of the three party model and cover presentation in the same way as issuance. I'm being frequently told issuance cannot be standardized. Based on our experience w/ OpenID 4 Verifiable Credential Issuance I would say: it's hard but it is possible. And it is needed to give users the choice, foster adoption of the model and prevent lock in.
• cross device: the before mentioned points are all already covered by OpenID 4 VC, so a browser API not providing more would not be compelling to implementers. That's why I believe such an API would need to cover cross device scenarios as we know we can cover those much more securely with browser/platform support.

Please be aware the second step might introduce a lot of challenges regarding scalability of the system, security, privacy, and regulation.

• scalability of the system: whatever the feature set of the API is, it won't be sufficient and will need to be extended as the three party model is still evolving very quickly. Are the browser venders willed to keep up with that?
• security & privacy: a lot of data will be flowing through the browser that are security relevant (such as nonces) and PII (in credentials). I already hear it "we will encrypt everything". Well, that will make the developers live harder.
• regulation: Also please be aware that the more functions are put into browser and platform the more likely those components will be subject to regulation, i.e. they need to be certified, the provider perhaps even becomes part of the auditing/reporting/incident notification chain of the respective wallet provider. That's no fun.

The alias approach does not pose any of those problems.

best regards,
Torsten.

[OR13]

First part sounds like the beginning of /etc/hosts but for browsers... If we don't give users agency / control over these experiences, they will just do it at the network / os layer, like we already do with pi-hole, etc...

Second part seems ok, but could be shortened to "not covering issuance & presentation in the same set of APIs is a vendor lock in tactic, and OIDC solves this by locking you to OIDC".

security & privacy: a lot of data will be flowing through the browser that are security relevant (such as nonces) and PII (in credentials). I already hear it "we will encrypt everything". Well, that will make the developers live harder.

I feel like making developers lives harder is less important than protecting user data... using encryption carefully is also part of the solution to your concerns regarding vendor lock.

• https://www.rfc-editor.org/rfc/rfc9518.html#section-4.6

You touched on all the layers in this post, let me summarize my view of them, and please let me know if I missed something critical:

• Transport ( names to addresses / invocable URIs )
• Session ( nonces, origin binding )
• Presentation ( format agnostic, encryption helps force this to be true )
• Application ( let user's choose which client to use for a given server, where client is wallet, and server is issuer or verifier, and in P2P land sometimes these roles get flipped )

Some parts of internet architecture intentionally blind the client/server from knowing the exact path that data will take / has taken.

The browser APIs this groups contemplate seem to fit well with that model, the browser is a trusted mediator, under the control of the user (ideally they can uninstall it or switch to a different one, in the case that it misbehaves, or has security / privacy stance that they don't agree with).

As such the browser can blind the wallet, from seeing anything other than what it is required to see in order to function, and blind the web server from seeing anything about the wallet / credentials / presentations beyond what is required to function.

This means the browser blinds the holder from the issuer, and the holder from the verifier.

Encryption with channel binding is one technique for blinding.

• presentation & issuance: issuers must find and invoke a wallet in the same way as a verifier. A comprehensive solution therefore must support both sides of the three party model and cover presentation in the same way as issuance. I'm being frequently told issuance cannot be standardized. Based on our experience w/ OpenID 4 Verifiable Credential Issuance I would say: it's hard but it is possible. And it is needed to give users the choice, foster adoption of the model and prevent lock in.

Our experience might be a bit different here.

We think both sides need to be covered with open standards (ones that are built in the open, and that you don't have to pay money to read, or provide critical security feedback on), but we don't think the same standards or protocols needs to be used for both sides of the triangle.

I could be in person, talking over bluetooth / QR Codes to get a credential (issuance in proximity), but later remote presenting with OIDC4VP (remote presentation without physical proximity).

The browser's job is to mediate these experiences, not to shuttle me into a one size fits all protocol suite, or credential format.

The requirements of a mediator API are to expose the interfaces necessary to use the mediator safely in other protocols.

The mediator does this better, the less they know about other protocols, this is a main reason why encrypting everything is a positive signal, at least from where I am sitting.

Now if it turns out that the way the encryption is done, you can only use certain operating systems or devices, with certain APIs... that would be a clever trick.

If the layering is done correctly, a browser does not know if it is mediating to a web extension or a native app, but the issuer or verifier does (because they need to know, and the browser does not need to know)... this property is similar to how middle boxes are not supposed to be able to decrypt traffic and inject or alter content... we know this breaks when we only rely on naive transport layer encryption.

If the browser, wallet, issuer or verifier knows its connecting to a specific platform, its easy to imagine setting an allow list for platforms, but at least with encryption we know the worst thing that can happen is censorship / denial of service when a party can't confirm that the target is "safe enough to trust"...

[mcr]

Perhaps I'm stating the obvious: encryption between wallet and verifier that the mediator can not see. However, that does not mean that the mediator is completely transparent to anything. It has a number of roles to play beyond rendezvous. It also has to provide some kind of DoS for a mobile wallet in order to protect the mobile wallet's battery.
Secondly, one should not think of a mediator as being a single "machine" --- although it can be horizontally scaled easily if different wallets can be redirected to a specific mediator instance -- the problem is that end users will need to use a variety of mediator end-points in order to avoid being tracked across transactions.

That implies that we need actual non-trivial authentication from wallet to mediator: at least TLS-1.3 level client certificates in my opinion (cause 1.2 discloses identity for client certificates). Passwords and other bearer tokens won't do. I would prefer something like IKEv2 https://datatracker.ietf.org/doc/html/rfc8019. This is particularly important in a pure-QUIC/HTTP3 world, I think.
As I've asked multiple times: the shape of the wallet/mediator API has to be driven by market requirements around how the mediator is funded. Specifically, we see from the web world that if one wants to insert advertising, then it tends to break use of APIs. As such, if an advertising model is supported for that interface, then it needs to be in API. (I'm not advocating such a funding model, but acknowledging that it exists)

[hlozi]

Reacting to this first statement

I have been told a couple of times the fundamental issue this group wants to solve is to find an alternative to custom schemes for invoking wallets. I agree with that objective as custom schemes are less secure than app/universal links and really brittle.

This is not the fundamental issue that this group intends to solve. Instead, the primary objective of this group is to come up with a browser API for identity presentment that is secure, privacy preserving, and offers a positive user experience and by using the browser, we can provide better security, privacy and usability features than otherwise possible.

[tlodderstedt]

Reacting to this first statement

I have been told a couple of times the fundamental issue this group wants to solve is to find an alternative to custom schemes for invoking wallets. I agree with that objective as custom schemes are less secure than app/universal links and really brittle.

This is not the fundamental issue that this group intends to solve. Instead, the primary objective of this group is to come up with a browser API for identity presentment that is secure, privacy preserving, and offers a positive user experience and by using the browser, we can provide better security, privacy and usability features than otherwise possible.

Then can you please explain in detail why a new approach is needed given the existing work in this space?

[tlodderstedt]

First part sounds like the beginning of /etc/hosts but for browsers... If we don't give users agency / control over these experiences, they will just do it at the network / os layer, like we already do with pi-hole, etc...

I certainly assume the user has full control over the process. Your comment also made me revisit my original idea. I think assuming the browser or OS would be able to resolve a certain alias to one or more wallets means someone has to curate the respective list. That could be the user (etc/hosts) or a service (DNS alike). I don't think either of those options would fly. Instead I think the verifier should ask the browser or OS to invoke one out of a list of wallets (e.g. identifier by app/universal links). How the verifier determines this list is out of scope. In eIDAS land that would most likely be based on kind of a trusted list. In other contexts, that could be done completely differently.

[tlodderstedt]

Second part seems ok, but could be shortened to "not covering issuance & presentation in the same set of APIs is a vendor lock in tactic, and OIDC solves this by locking you to OIDC".

I only don't know what you mean.

First of all. you might remember that I proposed to have a protocol independent wallet discovery mechanism in the first part, right? Second, a new API MUST be better then existing approaches. Otherwise, why should developers adopt it? So it's not only presentation and issuance, it is also support of different credential formats that matters. And that would bring the API just on par with existing approaches (at least OID4VC and DIDComm). The only really compelling feature from my standpoint (because it is not provided by any of the existing standards) is secure cross device credential issuance and presentation.

That's kind of my perspective on a compelling product.

[tlodderstedt]

I feel like making developers lives harder is less important than protecting user data... using encryption carefully is also part of the solution to your concerns regarding vendor lock.

The best solutions cover both, user data protection and developer friendliness. A solution without an intermediary can provide a reasonable protection level for data in transit by using transport security. The proposals here on the table send all data through the browser as intermediary. That's why application level encryption is needed to prevent the browser from seeing the user data. That's different.

[samuelgoto]

This is not the fundamental issue that this group intends to solve. Instead, the primary objective of this group is to come up with a browser API for identity presentment that is secure, privacy preserving, and offers a positive user experience and by using the browser, we can provide better security, privacy and usability features than otherwise possible.

Note that this is exactly how we are scoping FedCM, so I think it is worth reconciling how we think of this API in conjunction with FedCM for browsers that are exposing both.

[tlodderstedt]

I could be in person, talking over bluetooth / QR Codes to get a credential (issuance in proximity), but later remote presenting with OIDC4VP (remote presentation without physical proximity).

The browser's job is to mediate these experiences, not to shuttle me into a one size fits all protocol suite, or credential format.

I think we are on the same page on that but I might have expressed my ideas wrongly. I absolutely assume there is freedom to choose the ways credentials are issued and presented and I don't see a technical reason to create a dependency between those aspects.

[RByers]

From Chrome's perspective, we consider it part of our contract with users that the browser facilitates transparency and control over the user's sharing of personal information. I can't speak for the whole group, since I do think there's a diversity of perspectives here but I shared Chrome and Android goals in September here. In particular:

• Wallet discovery and invocation:
  • Allow websites to request credentials from mobile wallet apps
• Seamlessly support multiple wallets
  • Without users having to remember which credentials are in which wallets
• Get meaningful consent from users prior to wallets learning any context
• Enable cross-device requests
  • eg. Chrome on Windows opening Android wallet, similar to passkeys
• Enable competition and choice in credential formats and wallet apps
• Focus on pragmatic solutions that can be brought to market rapidly
  • While enabling ongoing innovation and iteration - in and outside the browser
• Enable browsers to protect user privacy, security and choice
  • Transparency of request
  • While enabling wallets to keep sensitive data hidden from the browser

I think reasonable people in this group will disagree on whether all of these should or should not be goals of the group. Eg. there's an argument to be made that it's the wallet's job to do the privacy protection, not the browsers. But from a Chrome privacy perspective (and I suspect @marcoscaceres and @bvandersloot-mozilla would say something similar for Safari and Firefox respectively), we're willing to trust the wallet only to the extent we know that the user intended to invoke that wallet for the given website. We aren't able to rely, at scale, on an allowlist of trusted wallets or trusted verifiers, and so need to be prepared, for example, for adult-content websites to want to abuse age verification for tracking/ad-targeting purposes, ad-funded website to want to leverage logins for data-brokering and ad-targeting with unresettable identifiers, and at least one world government to leverage their own wallet to more thoroughly monitor and control which websites their citizens visit.

So I agree that your proposed "first increment" could more easily solve wallet discovery and invocation. If that was our only goal, then yes we should totally start there (big +1 to doing the bare minimum and avoiding reinventing). But I believe it would put us on a path which would make us less able to mitigate the ecosystem-scale privacy threats. And so, even if I wanted to, I don't believe I could get permission to ship such a feature in Chrome.

Point well taken that we should work harder at aligning on and articulating shared goals. I personally would state the goals of this group as preparing an alternative which can live alongside the use of custom-schemes, leveraging as much as possible of the infrastructure being deployed (to minimize deployment costs and maximize flexibility for issuers, wallets and verifiers), while simultaneously creating the incentive for a path where the browser and OS can act as an additional check and balance in defending the user's privacy and security interests across the web and all jurisdictions. Thoughts?

[tlodderstedt]

@RByers thanks for taking the time for explaining your perspective (both in the meeting and in your comment).

I have come to the conclusion that just replacing custom schemes with a wallet lookup mechanism (1st increment) would be less privacy preserving than a solution based on custom schemes simply because the interaction through a custom scheme does not reveal data about the wallet. And I buy into the argument made in the session that this could already reveal data the user want to control and perhaps not reveal (like citizenship in case of a wallet provided by a nation to its citizens only). So I think an API mediating presentation (and issuance) request through the browser is the better solution.

The concrete request/response syntax might vary, similar to the way payload conveyed through HTTP and the custom scheme may vary today. I support the idea broad up of profiles, one of them leveraging OID4VC, and would be willed to support the work on those (at least the one for OID4VC where I have expertise).

I think the split of responsibilities between browser and wallet is something we need to sort out. I don't think it is desirable to duplicate, or in worst case contradict, the regulatory efforts and respective trust infrastructures built and operated, e.g .in the EU. I'm willed to contribute to work in this area.

[RByers]

@tlodderstedt thank you, I'm thrilled to hear that! I'm quite excited for the potential of an OID4VC profile using the browser API, and am glad to hear that you and other experts in the space are exploring it.

I definitely agree on the split of responsibilities. I'm sorry if I gave the impression I thought the browser should supercede or ignore any such trust signals from regulatory efforts. Our discussion in the W3C PING context have all centered around the fact that we can't possibly solve the fundamental problems here in the browser / OS, and instead we need to create the conditions to enable good regulations to be able to succeed in addressing the core trust issues. My comments about the browsers responsibility are really about the backstop for when we have little else to rely on (eg. perhaps markets like the US, at least in the short term).

Any concern with my statement that the browser has an additional trust role to play in adding protection where the other layers of the stack are insufficient on their own to create user confidence? In particular, I've said that I feel a responsibility to have Chrome help enrich the public debate through transparency, by publishing aggregate / fully private stats on credential usage and user behavior by origin. My hope is that this would be helpful to privacy researchers and those working on regulations to help them reason about and tune tough trade-offs to minimize harm in practice. I think the last thing any of us want here is public sentiment and user decision making being driven by abstract speculation and fear, right?

[tlodderstedt]

@RByers thanks for your feedback. I think this is a good basis for working on a good solution.

I forgot to mention one thing regarding market adoption. My assumption is by the time the new API will be broadly available in a stable and interoperable manner, other approaches will have been implemented and rolled out on a broad bases. Just as an example, the large scale projects in the EU are already under way and I'm aware of a couple of ongoing EUDI wallet implementation efforts. Just having another way for presenting and issuing credentials might not be enough. The one thing that none of the beforementioned approaches solves as of today is secure cross platform interactions. If the new API covers that from the beginning (in combination with profiles for the respective protocols), it will be much easier to motivate existing implementations to migrate, simply because of the gain in functionality and security.

Last thought: stats are a very good tool for making decisions based on facts. However, please be aware that having and publishing stats also might create the impression of surveillance of user activities. I think any feature in this space should be tightly aligned with regulators to make sure it is a means to protect users and it is also perceived as such. As another aspect, a lot of interactions will start in an app, not in the browser, and will be mediated by the operating system. So whatever mechanism is designed here, it should cover that aspect, too. Last thought: ultimately, the wallets see all the interactions and could also gather stats data. So again, the split of responsibilities is a topic.

[RByers]

@tlodderstedt thank you. Yes that is my expectation on market adoption as well (hence "preparing an alternative which can live alongside the use of custom-schemes" in my suggested goal statement). Thank you for the input on cross-device, that's consistent with what our initial clients have told us as well. I assume you're talking about flows which don't require, for example, scanning a QR code (eg. because the user is already signed in with the same Google account on both devices), is that right? Chrome will not yet support cross-device during our upcoming origin trial, but it is at the top of our priority list after Android-only, so is conceivably something we might be able to include in our full API launch.

Good point about the risks of surveillance perception.

[selfissued]

This may be stating the obvious, but OpenID4VP, as is, isn't a good fit for the WICG credential presentation API. Members of the OpenID DCP committed to creating a profile of OpenID4VP tailored to the needs of the API, but that work is still forthcoming. For starters, that profile needs to omit all references to redirect_uri (since no redirects are occurring) and needs to omit most of Presentation Exchange (since the WICG API is about requesting ONE credential, whereas the design point for PE is requesting multiple credentials).

[OR13]

@selfissued I recommend surfacing that google document here (the ones with so many examples), I think its a great starting point for this discussion.

[selfissued]

See https://docs.google.com/document/d/10JT--pXWsfwC4QVu3XJpXGwcO08M6tnpkZ4PKdtCEWo for the proposal.

[Sakurann]

a PR that lays the basis for digital credentials API in openid4vp has been merged openid/OpenID4VP#155

I think this issue can be closed, unless we would like to add text to a digital credentials API draft in w3c about responsibilities between the browser and the wallet, since I think that is one of the remaining points open from this issue?

[timcappalli]

The OID4VP profile for the Digital Credentials API is actively being work on in the OpenID Foundation's Digital Credentials Protocols working group. Closing this issue.