2024 11 18 Meeting Notes - WICG/digital-credentials GitHub Wiki

2024-11-18 (A Call)

Organizer: Tim Cappalli

Scribe: Wendy Seltzer

Agenda

Attendees

  • Tim Cappalli, Okta
  • Ted Thibodeau (he/him) (OpenLink Software)
  • Manu Sporny (Digital Bazaar)
  • Mohamed Amir Yosef (Google Chrome)
  • Zacharias Törnblom (SUNET, SeamlessAccess)
  • Joseph Heenan (Authlete/OIDF)
  • Ben VanderSloot (Mozilla)
  • Lee Campbell (Google/ Android)
  • Nick Steele (1Password)
  • Brian Campbell (Ping)
  • Hicham Lozi (Apple)
  • Wendy Seltzer

Notes

Administrivia

Tim: Reminder, participants need to join the WICG to participate in calls.

  • Dec. 25 and 30 calls are cancelled. So is Nov. 27. Next call will be Dec. 2
  • Simone: Charter has been sent to council, we await their review

Intros from any new folks?

  • None

Discussion

PR: Add initial content to Security and Privacy Considerations sections #189

Tim: Thank you Manu for starting a PR on security and privacy considerations. Has anyone gotten a chance to review? As we discussed last time, we just wanted to get something started.

Manu: I created 7 security considerations and 8 privacy considerations. Pulled titles from docs we link to; each has an issue marker noting what we intend to write in the future. People should feel free to go in and edit.

TIm: Thank you Manu. I would like to try to merge this soon, as this was one of the big blockers for getting the CG report out. Can reviewers give input by next call, December 2?

Simone: I can review, and Sec IG just formed

Tim: Please give feedback on the PR. Keep in mind it’s not deemed complete yet, but working to get thoughts in.

Issue: Relying Site/Verifier Lack of Scope or Restrictions #187

Tim: PRs. 187, restrictions around who can be a verifier. Use case of, what if I want to configure my browser… Do we need to specify that the wallet is also a user agent?

Manu: Language that clarifies 2 user agents is good. We probably need to make a decision about where the boundary of the browser or wallet begins and ends. DOes anyone want to argue that a verifier must strongly identify itself? Otherwise, the website can ask for anything. Can we say: there are 2 UAs? The boundary of what the browser will check is $X, other things are left to the user agent.

Tim: I’ll create an issue now, saying we need to map 2d UA to wallet. On boundaries, we need more discussion

Issue: Add a way to check what protocols are supported #168

Sam: We generally agree there should be a way for a website to test whether a protocol is supported in a way that works interoperably across browsers. Safari has taken a different approach from Chrome. Chrome’s architecture has been to be very unopinionated about what protocols are passed; let new protocols be introduced without registry entries; changes to protocol ok without requiring browser change. From an API perspective, a static object to test whether a protocol will be supported. What’s the best way to tell websites that Chrome will allow any protocol to pass through? If you have a getter, you could dynamically return true from Chrome; or

Tim: 2 questions. Expected usage. And the shape of the method.

Brian: 3 issues. One of the justifications for having the request API take multiple requests is that it’s unknown which protocols are supported.

Tim: Comment around realistic usability. In WebAuthn, we have request/response. If Chrome is going to return yes to everything, that’s useless.

Lee: I don’t see the need. Would I build this API for native apps? No. Do we have an is-supported? If it’s static, it’s "does this browser pass through", not “is there anything on the other side”.

Tim: I disagree slightly. Re WebAuthn, it’s not the browser supplying the passkey.

Lee: I think it's of limited value in the browser. I want the website to make the call. If you have detailed probing, you could have privacy leaks. Advice to RPs: make the call; you might get nothing back.

Manu: +1 to Lee. A static list doesn’t work because we expect things to be dynamic. The real question sites have — “will I get anything back” — is not wholly a function of the protocol. Query will return a big list of protocols, but that doesn’t really help the developer make a decision.

