-
Notifications
You must be signed in to change notification settings - Fork 9
2024 09 04 Meeting Notes
Tim Cappalli edited this page Sep 5, 2024
·
1 revision
Organizer: Tim Cappalli
Scribe: Matt Miller
- Administrivia
- Intros from any new folks?
- Any updates from incubation?
- Any updates from the OpenID DCP working group?
- TPAC Info
- Discussion
- Disallow multiple types via navigator.credentials's methods (CredMan:#244)
- Continued from A call: Proposal: unbundle the request to the wallet from credential selection (#161)
- Handling various origin types (#160)
- Rick Byers (Google Chrome)
- Sam Goto (Google Chrome)
- Ted Thibodeau (he/him) (OpenLink Software)
- Matthew Miller (Self)
- Nick Doty (CDT)
- Tim Cappalli (Okta)
- Heather Flanagan
- Marcos Caceres
- Brian Campbell (Ping)
- Lee Campbell (Google)
- Mike Jones
- Hiroyuki Sano (Sony)
none
none
none
- Due to external factors, strong renewed interest in taking OID4VP and OID4VCI docs to final
- ETA: in a few month's time
- OID4VP doc has an annex in it that tries to define profile, "protocol" of browser API for presentation
- Encourage folks to take a look at the section of the spec
- 60-day review period before things are finalized
- (Lee) Are eIDAS deadlines driving this?
- (Brian Campbell) Desire to see implementations is a driving factor. Not sure if initial implementation will meet eIDAS deadline. Would love to see new query language in this draft but unclear if this will happen. Current state is probably too rough to make the deadline.
- (Marcos) Would be sad to see it ratified in its current state, it needs more time to bake
- (Brian Campbell) Likely implementable. There's definitely room for improvement, and there are likely entities currently working to implement it now. Current structure of "pipes" to request and receive data, while rough, is an attempt to document data specific to the protocol.
- (Marcos) Probably going to be a bit of a Wild West for a while.
- (BCampbell) What entity is processing and acting on the request? One perspective re: interop is that browsers just send the pipe —
- (Marcos) — but WebKit believes data needs to be checked and verified by the browser
- (Rick) Chromium is on the opposite side of the spectrum, okay to pipe back and forth as-is [disagrees in that this is minimally preferable to custom schemes which currently send all data without any verification]
- (BCampbell) Point of final specs are to reasonably "well-specify" the protocol
- (Sam) Point of concern: have we gathered enough implementation experience with an NSK (sp)? Do we have confidence to say that it's actually implementable?
- (BCampbell) Cannot meaningfully answer that question at this moment in time. Opportunity to implement against this API is minimal atm; implementation experience is generally limited as a matter of course
- (Sam) Pressure that puts on this group is to do the best as we can, make the API as stable as possible, within the 60-day review period? Annex A is possibly not entirely compatible with the spec.
- (Lee) But we have implemented it as of the Origin Trial this week. Might be a parameter that's wrong but it's not breaking; there's an E2E implementation internally. Used in LSPs in Europe to get decent amount of feedback in the coming months
- (BCampbell) Suspect you're right, Sam. Pressure is likely to try and ensure that specific details that are inaccurate are reconciled prior to finalization of these documents in OpenID. Whether we like it or not, there should be a perception of pressure to finalize an API without leading to incompatible implementations.
- (Sam) Any concrete date in mind to finalize things?
- (BCampbell) No date atm, "nearish-turn-of-the-year" keeping in mind 60-day review period
- (Sam) Please help us keep up with the timeline and report back
- (Marcos) W3C has public review + formal objection which needs to be addressed. What is the process like on the OpenID side?
- (BCampbell) Defer to Mike Jones
- (Mike Jones) Goal from DCP call on Sept 3 is to get final specs within the end of current CY. 60-day review period, 7-day voting period, one week of WG last-calls. Working back, "end of November" deadline means all PRs in by Sept 5. Believe there's no substantive difference between end-of-Nov and end-of-Dec so PRs should be raised in eight days. Date can slip. If you think something is broken in a normative way then file it now. Easier to fix things hastily now than during final review. Goal is to follow with a 1.1 update w/o breaking changes.
- Re W3C process vs OpenID process: OpenID process depends on member vote being in majority to pass spec. Exception for Board to throw if they believe that finishing the spec results in an IPR risk to the Foundation. Every member of OIDF has one vote.
- (Marcos) What's the point of the public review?
- (MJones) Provide feedback on editorial changes. Possible to make minor normative changes if there's strong consensus. Check-and-balance that WG didn't go rogue in some way. Compare it to OASIS; one spec got voted down by members. Never been a No-vote in OIDF.
- (Marcos) Is there a test suite?
- (MJones) There's a certification test suite that a bunch of people used in Germany this week. Not part of the WG process, but an effort to help the ecosystem interop.
- (Marcos) Using test suite over the browser codifies how the implementation works. Surprised that there is no implementation passing a test suite over a browser API still allows API to be ratified.
- (MJones) Test suites are admittedly good check and balance. OIDF believes in test suites, and interop and certification tests. Building those out requires talent to build out and maintain.
- (Nick Doty) "Finalized" is in the sense of "no breaking changes"? No possibility of how the system works?
- (MJones) "Immutable". The Working Group plans to do 1.1 versions of specs that add features. Just like in another OID spec, they cut a 1.0 to meet a deadline for Brazilian open banking regulations, making a 2.0 to take features out and implement things in a more secure way (and do things the way they actually want) but deadlines out of their control sometimes force WG's hand.
- (NDoty) Does presentation exchange need to be finalized at the same time?
- (MJones) Those are in a final document (sp) in the DIF WG (sp). "What about the new query language?" Current plan is to add it in 1.1 in a non-breaking way to get dev feedback before finalizing.
- (Lee) Would wallets have to support both?
- (MJones) Ecosystems can choose what to support.
- (RByers) None of us can delay eIDAS, oid4vp. We have power, though, to determine if Europe will use browser API or not. Looming deadline drove Chromium to decide to decouple, make API a "dumb pipe". Reserve right to make implementation changes over time; plan to make such changes rapidly, iteratively, not blocked by W3C process.
- (MCaceres) The less that's specified the better; that could be another approach. Simplify the spec, but it could lead to an interop mess.
- (BCampbell) What Rick said makes sense, but it's also an opportunity to look inside the pipe vs custom schemes.
- (TCappalli) Three directly-related sessions
- Monday — time to work out bigger issues, 15m at end to discuss "graduation" from WICG and how we want to do that
- Follow-up from last year's session, open discussion with larger attendance, to catch up on what's been going on, to air grievances.
- "Harmonizing identity-related web platform APIs": WebAuthn, WICG, FedCM, lots of same conversations going on related to errors, etc...Payments will be out of scope for all this. It may come up but the plan is not to dedicate time to it.
- Threat-modeling session
- (LCampbell) Will the graduation be ready by TPAC?
- (HFlanagan) When everyone agrees then FedID WG can be home for this. What does that "agreement" look like? Probably not ready by the 23rd, but "you'll have a home when you're ready"
Disallow multiple types via navigator.credentials's methods (CredMan:#244)
- (Marcos) Created separate namespace on `navigator` initially because CredMan allows multiple requests to go on at the same time. Turns out in practice that didn't really happen, only for passwords and federate credential and only supported by Chrome. At the same time that left a big space open in CredMan to bring some order to the realm of possibilities. Plan is to get rid of `navigator.identity` namespace and use `navigator.credentials` instead
- (Rick) Lots of discussion was had in the past, does it make sense to continue bikeshedding this?
- (Marcos) Yes, worth it, implementation wasn't as difficult as anticipated
- (Sam) We do have to be mindful of us approaching the point where we can't make backwards-incompatible changes like this
- (Marcos) We have good implementation experience from the browser side to give confidence in this proposal. Resolves a bunch of issues across multiple specs to hopefully make everyone happy.
- (MattM) Happy to see this change, makes a lot of sense to outsiders and helps have a single place to point people to.
- (Lee) Happy for this as it mirrors the Android changes. If we do these changes we have to do them now. What would the timeline be?
- (Marcos) I can put out a PR today
- (Rick) I emphasize I like the idea, but we just launched the Chrome origin trial for the next six months, won't change the API during the trial. Probably make `navigator.identity` an alias.
- (Lee) People will have to support the old name for the short-term, demo sites, etc…
- (Tobias) Combinatorial requests, are we dragging more work in as a result?
- (Tim) No, right now we're saying one-at-a-time while we identify simultaneous presentations.
- (Tobias) Will we throw an error if multiple requests are in-flight? (thumbs up received)
- (Tobias) As an implementer, will Chrome add the alias? Will Safari/WebKit alias `navigator.identity` as well or go straight to `navigator.credentials`?
- (Marcos) Intent is to implement `navigator.credentials` as quickly as possible.
- (Sam) Plan to implement quickly to stay 1:1 with WebKit. Probably update docs to point to more desired `navigator.credentials` while supporting `navigator.identity` during trial
- (Tim) Call to action to write content about Digital Credentials API for LINK TBD
Handling various origin types (#160)
- (Tim) Probably grab same text from WebAuthn for origin checks?
- (Marcos) Yeah, we could. Let's check and make sure we're not executing in a non-SecureContext somehow
- (Lee) When the OS passes down the origin to the wallet, on Android it's just a string. Is that enough? Debate during an in-person meeting indicated there might be more data needed.
- (Tim) Data doesn't need to be signed unlike in WebAuthn, so topOrigin, etc… can be determined by the browser.
- (Lee) Confirming that a simple string is sufficient
- (Tobias) Are we saying we'll treat origin specially, and additional client data will get defined later?
- (Lee) Even with a more robust clientData data, origin is needed for other verifications and is easier to pass as a string.
- (Tim) This should be an object even with only a single property
- (Tobias) If you drop origin into another data structure it becomes a single thing to protect
- (Tim) The thing we don't have is something like CTAP to define the abstraction layer between wallet and user agent
- (Lee) Where this impacts specs is like in OID4VP where "need to sign data", data is defined in another higher-level spec.
- https://austroadsinterop.com.au/
- Want to test the API
- Only mdoc (sp) for now
- Deadline for registration is Sept 6