Support for immediate mediation for friction-less payment with SPC (in 1PC)

[tblachowicz]

As discussed during TPAC 2026, we'd like to consider adding support for immediate mediation as available in Chrome's origin trial¹.

In the context of SPC, when there is a passkey immediately available, the browser would launch SPC payment sheet / dialog right away without any user activation e.g. button click. The condition would be that the SPC is invoked with mediation: "immediate" by the RP (not cross-domain). Such approach would be particularly useful in 3rd party context, where RP would be loaded in iframe during checkout flow.

Footnotes

1. Origin trial: WebAuthn immediate mediation for frictionless sign-in ↩

[stephenmcgruer]

spec hat on

As per TPAC discussion, and having looked at the WebAuthn spec, there may be a few other requirements:

1. An empty allowList (e.g., an empty SecurePaymentConfirmationRequest.credentialIds). This is a shift from how SPC works today but is probably doable.
2. A user activation (because WebAuthn does for immediate mediation). Today SPC falls under Payment Request's optional user activation (which in Chrome is ~one "free" call to Payment Request per user-initiated navigation).

As a note (mostly to myself): We may not actually want to pass 'immediate' down to WebAuthn ourselves, since we only call it after showing UX anyway. Needs more thought, it might not hurt to just pass it in anyway (need to figure out the consequences).

[stephenmcgruer]

implementor hat on

As an implementor, I think this will be feasible in Chrome's current SPC implementations. The big shift is not having credentials to match against.

• On Android, we can silently query GPM for discoverable credentials (no need for the payment bit since this is first-party)
• On MacOS, we use the internal Chrome authenticator so can trivially query it for discoverable credentials (no need for the payment bit since this is first-party)
• On Windows, we can probably silently query for discoverable credentials and use that, but if not we may need to rely on the browser-owned storage of the payment bit (which might then require the payment bit even though this is 1p usage).

Non-trivial amount of work but not huge. But no timeline currently, to be clear :).

[stephenmcgruer]

cc @darwinlyang

[kenrb]

There are a couple of things that might be relevant to this group's discussion of Immediate.

First, Apple has proposed an alternative form of the feature out of concerns over the privacy implications of Immediate. With that change the get call would not resolve in the case that the user has no credentials or dismisses the dialog, so the RP would not get a signal that it should offer the user an alternative method. The Chrome WebAuthn team has not yet decided whether to change the implementation that is currently in origin trial. This might affect the use case that is in mind for SPC. (Separately, Apple's proposal would imply removing the requirement for user activation.)

Also, those privacy concerns might be more acute if this is adopted for SPC. The issue that has been raised in the WebAuthn discussion is that the RP can measure the timing of the rejection of the get promise to determine if UI was shown or not. If UI was shown, it tells the RP that the user has a passkey for the current site even though they didn't exercise it. Since SPC allows credentials to be used across origins, that could be a more meaningful information leak.