Web Payments Working Group

Chrome implementation updates

Ian: The Chrome team announced recently that Chrome 139 on Android now supports BBKs and the new UX out of the box. Stephen, any updates on timing for desktop support of BBKs and UX?

smcgruer_[EST]: We anticipate late 2025 or early 2026, though we hope to show off at least one desktop implementation at TPAC in November
… we also want to talk about iOS at TPAC
… we think there's a path for supporting chrome on iOS but plan to say more concretely at TPAC.

Henna: When you are doing the feasibility study on iOS, what are the options under consideration?

smcgruer_[EST]: We looked first at landing patches directly to Webkit but have not received responses.
… we then started looking at creating a shim in Chrome on top of WebKit
… and I think the latter path has more likelihood of success.

Authenticators and SPC

New document: Authenticators and SPC

Ian: Following initial work by the Chrome team to describe the landscape of platform authenticators and SPC, Stephen and I elaborated on that material to create more of an introduction and framing. The new document is Authenticators and SPC and we hope that it both helps explain the problem space and also provides a framework for prioritizing next steps in terms of expanding support for authenticators that work with SPC.

Bjorn: How would you like to get feedback?

Ian: Good question. I'll open an issue for receiving prioritization suggestions, and people can do pull requests to help improve the document.

ACTION: Ian to open an issue regarding prioritization (and mention pull requests for the doc)

UX guidelines documentation pull request

smcgruer_[EST]: We ported information from the issue into a standalone document.

ACTION: Daniel Wyckoff to review the UX documentation for SPC

ACTION: Bjorn Hjelm to have someone from the Yubico UX team review the UX guidelines document.

smcgruer_[EST]: There are mockups in the repo that don't use company names

Action item checkin

(Checking on progress to revise presentation to focus on high assurance login)

Jean-Luc: Might refocus on requirements

Ameliorate the need for re-authentication upon re-creating BBKs

SPC issue review

Ian: Any updates on the conversation about reducing double step-up? (issue 287)

smcgruer_[EST]: We are still thinking about the issue that was raised (slowdown due to holidays)

fahad: No updates from my side either, but this appears more to be a "DOS" type attack. Still haven't figure out how to resolve it yet.

Support for multiple RPs in the Payment Request API for SPC (Issue 310)

fahad: When you call PR API today to call SPC, you can pass multiple credential ids, but they are all linked to the same RP.
… the question is whether credentials from multiple RPs could be provided as input

Ryan: We're also looking at the "allow BBK" solution
… this might provide an interface opportunity here as well

Ian: Could this be addressed by serializing the request (and just having one UX either fallback or authentication)?

smcgruer_[EST]: As explained in the Authenticators and SPC document, some approaches to determining whether a credential is immediately available involve sending a query to an authenticator which may trigger a Web Authentication (even if there is no matching credential). Because the authenticators do not handle more than one RP, we would need to send multiple queries, which would trigger multiple Web Authentication flows.

Henna: I think you are right; we need to think about how to structure the ask to WebAuthn
… the browser figuring out what credentials are available is a better path
… also, we have a "related origins" concept. Could that help?

Ryan: It is probably not related origins. This is likely a use case where entities are very different.

https://github.com/w3c/webauthn/wiki/Explainer:-Related-origin-requests

Ian: Is there value in presenting the payments use case to drive feature evolution?
… e.g., payments use case to drive listing (also used for immediate mediation)