2024 02 21 Meeting Notes - WICG/digital-credentials GitHub Wiki

2024-02-21 (B Call)

Organizer: Tim Cappalli

Scribe: Heather Flanagan

Agenda

Attendees

  • Nick Doty (CDT)
  • Lee Campbell(Google/Android)
  • Dirk Balfanz (Google)
  • Hicham Lozi (Apple)
  • Heather Flanagan (Spherical Cow Consulting)
  • Mike Jones (Self-Issued Consulting)
  • Gareth Oliver (Google)
  • Loffie Jordaan (AAMVA)
  • Manu Sporny (Digital Bazaar)
  • Kyle Den Hartog (Brave)
  • Wendy Seltzer (Tucows)
  • Tim Cappalli (Okta)
  • Benjamin VanderSloot (Mozilla)
  • Marcos Caceres

Notes

Administrivia

n/a

Intros

n/a

Updates from Blink / WebKit incubation

Marcos and Sam made several changes to PR https://github.com/WICG/digital-identities/pull/79

Follow Up Discussion: Limit access to the API based on known allow listed origins #59

(Discussion continued from last week; see summary here) (Kyle) my follow up is to ask what is the differentiating factor here? What priority of constituency are we establishing? Who is the browser serving in this case? Is the browser serving on behalf of the issuer/RP? That doesn’t fit the model of user agency.

(Tim) Work is predicated on the browser being a traditional user agent. The speedbump is that consent is needed before any information is passed without user interaction. Can the user agent help in both directions? The trust model is almost entirely dependent on the issuance process.

(John) I don’t see that the browser has any role between the issuer and the wallet. Other than maybe as the conveyer of OAuth tokens

(Tim) at least it could help hand off to the wallet, be the selection broker.

(John) Yes, but that’s presentation not issuance.

(Tim) No, for issuance as well. It’s not getting in the middle of the issuance process, but the invocation to get the issuance request from A to B is valuable to the API

(Lee) The DMV is an example, and the browser is helping to get stuff to the right wallet.

(John) The issuer makes an offer to the wallet. Potentially there is a role for the browser in that, but it is very complex in that the issuer really needs to know a lot about the wallet.

(Lee) That would be out of band. We would say the DMV wants to issue a credential and provide an endpoint. The browser wouldn’t have any more involvement than getting to the right wallet.

(John) This is a separate work stream. We don’t want to invoke a wallet that can’t receive the credential.

(Lee) agree, there would need to be a matching process. But it’s still an orthogonal topic.

(Tim) We did say issuance was mostly out of scope.

(Kyle) Part of the concern is that there are a lot of conflicting issues on the model, so we may not be able to address the problem yet. If the wallet is acting as a separate role and a user agent, or what happens if the wallet is the browser, there are still open questions. But I’m still not understanding the constituency and their priority. IF the issuer can set restrictions on what software is being operated by the user, we are walking it down in the same way people got upset with the web integrity API. There have been big concerns by developers when we’ve done this in the past.

(Lee) there is a bigger conversation about where you can issue your credentials to, but for now it’s an out-of-band thing. The issuers get to decide what wallet app they give their credentials to, and many have policy about that. There is an open debate about whether the user can pick any wallet they like, but that’s not likely the world we’re going to see as the issuer wants to validate the wallet app. Esp. in the EU, they have very strict requirements. So this may be an out of scope question. We may need to help the issuer policies be met.

(Kyle) part of the issue is that it’s like saying a server will not issue HTML files unless it’s to a Chrome browser.

(Lee) You might be right, but I don’t think we can answer it here. That’s a bigger issue on policy and regulation. We can push for it, but it won’t happen in the early role outs.

(Kyle) That’s why I’m pushing back on the web platform being in on this. We have a conflict of interest.

(John) Agree with Lee, largely. To make progress, we have to leave issuance out of this. The wallet isn’t a user agent in the traditional W3C sense. It’s an authorization agent in the OAuth sense. That’s a much closer model. An OAuth authorization server definitely gets to decide who gets the credentials. It’s all about does the thing meet the policy. Apple/Google probably won’t instantiate all the attribute release policies from REFEDS and eduGAIN. There will be wallets appropriate for the kind of credentials they are holding and we don’t want to et in the middle of that.

(Tim) Using a webauthn example, it depends on how we use the credentials that are issued. Is it the user’s passkey or the RPs passkey? An issuer is using a set of utilities to give the user an artifact they still effectively own. The issuer can still revoke it (in theory). Where is the line between using the web platform as a utility?

(Kyle) In that example, a clear difference is the claims involved. Traditionally in webauthn, we’re not passing around PII claims with additional attestation abilities that offer higher trust. All other info in the web platform is self attested and has no certified value to it that can be trusted. Passkeys, WEI, Encrypted Media Extensions, and maybe FedCM are exceptions. At least with FedCM, it’s still acting as self-attested data mostly. EME was controversial, WEI was stalled, and Passkeys operate on a limited data set making this an acceptable tradeoff.

(Ben) whether you consider this self-attested depends on the relationship between the verifier and the issuer. Zero Knowledge schemes could be useful here.

(Kyle) ZKP present a happy medium, but you are still releasing little bits of entropy about the user. So it’s hard to draw a line because it’s dependent on the claim. Safer to assume all claims are risky, and if that’s true, how do we know the information needs to be revealed?

