-
Notifications
You must be signed in to change notification settings - Fork 9
2024 08 26 Meeting Notes
Organizer: Tim Cappalli
Scribe: Manu
- Administrivia
- Meeting notes need special handling when copied from Google Doc and pasted to wiki, to preserve inline links (such as the issue and PR links seen above and below) that are not raw URLs; especially important for non-GitHub targets
- Intros from any new folks?
- Any updates from incubation?
- Any updates from OpenID DCP working group?
- Issues Needing Action
- Define error handling (#130)
- Issues/PRs for Discussions
- Tim Cappalli (Okta)
- Mike Jones, Self-Issued Consulting
- Ted Thibodeau (he/him) (OpenLink Software)
- Lee Campbell (Google Android)
- Tom jones
- Manu Sporny (Digital Bazaar)
- Joseph Heenan (Authlete / OIDF)
- Andrew Regenscheid (NIST)
- Benjamin VanderSloot (Mozilla)
- Loffie Jordaan (AAMVA)
- Heather Flanagan (Spherical Cow Consulting)
- Wendy Seltzer (Tucows)
- Mohamed Amir Yosef (Google Chrome)
- Matthew Miller (Self)
- Ryan Galluzzo (NIST)
- Brian Campbell (Ping)
- Simone Onofri (W3C)
- Hiroyuki Sano (Sony)
- Hicham Lozi (Apple)
Tim: Anyone new that wants to say hello?
Tim: Any updates from incubation? Verifiers? Issuers? Wallets?
Sam: Chrome's incubation, in M108, Digital Credential API launched as an Origin Trial to Chrome Stable — anyone wanting to run against stable, you can do that now. Origin trial meets a strong bar for inclusion.
Tim: Any questions for Sam?
Sam: We don't know how long it will last, usually 3–6 months is the expectation.
Tim: Any other updates?
Simone: The Charter of the FedID group using DC API is out, if you are a W3C AC Member, please vote. Vote is open 9th or 10th of September, there is still time to vote.
Sam: Any feedback so far for this group?
Simone: Positive votes so far.
Tim: Any other questions for Simone?
Tim: Any updates from DCP for OpenID?
https://github.com/WICG/digital-credentials/issues/130
Tim: We were hoping for more discussion in this thread, not much since last call. Have folks looked at it?
[No comments]
https://github.com/WICG/digital-credentials/pull/157/files
Tim: There has been discussion on criteria, privacy considerations, anyone want to provide feedback here? Do folks need to generate WebIDL themselves?
Sam: This has to do with WebIDL. If we get into the business of generating WebIDL, whose responsibility is it? If you generate WebIDL, it hinders OpenID4VP evolution. What is the best way to layer the system to evolve independently?
Tim: Can you summarize that discussion in DCP?
Sam: We haven't arrived at a conclusion, we know what the problem is, we didn't talk about the solutions. In this PR, Marcos is suggesting we generate WebIDL for OpenID4VP. One of the things we're struggling with is, if we generate WebIDL and bake it into the browser, then WebIDL drops parameters that it doesn't understand. So, if OpenID4VP needed a new parameter, we would have to change every browser before that parameter could be used. If we bake it into the browser, that's what would happen.
Lee: Didn't we already have this conversation, that the browser won't step into this?
Sam: Now that we're getting to writing the PRs, we're having a more precise discussion. My and Rick's intuition so far is that we have to make sure to disentangle the browser from the protocol, so the protocol can evolve independently. For example, it is true that we shouldn't be opinionated about protocol parameters, but we are being opinionated about the query in protocol… there is code to parse presentation exchange, for privacy risk engine; some parts are inspectable, other parts are not.
Lee: It depends on the spec. Each browser can do what they like; new parameters don't break anything. All user flows work. Different from saying W3C spec controls every parameter in every protocol. We need to be clear about that; they'll use custom schemes.
Sam: That would put us in a position of not having a WebIDL. That's the discussion that we're having, having it in a more specific manner now.
Lee: Sounds like a hard requirement, that we can't put it in WebIDL.
Brian: I was going to concur; I thought this had been decided, that we were revisiting a consensus-based decision. WebIDL for protocols is meant to be extensible; seems like it's not appropriate to have or require it for an extension point for registry for protocols meant to slot in and be extensible.
Nick: To take the opposite position, registry inclusion criteria requires review of protocols to make sure we understand privacy considerations. If protections are meant to be in browsers, then browsers need to understand what is being requested, to communicate that to the user. If the protocol can change after a privacy review, not sure what that privacy review was for. WebIDL seemed to be a concrete version of that, satisfy criteria, easily inspectable;, anything updated since then, don't know what we can say to users or say what we've done to implement it, in the registry.
Joseph: Mostly going to agree with Lee and Sam, hadn't realized the implication that WebIDL would block extensibility. If that's the case, we shouldn't be baking in the WebIDL, as a fairly fundamental thing that extension points will extend in future to cover their use cases for reasons Lee says, not get in the way of them doing that, eventually harder for the browser to get involved with.
Sam: Nick delineated what the tension is — it is true that parts of that request are going to be inspected by the browser, to ask the right questions for the user. Joseph and Brian are also correct, there are other parts that we shouldn't inspect because we want them to evolve. These are non-conflicting goals. In OID4, there are nonces and client ID metadata, and a bunch of different parameters that the browser has no opinion on; because it can't make any guarantees, those can evolve independently. However, presentation definition, that is a part of the protocol that most browsers would inspect and alert users if anything is concerning in any way. We are having a discussion on OpenID as a whole, some parts that are protocol specific and some parts that are privacy oriented that the browsers should have an opinion of… that's where the confusion is.
Nick: Yes, I can see that, but can't see how some of it is not privacy concerning. Not sure if there is much that is not in the privacy considerations.
Sam: What about nonces?
Nick: Yes, but great extensibility isn't types of nonces.
Lee: Encryption keys, encryption algorithms, not particularly interesting either.
Matthew: Defining WebIDL in digital credential APIs; other protocols dictate issuance or presentation, like how you would get a credential out of the wallet. What is the intended experience for someone that wants to use the API to understand what credential formats are, to pass those in as arguments for the API. Is the registry intended to be credential formats and values? Cross-referencing on their own?
Tim: This is about protocols, but not about formats, that's another layer deep. OID4VP is mostly credential-type-agnostic, but that's mostly two layers of … DC API is only going to support OID4VP in the registry.
Matthew: Anyone trying to implement an API should figure out what the protocol looks like before getting to? Any existing examples of this?
Tim: Yes, in the registry. IETF uses registries.
Lee: PaymentHandler might have it, payment credential dependent.
Matthew: How do I request a credential? Need to learn OID4VP, section of doc on how to learn about protocol? As long as it's front-and-center, good for future adoption.
Tim: In reality, this is different in that developers have wallet w/ credentials, how do I get people to get them? Invocation mechanism on web and
Lee: Credential providers suggest how things are received. How are they issued? AAMVA defines everything about US driving licenses, mdocs, mdoc format, here are all the fields, field names, start there… then they say, wallets will implement OID4VP version X, then that spec says how to build one of these requests and then you work backwards, then they all end up in OID4VP in DC API, but different formats, different credentials. One of the credentials might be a payment credential; they have a whole section on transaction authorization and you'd only ever care about a payment credential if that makes sense.
Matthew: Lee, is there any concern in that model that credential providers lead to fragmentation on how to invoke API.
Tim: We are trying to do this like WebAuthn and Passkeys. Hopefully they never have to pick up the spec.
Lee: Library authors have to read the spec, hoping it's OpenID4VP sitting on top of DC API, as long as credential issuers use, then you don't get that fragmentation, this is the only one we know today, we hope we end up with one.
Matthew: If this plays out for PassKeys, how else does it work out here?
MikeJ: WebAuthn created a registry for WebAuthn, extensions that can be used and attestation types. The procedural note is only an RFC can create an IANA registry, if we want to do that for other W3C work, we can probably do so w/ courtesy help of someone at IETF.
Tim: Towards end of discussion, proposal to unbundle request to wallet
https://github.com/WICG/digital-credentials/issues/161
Sam: This is just a proposal on how to make this better. Might be a naive proposal, to be precise on what parts the browser inspects and what parts it doesn't; that's a tension with Marcos' PR. Marcos intends to validate the entire request. One of the ways we can diffuse that tension is to be precise about what parts we don't validate at all, which parts we validate, and decouple those two things. We make the request, custom schemes, OID4VP uses custom schemes for the wallet; then the whole request is passed to the wallet — bad for a variety of reasons, but good in that it doesn't have to ask the OS for permission. If we make credential selection inspectable by the browser, client metadata, credential selection is something that browser and OS will present to the user. Browser has an opinion on it, meaningfully changing UX based on what's in there. Presentation exchange, decoupled from protocol; we could have that as a thing, then we can have a request that is by choice uninspectable. Probably creates other problems but it solves that one.
Hicham: Is the proposal to do this on the protocol side? What is in WebIDL vs. what's in the browser? Or a common layer on the W3C side and is what the browser inspects?
Sam: Good question, noted that in the proposal, would be a benefit of that proposal; we could do something that's protocol agnostic. Something that a smaller query language isn't as broad as presentation exchange, something that browsers would look at and understand as a whole, unbundled from the protocol, we'd get benefit out of being able to construct query language to build meaningful credential selector independent from protocol used after credential section.
Hicham: Yes, probably good to define what we need on the browser side for user protection, and what we don't need to inspect.
Sam: Maybe client metadata is useful? It might not just be a selector, per se. Verifier's metadata. Proposal was to make it so that concerns of the browser go into one parameter; everything after credential selection is guaranteed to not be inspected.
Hicham: I agree that some parts are probably very difficult to go deep into inspection, needs to be opaque, happy to participate in work to define what part goes in what section.
Tim: Speaking as an individual, this is the only way I've thought is achievable long term. I do think we need to make this work. I do share concerns about having the selector incompatible w/ contents of the request; this is the only realistic approach for all parties to give an approach to the user in a reusable way. We will have this discussion on the B-call, Marcos will be there.
Joseph: What's the suggestion? Credential selection still needs WebIDL?
Sam: I also noted that in the proposal, it would have a WebIDL, make it more structured, but in WebIDL, there would be extensibility points; in that layer, query language is going to be most innovation, presentation exchange will evolve a lot, but parts browsers understand can be defined concretely; having WebIDL that is extensible is possible.
Tim: The hope is that the selector can be as minimal as possible; it won't be as expressive as the full request.
Hicham: The selector also includes everything that could lower the chances of transaction failure, like RP doesn't trust issuer of credential, or wallet doesn't trust the trust framework that RP is authenticated with, other than what documents, what claims, we probably need more that's understood by browser to lower chances of a failure.
Lee: Not by the browser, by the wallet, right? The wallet is the one that offers up the credential. The browser doesn't need to play any role to see if there is a match or not. Does that make sense?
Hicham: I did not understand that, Lee. If I have two wallets, and I have a country1 mDL and country2 mDL because I live in both. If I'm in country1, why would country2 be a part of the selection?
Lee: Incoming request comes in; wallet will make determination on whether or not they can make that request, might be a lot in the request, not want to standardize all of that in the browser, wallets can support it or not. Not the OS or browser deciding whether the match happens.
Hicham: Sounds like that's an implementation detail. We probably don't want to provide opaque things to wallets; there are opaque things we don't want to provide to all wallets. Implementation detail, want selector to be simple, it has enough to do the right selection.
Lee: I don't think it becomes NOT an implementation detail if we have to put it in the spec. If browser, OS, selection criteria needs to be specified in spec, then it's not an implementation detail anymore. That's where it gets more tricky; you can't update that w/o updating every browser. If you had a core set, which I think is what Sam is saying, protocol agnostic, then have extension points on that, maybe that could work… What's the core set, what can the browser do with it? Extra things with regard to match or not, maybe RP isn't on trust list, EU has to check it, browser isn't the one to check that list, RP has the credential or not, always stuff that's outside of underlying field selection, browser isn't going to know if it is selector or not, core set, decide what browser will do about it, it can't take part in full selection process.
Sam: I am using browser and OS interchangeably
Lee: We can say "platform"
Hicham: That's one way of doing it, but not comfortable. We shouldn't restrict how we do selection of wallets, ask all wallets or not, I may want to say "this wallet doesn't make any sense for this request, not even going to ask this wallet".
Lee: Yes, the platform could decide; it could do all determination logic, implementation detail. Different from spec'ing that in a W3C spec, so the platform can do that. You could specify how it works today. The platform can still do OID4VP requests; we could build that today, you're just encoding the OID4 spec into the OS. I think that's ok, but other OSes can do it in some other way. However, if you say WebIDL, then that locks it down in a way that brings in a lot. Purpose is credential matching and not risk analysis, if you change into credential matching, then you do much more than just matching the fields. You have to decide, are we specifying this for risk analysis, or for credential selection?
Hicham: It's both actually. Why can't it be both?
Lee: You can say you do this well enough for credential selection, for example, a trust model could be used, but those aren't even defined yet. You'd have to spec all of that if we're saying the platform does full credential matching.
Hicham: I'm not saying platform needs to do full credential matching; platform also doesn't have to just ask around; there is a sweet spot. The platform should do some of the matching, or part of the request, part of it is probably… getting too much into how to implement it, rather than the standardization part.
Lee: How much do you put in the spec and what's the rationale? Up until now, it's just "risk analysis", but if we change to "first pass of credential selection", that has to function fully. Very much sets a baseline for a protocol-agnostic credential selection protocol that can't evolve quickly, then have other parameters for credential selection, not an implementation detail anymore. As it's written today, it's left as an exercise for OID4, but that isn't in W3C spec. There is a difference.
Sam: Another way to think about this is in terms of interop, we want credential selection to be the same across platforms; whether you do it in Android or iOS, you should get the same credential.
Hicham: Well, we have to make choices
Sam: If you want credential selection to be equivalent, we need to write down what should happen w/ a request, including how to handle extensibility.
Lee: You have to think of that whole system. You want consistent results, what parts of that system… What do you need to act on? From my point of view, from native app, we don't look at anything. There's not a line of code in Android that knows anything about OID4VP, good for the ecosystem; if we did hardcode OId4VP in Android, that would be 3–4 years before it got out into the ecosystem. We don't look at WebAuthn. If you put it in the OS, you're looking at a 3-4 year timeline. It's a tricky trade-off to put more of the protocol into the spec.
Tim: What Sam and Hicham have described is more or less what WebAuthn does, but it's all in that spec, I'm not advocating for a single spec, we need to understand what that glue looks like for multiple specs. This is probably a bad example. If we look at OID4 as CTAP, it is a request that comes in on another device; what would the spec text look like? If you have't read WebAuthn, look at how there are procedures for clients and procedures for RPs. We don't have any spec text on what a verifier does other than get the promise resolution and do something. WebAuthn is detailed and hard to read, but it tells you exactly what to do.
Lee: I'm not saying it's not spec'd; if we already have OID4VP, it's written down, reasonably clear separation. If you start blurring them, we have to figure that out. One of the questions is: Do we pull the query language out of OID4VP and put it in the DC API?
Sam: Changing OID4VP, that ship has sailed. My specific proposal is duplication which can cause problems, parameter for platform for credential selection and then OID4VP for credential selection.
Lee: Then they can conflict.
Sam: In what ways would that be bad, two parameters that contain the same thing, can they conflict? Is this attackable? To be concrete, I don't know what second order consequences would be, but changing OID4VP would be a non-starter for me at this point.
Tim: if this is only for UI, people are going to put least friction and if it's not enforceable at layer, but completely different request can go to wallet, then we've created a problem
Sam: Haven't played out game theory, incentives are aligned so it wouldn't happen… naturally it wouldn't happen.
Hicham: About the "ship that sailed"? I don't understand that point, we're still discussing OID4VP query language, don't understand non-starter there?
Sam: Yeah, that's probably my personal intuition, maybe we can work with Joseph, Mike, Kristina, and Torsten, maybe we can work with them and see where it takes us.
Hicham: It doesn't sound good to do duplication.
Lee: I prefer to have it all in one place. OID4VP becomes a problem w/o query language and what about platforms on custom schemes, still needs one, then you have duplication. Difficult call, when using w/ DC API, OID4VP doesn't have a query language… decent amount of complexity to hold as an industry, not sure what problem it's trying to solve. What can't we do today?
MikeJ: I'm a little confused about what moving the query language to W3C would do or why. Brian can back me up on this but I believe that DCP WG will create a simplified query language and put it into the next implementers draft.
Tom: Just to follow up on what Sam said, what do you want in the query language, information that the user needs to make a choice. What does the user need?
Sam: Query language right now, fields requested, type of document, optionality, and so on. Those are used by the platform for credential selection.
Tom: Some of that doesn't seem like credential selection, wallet can determine that; user needs to know "Are you over 18?" "What is your ability to drive a car?"
Sam: That's what I mean by PresentationExchange, which browsers should use to help the user. Did I answer your question?
Tom: Yes.
Sam: What is being requested of the users?
Tom: Right
Tim: Ok, we'll wrap here. This will be on the B call to continue discussion, a week and a half away. Please add comments to the issue to get as much as possible done before the next call.
Joseph: How can we make progress on the error issue? We are waiting for that before givting examples of how to return errors in the VP spec.
Tim: It's all intertwined, it seems. Sam, about the error handling issue, they want to put something in OID4 spec?
Sam: It's intertwined, no closure yet.
Joseph: Thanks for trying.
AI Generated Summary (Google Gemini)
This discussion revolves around the challenge of defining how browsers should inspect and interact with Verifiable Presentation (VP) requests, specifically focusing on the "credential selection" process.
The Problem:
Currently, the OID4VP protocol handles the entire VP request, including credential selection, which is not ideal because:
- It requires full access to the request by the wallet, potentially compromising user privacy and security.
- It makes it difficult for browsers to meaningfully present credential options to users based on the request content.
Proposed Solution:
Create a protocol-agnostic "credential selector" that:
- Specifies a standardized query language for browsers to understand and use for credential selection.
- Defines what information should be inspectable by the browser (e.g., client metadata, credential selection criteria) and what should remain opaque (e.g., presentation exchange details).
- Enables browsers to effectively present users with relevant credential options.
Key Points:
- Browser vs. Wallet: The discussion highlights the need to clearly define responsibilities between the browser and the wallet. The browser should be responsible for presenting credential options, while the wallet should handle the final credential selection and matching process.
- User Protection: The goal is to ensure user protection by allowing the browser to inspect only essential information for credential selection and user experience, while keeping sensitive data opaque.
- Extensibility: The proposed approach should allow for future evolution of the query language and the credential selection process.
- Interoperability: The standardization of the credential selector aims to ensure consistent credential selection across platforms, regardless of the underlying protocol.
- Impact on OID4VP: The proposed solution would likely require changes to OID4VP, but the discussion emphasizes the need for careful consideration as OID4VP is a widely adopted protocol.
Open Questions:
- What specific parts of the VP request should be inspectable by the browser?
- How can we balance the need for user protection with the flexibility required for protocol evolution?
- How can we prevent conflicts between the platform's credential selection logic and the OID4VP protocol?
Next Steps:
- Further discussions on the proposed solution will continue in upcoming meetings.
- The group plans to explore the potential impact of the proposal on OID4VP and other related specifications.
- Participants are encouraged to add comments to the relevant issue to contribute to the discussion.
Overall, the discussion highlights the need for a standardized approach to credential selection that balances user privacy and security with browser functionality and protocol flexibility.