Sam: We probably need Marcos to represent himself here. If I try to paraphrase what I heard from him, Safari will be parsing the protocol requests. If they drop a parameter, will it fail to parse? Does the website still show a button? I don’t know the solution but I empathize with the problem.

Tim: I think it’s more valuable for issuance than presentation

Manu: Why can’t it be a part of the issuance API? I’m going to engage in an operation; what’s the next step?

Martijn: Not all of the statements made about Safari sound accurate; we need Marcos for better input. We think from a security perspective, it’s important that a WebIDL exists.

Tim: Older issue, where should we draw the line between what gets parsed

Sam: Marcos started this issue, should wait for him. I think it’s not a CG report blocker.

Mohamed: For issuance, we need to go through the platform

Tim: Capabilities-check with the platform is something we do with regard to passkeys. How deep do those criteria go? Is there a wallet? Does the wallet meet criteria?

Lee: It will probably return true for most cases, so useless.

Tim: But desktop might not have a wallet…When is the right time in the flow to fall back?

Lee: Maybe high-level. Is hybrid available, can the platform deal with it at all? These seem like fairly static bits for a given device. I’m worried about dynamic probing.

Hicham: Why do I need to know if a hybrid is available?

Tim: So as not to send user into an unsuccessful flow

Martijn: I don’t see why the website would need to know that

Lee: 2 choices: locally provided, remotely provided. If neither, RP shouldn’t go down the path. But that’s slightly different from probing what’s in the wallets. Does platform have the capability?

Manu: Asking, is the request going to hit a wallet? That’s not about protocols. “Will my request get to something that can actually answer the question?”

Tim: “I know this request can get to someplace it can be processed successfully”. Is there a wallet registered or not, I know that causes some privacy concerns, but there’s some precedent.

Manu: Can we update the issue? Not protocol support, but will the request be routed to something that can give a definitive answer.

Tim: I’ll create a new issue re: what capabilities are enumerable.

Protocol extensibility: where should we draw the line between what gets parsed and validated by the browser? #161

Tim: 161. Where should the line be drawn? Think we need Marcos’s input

Lee: isn’t this about splitting a request into formal parametrization and a blob that just gets passed through? Seems impractical at this point. If we’re just going to take a request blob and pass it through, then you just get a monolithic thing, and browsers can decide whether to look into it, route it. Platform might inspect to decide where to route. Don’t need to define it in WebIDL.

Tim: I think we largely closed on that.

Manu: There’s nothing stopping an implementation from looking into a request. We should probably note in the spec that that’s implementation-specific.

Tim: This would be in conflict with the request to have WebIDL in the spec.

Hicham: Is there room to discuss long-term, short -term? It’s useful to have simple types.

Manu: I think the protocols will need to settle for multiple years before we get there. Locking down in WebIDL would block needed experimentation, or trigger work-arounds. Don’t lock in prematurely.

Lee: Agree. Don’t think it's a problem we can solve in v1 of the spec.

Sam: What’s the best way to move forward? Do we have CG consensus?

Tim: I think we’re aligned. You opened this issue, if you want to summarize and close. Write a comment and tag pending-closure.

Hicham: Independent of WebIDL, it doesn’t mean opaque things should just be passed. WebIDL or not, requests still need to be well-defined.

Lee: Still needs to be a well-defined request. Something has to route it, so something has to parse it. That’s different from saying it needs to be in WebIDL.

Tim: I think we’re also looking at 152, Marcos’s version of the issue.

Sam: I’ll mark the other as duplicate and tag both.

Tim: Look at issue 136 for next time.

Simone: AOB, response to European inquiry on timeline. FPWD in March? When would we expect to have a Recommendation?

Tim: That depends a lot on formal objection processing. If we keep issuance out, the reviews will be the bulk of the time I expect. Does anyone think we’ll take more than a few months to get all the spec text?