-
Notifications
You must be signed in to change notification settings - Fork 9
2024 02 26 Meeting Notes
Organizer: Tim Cappalli
Scribe: Wendy Seltzer
- Administrivia
- Reminder: next call will be dedicated to presentation query syntax
- Intros from new folks
- Updates from incubation
- Any updates from Google / Chrome team / Apple teams?
- Anyone prototyping with their wallet or verifier?
- What’s the capability negotiation model assumed between the relying party (RP) / origin and the wallet / provider? #76
- registry of credential types
- Mutual Authentication
- AOB
- Tim Cappalli (Okta)
- Lee Campbell(Google/Android)
- Mike Jones
- Loffie Jordaan (AAMVA)
- Rick Byers (Google Chrome)
- Andrew Regenscheid (NIST)
- Wendy Seltzer (Tucows)
- Nick Doty (CDT)
- Oliver Terbu (MATTR)
- Hicham Lozi ( Apple)
- Joseph Heenan (Authlete)
- Brian Campbell (Ping)
Tim: March 6 meeting will be presentation of discussion ideas from last meeting, OpenID4VP profile
None
Rick: continue to iterate on implementation, nothing new to share
Torsten: What do you mean when you say "spec is getting better," Rick? This: https://wicg.github.io/digital-identities/
Sam: Yes, that URL worked with Marcos, resolved a bunch of things in the PR, https://github.com/WICG/digital-identities/pull/79, Issue https://github.com/WICG/digital-identities/issues/65 talk about how we merge?
Tim: We weren’t going to talk about web platform innards on this call so long as it doesn't impact functionality. If it materially changes how things work, bring it to the call. And if anyone has questions, bring to a call or to chairs’ attention for the agenda
Torsten: question about how the API works, need more explanation
Sam: agree the spec isn’t the best place to see how to use the implementation. I kicked off a bug with a code snippet, issue 80: https://github.com/WICG/digital-identities/issues/80
Sam: 80 is current, my approximation of how we’d call OpenID4VP given how it exists today. Using presentation exchange. Doesn’t go over UI
Torsten: Looking at how a wallet plugs in to that. This looks like service provider interface
Tim: How you write a wallet for Android isn’t in scope for the WICG conversation in detail; should try to help find a place elsewhere.
Torsten: need to agree on design principles
Tim: platform implementations aren’t for this group
Torsten: depending on who's doing the matching, different things go into the request. A conceptual architecture is important
Tim: there’s no guarantee that a matcher will exist on any platform. Same layering that happens with WebAuthn; there’s an undefined element. We can’t dictate to platforms. Client and platform layer in between is gray, undefined. In some cases, platforms say it’s the same as web API; in other cases, they don’t. We can make recommendations, but not requirements.
Lee: we want some idea of roles and responsibilities, e.g., who decides if a credential matches? I’m willing to chat about it in a side conversation here, IIW, elsewhere. Agree that an implementer wants to see the whole thing to see if it makes sense. Happy to share perspective from the Android group. We can also give full endpoint samples. Functionally, platforms want to be delivering the same functionality.
Manu: I’ve got 2 PRs, one editorial. 82.
Tim: I’ll add them to the agenda, thanks.
Tim: any recommendations?
Rick: We’ve got the right people here to discuss architecture. Does anyone mind doing that? Maybe do some explainers?
Tim: lots of thumbs up. Be aware there won’t be a W3C spec that comes out with a definition of platform spec
Lee: we can influence the design even if we can’t write a platform spec
John: Unless we agree on overall architecture, consider privacy and security implications, it’s going to be hard to make the API do what we want. Until we figure out overall flow, it's hard to nail down this part of API.
Ben: +1 to this type of discussion in CG.
Manu: +1 to the discussion, watch for keeping focus on API as well.
Tim: Current structure is designed to abstract away platform-specific features. Still aiming for that design principle
Torsten: key questions, payload in the request doesn’t need to be understood by the browser. I don’t need to worry about the browser then; that’s a design decision.
John: to Torsten’s point: what role is browser, matcher, wallet? We’ll need some guidelines around what matchers understand. Different platforms may make different choices. We need to understand what is common, so we can deploy cross-platform.
Lee: should request be more than a string? Then IDL considerations. For Android, it’s just a string, though we may try to understand it. For the web, is it typed, object, codified in the spec?
Rick: for the web, one nuance is that we have to be involved in the abuse-mitigation challenge. In a perfect world, it could be an opaque string, but the world is imperfect. Architecturally, it should be pass-through to wallets.
Tim: To me, that’s the challenge. If there’s any time you’ll need to understand it, then it has to be structured
Rick: chrome has places where to mitigate abuse, use heuristics, sometimes interrupt the user with a big red screen. Probabilistic, up to browsers to implement effectively. Edge cases when the architecture has failed. Safe browsing as an analogy. Browser reads the text of the page, not part of the architecture of the web.
Issue 76: What’s the capability negotiation model assumed between the relying party (RP) / origin and the wallet / provider?
https://github.com/WICG/digital-identities/issues/76
Manu: central for the API. How does the verifier know it can trust digital signatures coming from the wallet? Various proposals: none of the browser’s business but metadata discovery between wallet and provider; on the other end, Wallet credential. Whole spectrum of possibilities
Lee: isn’t that a slightly different issue, re verifying the wallet. Isn’t this one about capabilities? E.g., encryption algorithms, protocols. Where you need to know, do you probe for feature enumeration? Trustworthiness/integrity of the wallet is a different problem.
Lee: It’s on the issuer. If you know you’re requesting a European DL, the issuer is choosing where to issue it to. Any wallet that can honor the request has the capabilities to respond.
Nick: I was thinking about capability negotiation. Verifier wants to know a series of things: does the user have a wallet, that has this credential, that can respond to these protocol requests…? that can introduce privacy issues, as you learn quite a bit through these queries. That can be privacy-invasive, not just fingerprinting, but also characteristics of users likely to have these wallets (e.g. nationality)
Lee: Yes, talking to real verifiers, we keep getting asked for silent enumeration API. They don’t want to put the button if the user can’t click it. We do not want to give them this API. Also need to think about the UX, how not to have buttons that don’t work. Maybe conditional API.
Manu: +1 to Nick and Lee. Can quickly become a privacy issue. Capability detection in the wallet can lead to a trust score. Related issues. Silent API or wallet broadcasting capabilities are both bad ideas.
John: Agree; from privacy principle we want to disclose minimal information about wallet before the user decides to present a credential. Choices for wallets: we need to design mechanisms where verifiers can send enough info to the matcher, where the matcher can’t make a connection to get metadata. If the wallet and verifier can’t talk back and forth, they still need a way to find common terms. Who can make network calls, who can get metadata, how does info get to the matcher?
Lee: Feature enumeration, I get it for the issuer, but for presentation, if you’re requesting a credential, you can just ask for the credential, and if you get it, then there was a capable wallet.
Lee: Websites learn nothing until the user has consented to something; same on wallet, wallet learns nothing until user has consented. Matchers mean they get to run some code in a sandboxed environment, but don’t learn anything.
Tim: Lee, please create an issue with that statement (lee: Done https://github.com/WICG/digital-identities/issues/86)
Manu: +1 to Lee, JB. Too simplistic to say if you know the credential, you know all the parameters. Some creds have different parameters, e.g., cryptography. Fine to say that the response doesn’t go back until the user has consented. Could be both credential and parameters. That design pattern works pretty well in @@
Lee: You have to know what you can support, as you’ve got to decode it. You could offer a list of things you can parse. “I will accept X,Y, Z.”
John: I’d put it more as probing the capabilities of the credential, not the wallet. Most RPs will be asking not for “California DL” but “DL with an over 18 claim” which could be many different formats, signatures. So do they need to be more specific in their query? Send 2 requests for MDL, VC? What optionality, constraints?
Hicham: reader needs to know what they want from wallets. That's a reason we need a credential registry, so we know what’s out there. ISO, we’re trying to do that registry
Manu: -1 to a centralized credential registry. There are better ways. John, you mentioned that wallets don’t create credentials, but it has other capabilities: what protocols, is it backed by a hardware store, can it say these are the issuers I’ll accept credentials from, these are the formats, encryption, etc.
Sebastien: being able to select on the issuer, I don’t think that’s an option. Mandatory. A French website designed only for French people, doesn’t make sense to accept a German ID.
John: I wasn’t suggesting we not allow scoping by issuer or trust mark. We will create a brittle system if we start allowing RPs/Verifiers to overly specify behavior of the wallet. It’s up to the issuer to decide what it requires. Security abstraction ok, but additional constraints from verifier will be road to interop hell. Security is one property of the credential, LOA on the credential. Properties of the credentials, more than of the wallet.
Tim: I’ll put this back on the agenda after the March 6 meeting. March 6, query language