(Ben) We don’t want to induce demand, nor do we want to have people balk at a request. We’re trying to provide an improvement that doesn’t result in massive demands.

(Lee) If you look at the model, esp. in the EU and US, who gets decide to play? Who is allowed to make the request? In the EU, they believe the issuer gets that, so there will be a process where a website has to go ask to be approved to get an EU-issued credential. The wallet will be responsible for enforcing that. LIkely something similar in the US. So there will be a framework underlying stuff. Should the browser be another layer where they also get to decide who gets to play? Is an allow list the way to do that? Maybe a safe browsing list would reject some entities out of hand? Or if we made it too hard, would people go back to mailing photos of their drivers license? We can’t enforce a global allow list. There is a practicality question as to whether we could do this at scale.

(Kyle) What we have with the Public Suffix List, it’s single built, monolithic, anyone can point to it or add to it. Agree that that is not the right model and it goes against the principle of user agency because it requires the user to opt in to all use cases or none. I’m thinking more along the lines of an opt-in list like what we do with ad-block management. The user still gets to choose what lists they get to use in the same way they might choose a fiduciary in a financial role. They choose who they trust to make decisions on their behalf. That allows openness to exist while still setting defaults. We don’t have to make the assumption that some wallets will be validating properly and some won’t. Instead we say any wallet works. A wallet is not just a separate application logic, it’s an entity that can be one or many pieces of software that can achieve that role.

(Lee) Still worried about the scalability and the developer experience. Example: how do you get a hold of an EU drivers license? You have to contact the EU, get certified. But then you also have to follow another process to get on a separate list. This would have to be standardized for every browser, which introduces another group with another policy that gets to decide if the EU policy is acceptable.

(Kyle) The issuer lists can act as the certification logic of accepted verification use cases and is put into a standardized format that can be consumed by the browser and the user can enable it. Since it is in a standardized format, the browser can consume it. The EFF could create their own list. Ping Identity could create a list. We can default to “on” for the issuer list being offered by a government but could also take on the EFF list. This works within the browser context, and wallets are likely to have to do this anyway. So why not standardize across the board.

(John) Having a standardized way of doing that is easier said than done. The EU may mandate that browsers only talk to websites that have QWACs. That’s how they’re thinking of publishing their allow lists. There are other geographies and sectors that may have their own rules as well. If we could come up with a way for a browser to come up with a way to consume things like eduGAIN metadata, that would be great. But browser trust lists sound dicy.

(Tim) is this something PING would be able to discuss and report back on?

(Nick) it is possible. it still seems in scope for the API design, whether there will be a parameter or a trust-mark/enrollment/etc. but PING can be a place to discuss the privacy requirements there as well.

(TIm) any context the browser is able to observe and pass on to the wallet is in scope, but doing more than observe and pass on seems out of scope.

(Kristina - chat) I am not sure I am comfortable with the line of thinking that Wallet “certification” (by issuer or whoever) deprives the user of the user choice. giving the users the choice among the “certified” wallets is part of the user choice. User action at the browser api is not the only place where user choice can happen… And maybe I misunderstood some of the arguments

(Kyle - chat) It's a "choose your overlord" model rather than keeping this in line with the user are prioritized and maintain full ability to override their browser. Thinking about this akin to HTML files, saying that a server would only serve to certified chrome browsers would also not be considered acceptable on the web platform.

OpenID4VP workstream updates

(Mike) This is a proposal to have a discussion about the queries we want when requesting the presentation of a credential with the OpenID4VP group. Will have a discussion in that WG on Thursday. What we’d like to talk about in this CG is what properties we want in the API we’re creating for the queries that we’re making for credentials. There is an issue in the OpenID4VP repository. We were hoping to get a special topic call about it. https://github.com/openid/OpenID4VP/issues/112

(Kyle) Can summarize my point in a comment and you can find a better time.

(Mike) would rather have this on a call next week.

(Kristina) We haven’t had this discussion in the working group yet, so the call will be about individual considerations.

(Kyle) my biggest concern is that we don’t end up with too many profiles.

(Tim) we will dedicate the B call on March 6 for this.

Editor's updates

(Marcos) we dropped “identity” terminology from the spec, including the Identity IDL interface

(Marcos) We also chose “digital” for the “credential request options”, because the API is about requesting “digital credentials”

(Marcos) We deferred as much terminology as possible to the Verifiable Credentials Model V2 spec (e..g, “issuer”, etc.) because that spec defines things really well (and we didn’t want to duplicate that work).

(Marcos) The editor’s reached out to Manu Sporny (editor of VC Data Model) to help up further align terminology. Manu sent two pull requests: https://github.com/WICG/digital-identities/pull/82 https://github.com/WICG/digital-identities/pull/83

(Marcos) We also looked at what’s left to do to integrate with Credential Management: We have documented what we need to do as part of https://github.com/WICG/digital-identities/issues/65 There is a little bit of spec work, but it’s not much. We have a really clear todo list.

(Marcos) That should be fairly quick to knock off, and the larger question around the actual request format now remains.

Reminders

Please look at Manu's PRs for an upcoming call:

2024-03-06 call will be dedicated to the OpenID4VP profile discussion, and more specifically query syntax for presentation.