Skip to content

Add Immediate uiMode#2291

Open
kenrb wants to merge 16 commits intow3c:mainfrom
kenrb:immediate-mediation
Open

Add Immediate uiMode#2291
kenrb wants to merge 16 commits intow3c:mainfrom
kenrb:immediate-mediation

Conversation

@kenrb
Copy link
Copy Markdown
Contributor

@kenrb kenrb commented May 6, 2025

This specifies the behaviour of the mediation: 'immediate'.

Issue: #2228
Explainer: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation

Parallel PR adding the enum to Credential Management: w3c/webappsec-credential-management#272


💥 Error: 422 Unprocessable Entity 💥

PR Preview failed to build. (Last tried on Apr 22, 2026, 6:35 PM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build bikeshed/ReSpec specs

🔗 Related URL

Error output:

[
    {
        "lineNum": "2058:21",
        "messageType": "fatal",
        "text": "Tried to auto-close a <li>, but there were unclosed elements remaining before the nearest matching start tag (at 1914:5).\nOpen tags: <div> at 1696:1, <li> at 1914:5, <dl> at 1917:9"
    },
    {
        "lineNum": null,
        "messageType": "fatal",
        "text": "Line 2357 isn't indented enough (needs 1 indent) to be valid Markdown:\n\" <a bs-line-number=\"2360:10\" bs-autolink-syntax=\"[=transient activation=]\" data-link-type=\"dfn\" data-lt=\"transient activation\">transient activation</a>, throw a \"<code bs-line-number=\"2360:46\" nohighlight=\"\" class=\"idl\"><a bs-line-number=\"2360:45\" bs-autolink-syntax=\"{{NotAllowedError}}\" data-link-type=\"idl\" data-lt=\"NotAllowedError\">NotAllowedError</a></code>\" <code bs-line-number=\"2360:67\" nohighlight=\"\" class=\"idl\"><a bs-line-number=\"2360:66\" bs-autolink-syntax=\"{{DOMException}}\" data-link-type=\"idl\" data-lt=\"DOMException\">DOMException</a></code>.\""
    },
    {
        "lineNum": null,
        "messageType": "fatal",
        "text": "Line 9113 isn't indented enough (needs 1 indent) to be valid Markdown:\n\"are other reasons why it might reject the promise quickly, but not having a credential is likely the most common.\""
    },
    {
        "lineNum": null,
        "messageType": "fatal",
        "text": "Line 9115 isn't indented enough (needs 1 indent) to be valid Markdown:\n\"given Relying Party, even if the user does not choose to authenticate with that credential.\""
    },
    {
        "lineNum": "8576",
        "messageType": "warning",
        "text": "The heading 'Well-Known URI Registration' needs a manually-specified ID."
    },
    {
        "lineNum": "8396:5",
        "messageType": "lint",
        "text": "Unexported dfn that's not referenced locally - did you mean to export it?\n<dfn bs-line-number=\"8396:5\" data-dfn-type=\"dfn\" id=\"set-user-verified-parameters\" data-lt=\"Set User Verified Parameters\" data-noexport=\"by-default\" class=\"dfn-paneled\">Set User Verified Parameters</dfn>"
    },
    {
        "lineNum": null,
        "messageType": "failure",
        "text": "Did not generate, due to errors exceeding the allowed error level."
    }
]

This seems to be an issue with the Spec Generator service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can report the issue to the maintainers of Spec Generator directly. Please be courteous. Thank you!

If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can file an issue with PR Preview.

kenrb and others added 6 commits April 29, 2025 20:56
This PR adds the Immediate Mediation mode for WebAuthn requests,
which shows discoverable credentials to the user if any are
silently found, or else throws a `NotAllowedError` if there are
none.

See the
[explainer](https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation) for more context.
A parallel PR to add the mode to the Credential Management
specification will be created.
@kopy
Copy link
Copy Markdown

kopy commented May 8, 2025

While I understand the privacy considerations underlying AllowList limitations, requiring explicit user activation significantly restricts practical usability at scale for this scenario:

  • Direct use on standard login pages (typical scenario for most websites) is the main issue addressed here. If an email input field is already visible, requiring further user activation for immediate mediation becomes unintuitive, as the user may have already started typing their email. A lot of websites have a profile or menu and not a "sign-in button" on the upper right or use "layers"

Removing the strict requirement for explicit user activation, aligning with existing first-party WebAuthn implementations, would substantially enhance usability. Immediate mediation could then seamlessly activate upon page rendering, offering a smoother authentication experience before users interact with input fields. Notably, every native implementation that supports preferImmediatelyAvailable—such as on Android and iOS—do not require a user activation.

Currently, adopting this approach broadly would necessitate extensive UI and workflow adjustments. Furthermore, login pages often redirect users to relying-party single sign-on systems, making UI changes challenging and potentially disrupting existing authentication workflows.

@Firstyear
Copy link
Copy Markdown
Contributor

Having webauthn prompts randomly trigger on a page load with no explanation or context for users, sounds like the exact opposite of good UX to me - it sounds a lot more like a path to confusion and frustration.

@kopy
Copy link
Copy Markdown

kopy commented May 8, 2025

Having webauthn prompts randomly trigger on a page load with no explanation or context for users, sounds like the exact opposite of good UX to me - it sounds a lot more like a path to confusion and frustration.

This could still happen after the user navigates to the login page or exactly where it does now. It’s not random we leave it up to RPs - we had this exact same dicussion with WebAuthn user gestures for Safari and they were lifted. As someone responsible for large consumer RP implementations, I have problems seeing clearly how this approach helps for most pages.

@kenrb
Copy link
Copy Markdown
Contributor Author

kenrb commented May 9, 2025

This could still happen after the user navigates to the login page or exactly where it does now. It’s not random we leave it up to RPs - we had this exact same dicussion with WebAuthn user gestures for Safari and they were lifted. As someone responsible for large consumer RP implementations, I have problems seeing clearly how this approach helps for most pages.

The main advantage of not having a user gesture requirement for existing modal WebAuthn calls is that they can be used for re-auth, a use case for which immediate mediation isn't useful.

Immediate is aimed at scenarios in which a user has done something to indicate a sign-in is appropriate at that time. This isn't precisely replicating preferImmediatelyAvailableCredentials on mobile because the web has different privacy properties.

There is a separate proposal for a mode called Ambient, in which more subtle (non-modal) UI is displayed to offer the user an opportunity to sign-in, and would not require user activation. https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Ambient-Signin-UI

That proposal is still active.

@kopy
Copy link
Copy Markdown

kopy commented May 12, 2025

This could still happen after the user navigates to the login page or exactly where it does now. It’s not random we leave it up to RPs - we had this exact same dicussion with WebAuthn user gestures for Safari and they were lifted. As someone responsible for large consumer RP implementations, I have problems seeing clearly how this approach helps for most pages.

The main advantage of not having a user gesture requirement for existing modal WebAuthn calls is that they can be used for re-auth, a use case for which immediate mediation isn't useful.

I see your point, but my comment referred to the fact that continuously triggering WebAuthn requests hasn’t yet emerged as a significant abuse issue. WebKit also moved away from enforcing user gestures for WebAuthn, recognizing that plenty of alternative approaches are available to effectively rate-limit such behavior. For example, I can see why this is useful in cross-origin iframes.

Immediate is aimed at scenarios in which a user has done something to indicate a sign-in is appropriate at that time. This isn't precisely replicating preferImmediatelyAvailableCredentials on mobile because the web has different privacy properties.

There is a separate proposal for a mode called Ambient, in which more subtle (non-modal) UI is displayed to offer the user an opportunity to sign-in, and would not require user activation. https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Ambient-Signin-UI

That proposal is still active.

I am aware; thank you, @kenrb. I greatly appreciate Chrome’s efforts to improve the passkey experience. Immediate mediation is helpful, but only precisely for the UI case you mentioned - it’s just challenging for some RP implementations. I was simply suggesting making it more broadly applicable; perhaps the ambient proposal would be better suited.

@zacknewman
Copy link
Copy Markdown
Contributor

Do we want an error to occur if an RP uses immediate mediation during credential registration, or is it sufficient to effectively treat it as an unknown enum value which in turn is treated as required?

kenrb added 2 commits November 5, 2025 16:29
Added uiMode. Also expanded the privacy section.
@nsatragno nsatragno self-requested a review February 3, 2026 15:07
Comment thread index.bs
Comment thread index.bs Outdated
Comment thread index.bs Outdated
Comment thread index.bs Outdated
Comment thread index.bs Outdated
Comment thread index.bs Outdated
Comment thread index.bs Outdated
Comment thread index.bs Outdated
Comment thread index.bs
@kenrb kenrb changed the title Add Immediate Mediation Add Immediate uiMode Feb 4, 2026
Copy link
Copy Markdown
Contributor Author

@kenrb kenrb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated the PR incorporating @nsatragno's comments

@MasterKale
Copy link
Copy Markdown
Contributor

Is there something going on higher up in CredMan that led to this option becoming a seemingly new uiMode option instead of using mediation? And are there any plans brewing to migrate current use of mediation to uiMode instead? It's very non-obvious why this new execution mode is moving away from mediation, and I'm wondering if there's more to the story.

Comment thread index.bs Outdated
Comment thread index.bs Outdated
Comment thread index.bs
"conditionalCreate",
"conditionalGet",
"hybridTransport",
"immediateGet",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this PR title should be updated to something like "Add Immediate Get" to better convey that this PR is only about updating .get().

@MasterKale
Copy link
Copy Markdown
Contributor

Ah I just saw w3c/webappsec-credential-management#272 maybe I'll take my comments thither

Copy link
Copy Markdown
Member

@nsatragno nsatragno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved, but this shouldn't land until w3c/webappsec-credential-management#272 lands.

Change `CredentialUiModeRequirement` to `CredentialUiMode`, reflecting the same change in the Credential Management PR.
kenrb added 3 commits April 2, 2026 15:19
Remove the requirement to consume the transient user activation during an Immediate mode Get request.
Remove requirement for Immediate mode requests to consume user activations (attempt w3c#2).
Comment thread index.bs Outdated
and [=set/remove=] |authenticator| from |issuedRequests|. Throw a "{{NotAllowedError}}" {{DOMException}}.

: If <code>|options|.{{CredentialRequestOptions/signal}}</code> is present and [=AbortSignal/aborted=],
: If <code>|options|.{{CredentialRequestOptions/signal}}</code> is present and [=AbortSignal/aborted=], and <code>|options|.{{CredentialRequestOptions/mediation}}</code> is not {{CredentialMediationRequirement/immediate}},
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is incorrect. This should be <code>|options|.{{CredentialRequestOptions/uiMode}}</code> is not {{CredentialUiMode/immediate}}

@timcappalli timcappalli self-requested a review April 22, 2026 18:17
@akshayku akshayku self-requested a review April 22, 2026 18:19
@nadalin nadalin requested review from pascoej and ve7jtb and removed request for akshayku April 22, 2026 18:19
@nadalin nadalin added the tag-tracker Group bringing to attention of the TAG, or tracked by the TAG but not needing response. label Apr 22, 2026
Replaced some incorrect references to  `CredentialMediationRequirement`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

tag-tracker Group bringing to attention of the TAG, or tracked by the TAG but not needing response. type:technical

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants