Requirements and Objectives about digital-credentials HOT 18 OPEN

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?

from digital-credentials.

@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.

from digital-credentials.

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).

from digital-credentials.

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"...

from digital-credentials.

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)

from digital-credentials.

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.

from digital-credentials.

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?

from digital-credentials.

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.

from digital-credentials.

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.

from digital-credentials.

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.

from digital-credentials.

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.

from digital-credentials.

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.

from digital-credentials.

@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?

from digital-credentials.

@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.

from digital-credentials.

@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.

from digital-credentials.

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

from digital-credentials.

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

from digital-credentials.

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?

from digital-credentials.