-
Notifications
You must be signed in to change notification settings - Fork 9
2024 01 29 Meeting Notes
Organizer: Tim Cappalli
Scribe: Wendy Seltzer
- Administrivia
- Intros from new folks
- Updates from Blink incubation
- Any updates from Google / Chrome team / Apple teams?
- Anyone prototyping with their wallet or verifier?
- Live discussion: “Requirements and Objectives” #52
- Is "requestIdentity()" the best method name?
- Registry inclusion criteria
- AOB
- Lee Campbell(Google/Android)
- Rick Byers (Google Chrome)
- Dirk Balfanz (Google)
- Hicham Lozi (Apple)
- Tim Cappalli (Okta)
- Wendy Seltzer (Tucows)
- Sebastien Bahloul (IDEMIA)
- Andrew Regenscheid (NIST)
- Loffie Jordaan (AAMVA)
- Nick Doty (CDT)
- Ryan Galluzzo (NIST)
- Torsten Lodderstedt
- Brian Campbell (Ping)
Torsten: co-author of OpenID4vc family with Kristina; and German wallet project
Tim: Disclosure, I’m now at Okta.
Rick: Patches have started to land in webkit. We should add that to the updates from incubation.
Tim: I’ll add a link post-call >> https://github.com/WebKit/WebKit/pull/23034
https://github.com/WICG/digital-credentials/issues/52
Tim: hoping we can get to closure. Anything for live discussion?
Torsten: Surprised to hear that you think this has been covered. Need clarity to guide the group. It’s still unclear to me what you want to achieve. Think we don’t need to define a new protocol to move credentials, but to find a wallet. Currently, reliance on custom links, has poor security properties. Could build a solution that works for many existing protocols and wallets. “Get an endpoint to an existing wallet.” Not competing with existing protocols, but cooperating with them.
Tim: Level-setting, I don’t think we’re trying to define a new protocol, but a new binding. Oct/Nov/Dec We could use the openID4VC redirect binding, were waiting on OpenID group for profile.
Torsten: at IIW, I designated DNS and proxy options.
JohnB: Lee’s document hasn’t yet been contributed to the doc
Lee: waiting until mid-Feb to get time in OpenID. Would submit then
Torsten: I’m here as an individual raising concerns. I haven’t been part of those discussions. Why can’t we get an alias method that gets a protocol endpoint Lee: anything that reveals the identity of the wallet is a non-starter. If you get back a package name of the app, that’s not a good model because it reveals wallet identity. Principles, the proposed models align pretty well with your comment. 2 parameters: protocol name and request field. Goal to replace custom URL schemes, invocation. This API doesn’t define what’s in the request. We’re doing the plumbing, RP website to wallet. Leaving it cred format agnostic.
Torsten: Internet analogy: instead of providing DNS server, we’re sending all traffic through one component, so as not to reveal IP address. That puts browser as chokepoint, think we need to discuss further.
Rick: Apologies for not posting on the issue sooner. Discussed at TPAC, dropped link to presentation. Talked with PING. No way we can get feature in the browser that gives users less control of how their identity is being shared. Part fo our value prop as browsers is defending user privacy. We need to understand enough about the request to get meaningful consent.
Torsten: Not trying to invade privacy. “Find a wallet” is not PII. Question is who is going to gather that consent.
Rick: We don’t want to control the user experience. Want to have checks for user. Speaking for chrome, we think that’s part of our role, don’t think we can delegate to apps for something as sensitive as gov’t ID.
Lee: we all agree
Torsten: there are regs to assure user privacy. In EU, it’s clearly role fo the member state to ensure that everything goes right, not the role of the tech provider.
Hicham: Good question to discuss. Protocols were designed without considering availability of browser API. they have many elements that aren’t necessary if API exists. We’re discussing making it more available, more secure. Dont’ see competition, but simplification, security.
Torsten: if browser API can be easier, more secure, that would help to convince me. Haven’t yet seen that proof of superiority. We’ve been working 3+ years. Suggest incremental improvement
Tim: Last time we were deeply engaged was IIW session. Think you left that session with mockups. Implementation is not part of the spec.
Torsten: Open to working on it, not yet convinced it’s the right approach.
Tim: This work is supposed to be about experimentation
Torsten: on-board with experimenting. I think the DNS-based model is more likely to help us solve problems faster than proxy model. We’re rolling out implementations across EU. It’s too late for browser API. perhaps for EIDAS3
Lee: I think it’s not too late. We’re advising that building anything around custom URL schemes is not going to scale.
Torsten: this is not a simple replacement of custom schemes. Defining a new API will take years.
Lee: think we can get origin trials this quarter, draft spec by end of year. Looking at user and developer experience, building for long-term. DNS-model, we think developer and user experience won’t be good. We can do credential selection, browser UI needs something in the request.
Torsten: disagree with assumptions
Lee: In a world with multiple wallets, need to select among them, you have a way with no UI to select among them?
Torsten: people are implementing European digital identity wallets.
Lee: Trying to replace custom schemes. API with two fields, accommodate existing protocols. Some people wanted to reimplement OpenID, we didn’t do that. Developer ergonomics. Forward to the wallet. When the browser API is on the table, can build a superior user and dev experience, on top of existing work. Alternative to custom URL scheme.
Hicham: We’ve been discussing browser API for years. API just to replace custom schemes is not a good idea, since those protocols were developed pre-browser-API. Schemes are a problem, not the only problem.
Rick: We have to assume that the existing design will be out in the wild. What’s already defined will be in production. Aiming to solve the whole problem, not just part. UX and privacy and security threats. As pointed out by constituents such as W3C TAG. Think we’re on same team, helping citizens who are concerned about sites requesting their government ID. In US, seeing move to age verification. Point of this group is to find intersection fo our goals. Think we have agreement around improved UX, reducing MITM opportunities. We have additional concerns as well.
Torsten: Please share pointer to security and privacy concerns.
Torsten: Lead German EIDAS wallet implementation. Germans are suspicious of data flows on Internet, need to secure flows. Difference in where we think that assurance is done.
Kristina: Would be good to explicitly agree that Increment1 and Increment2 are in scope. 1, existing protocols can use this API to get wallet endpoint; 2 is an alternative protocol. If you’re not using redirects, but passing openid syntax over the browser is a different protocol. Lee and Hicham’s responses sound different. While we all want privacy, different ways to accomplish. Narrative that browser API can make it much more privacy preserving should be clarified.
Ben: Custom scheme will be what we rely on until we’re ready to implement API. Moz is going slower. Trusting the wallet entirely to control user info flow is challenging, particularly from US perspective, where there aren’t great data protection rules and states are implementing wallets, worried about state surveillance.
Torsten: in EIDAS ecosystem, there will be multiple wallets, where users can pick.
Benjamin: we’re looking globally
Sam: Do you think there are certain circumstances where wallet chooses not to reveal itself to verifier. E.g. if I’m revealing an event ticket, don’t want to share my national wallet that shares my nationality.
Torsten: Valid point. Could also ask, should a website know what UA I’m using to browse the web? What are the consequences of decisions.
Sam: Let’s try to write down properties, then prioritize.
Torsten: Add to Rick’s security and privacy doc.
Sam: Then ask, Does it stand on its own in terms of added complexity,
Lee: Privacy review, internal at Google, unlikely to pass with a design that implicitly reveals identity of wallet at every presentation.
Rick: When shipped, we’d expect a huge volume of requests for age verification for adult websites. Need to consider privacy for users in that context.
Kristina: Crypto signing, etc. will still be done by wallets. Concerned to hear that if two implementers concur, PRs will be merged even if others disagree.
Lee: in terms of attestations, wallet attestation during issuance, ok. Issuer vetting wallets. When an RP requests e.g CA Drivers License, implicitly learn that the wallet responding meets requirements of issuer. Even for enterprise use cases where you want to attest wallet, ok for protocol to allow. Enable but not mandate wallet attestations. General case, wallet ID shouldn’t be revealed. Response can contain anything, including possibly attestation of wallet identity.
Sam: We’re a community, we choose our mode of operation. Suggest that 2 browsers to merge is a necessity, not sufficiency condition.
Tim: that came from W3C WG mode, require 2 implementations to move forward. Happy to entertain proposals to write more process. Torsten talking to Rick on doc, keep comments going on the issue.
Torsten: Thank you for taking the time. One aspect of the API, is this group focusing on presentation only, or also issuance? I think it’s mostly presentation
Lee: Think it’s presentation first, but not solely. At some point, expecting to deal with issuance as well. Hear you saying both need to go together. Seeing that there’s already (in US) issuance, but not yet presentation. Ordering, not exclusive.
Tim: Make sure we’re not doing anything inconsistent with issuance. Torsten: Thanks. Is there a charter?
Tim: This isn’t a group, a WICG work-item, incubation of web APIs. Once discussion proceeds, potential move to dedicated CG, formal WG. e.g. FedCM, 2 years of CG, then moving toward WG. Feedback was that a dedicated CG would slow things down.
Hicham: Happy to help with the doc re security and privacy.
Rick: Link in the slack @@ to add to notesN@@
Tim: Next call will be Wednesday