-
Notifications
You must be signed in to change notification settings - Fork 9
2024 04 03 Meeting Notes
Organizer: Tim Cappalli
Scribe: Manu Sporny
- Administrivia
- Reminder about IIW planning
- 4/8 A and 4/17 B call canceled due to TDI/OSW/IIW
- B call rescheduled starting 5/1
- Intros from new folks
- Updates from incubation
- Anyone from Google or Apple have any updates?
- Anyone prototyping with their wallet or verifier?
- Any general updates from the OpenID DCP Working Group?
- Additional work item for Federated Identity WG
- Should we add a clientData like object? #95
- New issue based on a bunch of conversations on the calls
- Wallet-provided nonce #92, mutual authentication #81
- Are these addressed by the OID4VP profile defined modes?
- Nothing is learned without consent #86
- Does this need to evolve into spec text or is it just design guidance?
- AOB
- Tim Cappalli (Okta)
- Heather Flanagan (Spherical Cow Consulting)
- Rick Byers (Google Chrome)
- Manu Sporny (Digital Bazaar)
- Nick Doty (CDT)
- Loffie Jordaan (AAMVA)
- Mike Jones (Self-Issued Consulting)
- Lee Campbell (Google/Android)
- Tobias Looker (MATTR)
- Marcos Caceres (Apple)
- Helen Qin
- Tom Jones
- Sam Goto
- Gail Hodges
- Jin Wen
- John Bradley
- Hiroyuki Sano
Tim: Administrative items – IIW is in two weeks, if you're going, let's coordinate on sessions. If it's related to this space, let's help each other plan. Next two calls are canceled, lots of conferences happening. Next call is Apr 22, 2024
Tim: Final time chosen for new time slot for APAC call, 2 hours earlier, will start on May 1st, download new calendar series. There is a new Google Meet link.
Tim: Any introductions/re-introductions?
Tim: Any updates on chromium/webkit?
Lee: There will be updates from IIW.
Marcos: No big updates, more general implementation going on. I will be at IIW. There'll be a bunch of people from Apple there.
Tim: Any updates from DCP WG?
Tobias: There is general WG movement going on, nothing specific to this group.
Sam: I went to one of the calls, we found some convergence on browser API convergence to PR that will be sent. That's worth noting.
Tobias: Yes, if that wasn't already covered/raised, that's worth noting.
Gail: Torsten raised the PR with contribution, but don't believe report out to WICG has been done yet?
Tobias: yes, that's my understanding.
MikeJ: That profile for OpenID4VP for browser API, one of the things we're trying to sort is which parts to retain and what parts ot redact. When used in OAuth web flows there is a redirect URI (because you redirect through web origins), not applicable in Browser API. Turns out that knowing origin of party you're interacting with does convey some information. Need to figure out if equivalent information needs to be sent or not… any notion that we'd use existing OpenID4VP unmodified in browser API has been abandoned.
JohnB: For example, credential selectors can't make network calls, which OID4 needs to do, so what needs to come out, what needs to go out, what needs to change. Include the origin as part of the request (https://github.com/WICG/digital-identities/issues/96).
Sam: FWIW, client metadata would go into matcher process.
JohnB: client metadata is usually resolved with a network call. We may have to take that information and provide information in matcher. Because flow is different, matcher might need to take advantage of that.
MikeJ: Discussing at IIW, what can be the same, what can be different, might be an interesting IIW discussion.
Tim: FedCM WG is launched, did not include WICG work, there is a proposal to add this work item. Feedback welcome: https://github.com/w3c/strategy/issues/450
Heather: IIW session to discuss this, make this a point of discussion after WG is created, hoping to get session at IIW about it.
Tim: Any questions about this?
https://github.com/WICG/digital-identities/issues/95
Tim: There are 3 parties in WebAuthn model, this looks close to what we do there, browser has a unique lens on what's going on, type of request, authoritative on origin, TLS context, one thing we know is that we need to get origin down to wallet. Do we need to provide context around TLS? QWAC cert, etc. We might want to pass origin… does it work in iframes? We'd need to pass things through to that frame. We might want to kick off issuance discussion as well. This should look familiar if you're familiar with WebAuthn. This could be passed to wallet / platform, it could get signed over, one values … authenticator acknowledged and signs over it, RP could validate that on way back that it matches what they expect, important for cross-origin calls. You want to see origin in response. Initial thoughts?
Lee: Are we thinking very close to WebAuthn?
JohnB: We should do it, but TLS Context isn't in there because browsers haven't added it yet. At point where you're calling JS API, you have no idea what cert was used. You know what origin is, but there might be 20 different certs, browsers have resisted providing that information at that point. Adam Langley has strong opinions about this.
Tim: Let's treat this as evergreen, request it, and see what happens. I can see both sides of argument.
Sam: Clarification question, is this an object that gets passed from website to wallet or … who is the creator of this object?
Tim: The browser.
Lee: Wallet gets origin and hash of data.
Tim: There is value in wallet signing over hash.
Sam: Wallet trusts browser to provide valid data.
Lee: You have to trust the browser, it provides data, then sign over it.
Sam: Marcos' proposal to passing origin to wallet is complementary?
Tim: Yes, we'd have to add this to the data that's sent.
Nick: Which certificate seems like information that the wallet may need. Not sure why website cares?
JohnB: Adam Langley's position is that this API is called by Javascript, which might be pulled in from multiple origins with different certificates, not an easy way to say TLD has control over JS running. Chrome can't easily map that. One of the things we had in WebAuthn originally, hash of certificate of RPID would be put in client data and that was taken out because it was considered to "not be practical to do". If we could do it, it would be good, cautioning that UA may not know what certificate was used (if multiple certs was used).
Marcos: You can know which cert applies to index.html, once you mix in you don't know JS that's applied that's used.
Tobias: The true audience of client data is backend that validates it, that's how you get proof that response is actually for you, so that's critical part of this. Origin is pertinent, might form part of consent process, trust decision by wallet, that information is conveyed in a platform-specific manner? There might be a platform-specific treatment of that information from webAPI down onto that platform.
Tim: The hashed object is only the web platform's view of that, how that gets down isn't in scope
Sam: This requires OID4VP to instruct holders to sign over hash? Requires OID4VP to also be changed.
Tim: That's the optimal path, but there is value in client returning it to API call. Signing over it in OID4VP is best approach.
Sam: Client already knows most of this information? Verifier knows this, right?
Tim: Verifier does not know that. WebAuthn stops MiTM.
JohnB: Makes MITM harder, doesn't stop it entirely.
Sam: There is value in this even if OID4VP doesn't sign this.
JohnB: It should be possible to change this, probably needs changes in individual formats. So mdoc is probably a different change, from a VC for SD-JWT, Verifiable Presentation might have format dependencies.
Tobias: You could put it in the vp_token, OID4VP does have mechanisms that we could use. At end of the day, we don't want verifying parties to verify response for them. I do believe there are options.
Lee: For mDoc we have to define session transcript for browser. We have to decide what goes in there, reader public key, origin, etc… client data hash to end up in transcript, sign over it using mDoc keys, HPKE, we need to add that into that structure.
Sam: Change is in signing of formats, not OID4VP.
Tim: We should come to a conclusion on this sooner than later. If you have feedback, please put it in the issue. If we get consensus, we can do a PR for the spec.
Tobias: Is the behaviour around obfuscating information to wallet important to preserve here as well, wouldn't want to ship it over as JSON or you can agree on hash, are we saying that why this is being pursued?
JohnB: I can speak to why it's done on WebAuthn, but the reason doesn' thold for wallets. WebAuthn is designed tow ork with smart cards over NFC, in client data we had txauth, hash … size of client data was unbounded, being able to send it over NFC wasn't practical, decision was made to webauthn do hash, send hash to authenticator so there is deterministic amount of information.
Lee: We're not hiding from authenticator, they're not the audience for it. The audience of that data is the verifier server, only people that need to look for it.
Tobias: If it's not about bandwidth, and if there is other information in there, if they will be integrity protected, if it's going to be sent unhashed, extensible payload that browser could add over time, not sent as a hash, one copy of info for source of truth and whatever else browser wants to communicate, maybe we're talking about a slightly different design to WebAuthn.
Sam: Does making request cross-device change equation? Bandwidth problems with cross-device?
JohnB: All of the … extensions… what goes over hybrid is closer to WebAuthn messages vs. CTAP messages. Large blob sent directly to the phone rather than have client on desktop try to process it. There are some constraints, but what's going over hybrid is much larger than what's going over CTAP.
Lee: We increased the size… mDL portrait gets into hundreds of KBs, if we pass hash no API boundary, if we sign object, we have to define what's in it, wallet is a part of that contract.
JohnB: What would be in client data that client wouldn't need?
Lee: Same argument, could mean we define client data sa top level thing and fully spec it.
Sam: Is there any data that isn't there that we don't want wallet to know?
Lee: Depends on how far we go and what we put in it. Probably not a privacy thing. Pragmatically, don't make it part of the API contract.
Tobias: Would it be useful to have payload that is integrity protected? Perhaps we don't have near-term objectives? Client data might only be pertinent to verifier backend?
Lee: if we put together examples of client data object, we can start to reason over, should client get this, or just origin on steroids. Let's put examples in issue.
JohnB: Let's look at client data in WebAuthN, origin, package id, top-level origin if iframe, there is additional context stuff, secure payment confirmation information, extension information, extensions… bucket of everything that doesn't have direct impact on authenticator that needs to be communicated back to verifier.
Marcos: We haven't even decided if we're goin to allow this cross-origin, permission policy implications, etc.
Tim: What is the status of these issues? Are these covered by the OID4VP Profile?
JohnB: It's under active discussion
Tobias: How do we appropriately authenticate website to wallet in a way that is independent of the web platform trust model? Much of that issue is talking about other solutions, title itself is a bit misleading. There are three different solution options, a bit of back and forth on what would be most suitable for browser API.
Tim: Should we split the issue, close it? What's the next step?
Tobias: What is EIDAS regulation technically mandate as best as we can gather, trust model for web platform, what is assumed? What would it mean to build API that is trustless? Wallet can establish who sent the request when everything leading up to it is initiated through the browser?
Lee: As a wallet, do I need to maintain a massive list of RPs? We can do that using reader keys, but I think if you're concerned about – offer it to user, if it fails on server side over verifier… if you are not ok with that then it's not sufficient. We need to decide if this is a problem?
JohnB: The reader key solution is the worst solution for scalability and interop – tying to TLS transport , do you put QWAC on your site, or something else? Sites don't know what wallet is being used, don't want to expose wallet to verifier up front.
Lee: Nothing to do with TLS, reader key that's passed as part of HPKE response.
Tobias: You have to provide public key to encrypt response, you could also pass certificate chain that validates that to trusted origin for reader key. TLS also does that, but that's where similarities end.
JohnB: As long as its separated from TLS layer, had discussion w/ Microsoft for QWAC for certstore, people are deeply confused about various layers and where certs are presented. Different cert as part of request, getting trust mark from metadata, number of different ways that different trust models will evolves for different credentials, EU is keen on QWACs and we have to support that until it falls over. Verifier doesn't know what to send as a reader cert because they might have many of them.
Tobias: Overarching question that brought this up – browser is going to provide its attestation. Wallet can use that. Question that brought this to forefront, what if I don't want to trust the browser? Separable trust, you could validate who you encrypted the response to. Only party that you intend to get response, wallet provided nonce – what if I want to authenticate party w/o trusting browser.
Lee: The reasons are replay, can't trust origin rom browser doesn't make sense, but scalability wise origin might not be enough, reader key alone could consent, can't do anything w/ response. Is it worth
Manu: Anytime we say we can't trust the browser, it seems suspect. …[missed].. There's a scale problem with all of these proposals. QWAC has a number of issues, many of us think it'll fall over in time. Wallets keeping a list of RPs is going to have problems too. We shouldn't assume that wallets need to always strongly verify the RP - eg. movie tickets, lots of use cases that aren't super high assurance.
Tobias: If you say strongly verify, then the trust decision comes to the user. We can just say "foo.com" which is the trust model the whole web relies on - for the user to decide.
Manu: Exactly. We can follow the trust model the web follows today. You put the origin in front of the user and the user decides if it's what they expect or not. Anything beyond that may provide an additional level of security but introduces scalability challenges.
Brian: The idea that the browser isn't trusted isn't the main thing driving these requirements. Is it incumbent on this group to hand something off to wallet so it can do additional verification? Maybe that would be sufficient?
Tim: Pay attention to next meeting time, download new calendar stuff.
Lee: We're going to do a 101 on this WICG group, Tim will give overview, Sam and I will demo, feel free to jump in.
Tim: See some of you at the conferences coming up!