-
Notifications
You must be signed in to change notification settings - Fork 9
2023 11 01 Meeting Notes
Reminders:
WICG member: https://www.w3.org/community/wicg/
W3C Code of Ethics and Professional Conduct: https://www.w3.org/Consortium/cepc/
Please use the meeting’s Slack thread for discussions instead of meeting chat
Organizer: Tim Cappalli
Scribe: Marcos / Rick
Meeting thread on Slack: https://w3ccommunity.slack.com/archives/C05UG0EJUDB/p1698780994541809
- Administrivia
- Intros from new folks
- Updates from Blink incubation
- Anyone prototyping with their wallet or verifier?
- Custom Schemes Analysis write-up
- Protocol layering
- Explainer: API for Requesting Digital Credentials
- AOB
- Tim Cappalli (Microsoft)
- Rick Byers (Google Chrome)
- Gareth Oliver (Google)
- Marcos Caceres (Apple)
- David Zeuthen (Google)
- Lee Campbell(Google)
- Tobias Looker (MATTR)
- Helen Qin (Google)
- Hicham Lozi (Apple)
- Sam Goto (Google)
- Nick Doty (CDT)
Tim: has anyone started any prototyping?
Tim: Rick, You wanted to present a document? Rick: we heard from folks that they wanted to see some form of requirements document. Tess made comments on the PR. Tim: Please take additional comments to the PR
Tim: Sam and Rick, you wanted to present something around protocol layering.
Rick: How do we continue to make more rapid progress around protocol and the invocation mechanism. Marcos put up an explainer. Should we look at invocation problem VS custom URL scheme, and how you do the filtering?
Hicham: It’s the invocation and the transmission that is important
Tobias: It’s kinda murky around invocation around now you send data around.
Lee: This does mean there are not requirements in what gets passed around.
Kristina:
Lee: what a browser might inspect the requirement and put some UI. For example, we couldn’t take a completely encrypted request because otherwise the browser wouldn’t know what to do.
Rick: We need better name for this thing, but for now lets call it the Identity Credential API. Let’s figure out what we need to figure out within this group.
Tim: Like, we won’t need to define the query language. We could defer them to other specs.
Hicham: yes, we could potentially defer them to other specs.
Sam: As far as android and Chrome are concerns, only the wallet and verifier need to agree.
Rick: we would still want to limit the number of protocols that we support.
Sam: We would need multiple layers.
Sam: one concern with this proposal is if the browsers vendors disagree on what is in the registry… so otherwise, Browser A will only support some protocol and Browser B would support a different protocol. We don’t want that. We should agree on the protocols in the registry.
Tobias: The browser would want to put some kind of structure around the request vs the request being opaque.
David: I like this idea, but we need to think about interop. We really need the browser vendors to agree otherwise we will have interop issues.
Tim: Agreeing on an API shape is step one, and agreeing on the protocols is step 2.
Hicham: we can discuss the foundation and then agree on how the protocols would work. The browsers and the OS need to understand some things otherwise you won’t be able to do any matching selection.
Tim: …presents diagram…
Nick: there is advantage of abstracting out all the parts of the API. However, the privacy and security concerns remain in the protocols themselves. It would fragments the requirements. What guarantees does the user have?
Rick: it’s something we will named to manage over time. We already have two different standards that we are dealing with (mDoc and OpendId4VP)... let’s at least start with those existing two, and how we plug them into the browser. Hopefully this isn’t opening the floodgates to more - so let’s have those conversations.
Nick: we want to make it easy for developers so they do the right thing when making the request.
Rick: we have to acknowledge that people have been building this for some time. Some real world deployment in, for instance, Europe, we need make sure we can support accepting these credentials but don’t have a browser that supports this API. We don’t have the luxury of designing the one solution/API at this point. But we can design the thing we converge to over the time period.
Marcos: Happy to talk to the new explainer. This represents some discussions a few of us have been discussing (browser vendors and related parties). Nothing new in intro, just use cases we want to cover.
Marcos: We think credential management API is a good fit for the problems we want to solve - integrated into web security policy, lots of overlap with what we want to do. Can save us significant time and discussion, but focused on passwords etc. But we want to add a getIdentity method (in addition to current get method). Felt it was better to add a new method. Haven't discussed how to store these credentials yet. Listed some justifications why, more clarity for developers. Make it easier to shape the API. Also want to avoid requesting a password and identity credential at the same time - would get very complicated.
Marcos: To Nick's points around what would this look like. IdentityRequestOptions with an AbortSignal and multiple providers. The providers would include the protocol, defined in a registry. Also we'd add the cryptographics here.
Marcos: Once the request is made, getting back a 'DigitalCredential'. Called it that for now just because we have clash with IdentityCredential from FedCM, but hopefully we can resolve that since "DigitalCredential" is so generic a name.
Marcos: Then we have the registry I was imagining that we'd have privacy and security requirements that we'd expect as community because it has these privacy properties. Hoping we could enforce as a community what things we actually support. But at the same time input from implementors on what things they want to see supported here. Hopeful that we could come up with a set of criteria that the W3C requires for registries to enforce quality at all levels.
Marcos: That's it. Pretty simple. For now based on strings, we could look at structuring them. Leave it to OS and wallets to handle the format details. That's the rough proposal. Any questions / comments? Tobias: What's the implications of providers being an array / set? Within a single request you could ask for say an 18013-5 mdl and (or "or"?) Vc?
Marcos: Yes, "or"
Tobias: Would have to be defined about prioritization etc. Marcos: Get question we should put that in the doc. Should be based on user preference. Had this issue in payments space, and we put language into paymentrequest api spec that user preference takes precedence over anything else.
Tobias: So that might involve configuring in some way that's browsers specific. So eg. mDL might be rendered before anything else.?
Marcos: Yes.
Kristina: Love the direction, thanks for the work. For OpenID4VP, assumption is OpenID4VP request goes in, response is credential. For -5 request goes in, response is mdoc. Another option that's been discussed is a request goes in and response is a custom endpoint then verifier can talk directly to the wallet via the endpoint. That avoids the problems of custom schemes. Would that be a protocol that could go into the registry?
Marcos: No there would be privacy and security concerns
Lee: Want the property that RP doesn't have to learn the identity of the wallet. Eg. if you're revealing age, you shouldn't have to also reveal the wallet. Like would be bad to return an Android package name to be invoked. Also ergonomics. But as written it doesn't preclude doing something like that - could do something afterwards. Maybe we could have that conversation in OpenID4VP.
Marcos: Yeah that's true.
Tim: One of the goals is to make it slightly more phishing resistant than today. That would be a challenge.
Sam: I think that's why it's important to break this into separate layers. What would be the protocols that each browser would support would be an assessment.
Kristina: Happy to discuss concerns. Definitely wouldn't suggest returning the app package. I do think we could delineate verifiers talking directly to the wallet. Is worth considering, maybe privacy considerations are too bad that we shouldn't do it iat all. But should be on the table.
Kristina: Also curious where we're at for the cross-device scenario. That's super important to us, but haven't seen that mentioned yet.
Lee: Our aspiration is that you coil dmake this call say on a desktop in exactly the same way as on a mobile, and the browser could send it over like passkeys hybrid flow so it would be seamless. I think there's agreement that's the way it should go, but we haven't gotten to trying to specify that at all.
Tim: [Shows diagram]. Protocols would be specified, not not all here.
Sam: Important to ensure our initial design doesn't preclude us from doing this. We don't necessarily have to agree exactly how that's done. Could be per-browser.
Lee: One thing we're looking at in FIDO is to change the hybrid protocol to take arbitrary JSON. So we could maybe just pipe this over the FIDO JSON pipe.
Tim: Important architectural note: wallet apps shouldn't have to do anything to support this.
Sam: I would go evenfurther - you're saying CTAP/Hybrid. But within the same ecosystem you can skip a lot of that.
Tobias: Want to come back to what the API would return in terms of response. Probably obvious, but this is a protocol so we should define what is in the response. For developer ergonomics if some give us a credential back and others give us some complex thing we need to act on further to get a credential that seems like a failure of the API. Protocols that want to be able to integrate with this API should be able to reason about it.
Marcos: Obviously something we need to explore. Don't necessarily see it as a failure, eg. protocol may have requirements about how you decrypt it and so on. If we see multiple protocols share a response format that can be structured into one of these response types when we should leverage that. But to Rick's point, not sure how much we've missed the boat on that already.
Kristina: See the request is separate from the public key. When we explored how to encrypt the response using mdocs, the public key is part of the request. The protocols today put public key as part of the request. Is there any strong opinions behind this?
Hicham: The idea is to be able to specify an encryption that's common to all those protocols so credential is encrypted directly to the server and wanted that to be common to everything. Reducing the complexity of looking to each protocol to ensure the key is managed consistently, etc.
Kristina: I'm not convinced of the need for a protocol agnostic way to pass this public key? How do you know the public key is sent by the verifier sending the request? Some implementations verify the public key is in some chain of trust. Could have scenario where someone is replacing the public key, if we need to defend against that.
David: To be in the registry need to have a process. Would need to check that use encryption for the response. Maybe it's reasonable to say in order to be in the registry everybody uses the same way to encrypt the response. I would expect in addition to publickey there might be one or more certifications of that public key. Perhaps also a nonce. I think we have to find a balance. How many requirements are we going to put on these different protocols. It's a balance, we need to be mindful of developer ergonomics but we also don't want to force everyone to be the same.
Macros: Agree with David
Kristina: I want us to be realistic about the registries. W3C process inspired by IETF. IETF prevents duplication but don't make content-wise assessment, don't validate security/privacy (supposed to happen at the RFC level). New process for registries at W3C. If you ask me DID registry went terribly wrong. We voted in VCWG to use IETF registry process since didn't have confidence in W3C process. More could be externalized liek nonce or public key. I understand where you're coming from but I wonder if that impacts the mental model we're talking about here. I can't have nonce here and integrate with OpenID4VP - complications of having nonce in both places, what is guidance to implementors?
Lee: Don't think we want too many things at the top level for everything Kristina said.
Nick: My concern about the registry is that the privacy properties are not about the protocol quality. Can't evaluate very thoroughly reading the specs. Actual privacy comes from how browser explains to the user. Not going to get from a registry, or from an opaque blob. Don't see how to satisfy any of the legal or ethical requirements using the abstract model.
Hicham: Just want to remind folks that we don't want a lot of protocols here, want to hopefully converge for interoperability. Even so API says public key here, idea would be certificate chain with signature etc.
Tobias: Registry processes do exist in IETF where you have expert reviews - process beyond just checking for duplication, like checking encryption etc. Some might be harder. But technical protocol requirements could do that in process like IETF. But just because we have a registry doesn't mean we should aim for 100 or even 10. Should look for a small set.
Tim: Please file issues against this proposal. There's a label for it, please use it.
Sam: Kristina / Tobias: Do you think this could work for OpenID4VP, willing to work for us?
Tobias: Really interesting and good design direction, good step forward.
Kristina: looks good, just want to clarify returning value.
Tim: please file issues to track for the agenda.