Re: [webauthn] Allow immediate mediation (#2228)

> I can see how the shape of what I’m proposing for “immediate” and the ambient proposal are isomorphic, but since the intended use case and behavior in the UA are so different, they’re different, right?

Spec-wise, I think the main difference is that Immediate is currently designed to be modal while Ambient is non-modal. The exact UI is implementer dependent. It seems like it might end up being used for the Ambient use cases, regardless of spec author intent.

> I think in some testing that Google did in the past, having sign-in related content behind browser UI actually improved sign-in success rates.

I'm not aware of this testing. Do you have more details?

> Can you tell me more about what isn’t possible without the feedback to the RP?

I think what you are asking is what advantages are there to a primitive that enables "prompt for a passkey sign-in if one is available, or else do something else" over a primitive that enables "do something else, and then prompt for a passkey sign-in if one is available". Here, 'something else' can be a navigation to a form-based sign-in page or adding a sign-in frame/iframe, but there are other possibilities like [initiating a guest checkout flow on an e-commerce site](https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation#contextual-sign-in-moments).

We have heard from RPs that they believe the reduced friction is important. In some cases it removes the need to take the user out of the current context. In general it prevents having to show additional site UI that is not relevant to the user. If you'd like further elaboration on that then I can reach out to some RP developers to comment.

-- 
GitHub Notification of comment by kenrb
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2228#issuecomment-3444777127 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 24 October 2025 20:20:45 UTC