Support Filtering by allow list in Conditional UI

[ChadKillingsworth]

Description

It is common for sites to re-confirm an already authenticated user's password to perform sensitive operations in an application - such as changing a username, two-factor auth setting or any other security related data point. Replacing this flow with user verifying authenticator credentials is required to fully eliminate password use.

As I worked on implementing Conditional UI, I realized that while the confirming credentials can only be for the currently authenticated user, Conditional UI provides no way to filter those credentials. Choosing the credentials of any user except the currently authenticated one will always fail.

While the Conditional UI explainer explicitly requires an empty allowCredentials list, it seems like this use case was not considered. In traditional password based flows, a hidden field with the username is utilized to hint to password managers which credential is being requested.

Conditional UI needs a method to filter or at least hint which user's credentials are acceptable for this use case.

Related Links

Without a Conditional UI hint, implementers will be forced to rely on some sort of browser state to prevent a negative user interaction which will incur all of the original problems leading to the development of the Conditional UI: #1356

[emlun]

If the scenario is that you already know the user's identity and their eligible credential IDs, what is the reason you cannot use the modal UI variant?

[ChadKillingsworth]

I can (and do) offer a button to manually trigger the modal variant of the UI with a provided allowCredentials list to filter to the correct IDs.

However it requires either:

• The user to know they have a credential and use the button to start the flow
• Keeping some sort of browser state to know that the user logged in with webauthn credentials and can therefore show the correct flow automatically.

As we have been testing the flow internally, the autofill box has a much higher discovery rate for users and is strongly preferred.

[Firstyear]

We should be clear it filters on user-id not the displayname.

I think it seems niche at first, but this use case will be important in many applications so I think it's good to support.

[lgarron]

For what it's worth, github.com has a "sudo mode" where this would be handy. https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/sudo-mode

We currently have an experimental feature to prompt for WebAuthn devices (security key or passkey) when the prompt loads, but we've been reluctant to enable that feature for all users. Since our goal is to make passkeys convenient and intuitive for all users, a feature like this could be nice — we would be able to rely on the "conditional" feature instead of having to explain to users what the WebAuthn prompt is and why it might instantly fail. Specifically, this could avoid a user reaction of "why did you even give me a button to show that prompt, if I can't actually use it?"

[emlun]

Ah - it wasn't clear to me what would be the risk if you already know that this particular user definitely has credentials registered, and thus is likely familiar with WebAuthn. But it seems the concern is that all of their credentials might be (non-synced) platform credentials on different machines than the current one?

[ve7jtb]

Wouldn't supporting the current credentialID allowlist pattern in Conditional UI be simpler than trying to add a filter on user-id?

[timcappalli]

I don't think the Autofill UI is the right pattern for the the step up use case. You generally don't show the user a username field to ask them to step up. The Autofill UI is designed to address initial sign in.

[ChadKillingsworth]

But it seems the concern is that all of their credentials might be (non-synced) platform credentials on different machines than the current one?

Yes. In general, the implementors (including myself) are very leery of launching the modal UI flow unless their is a near-guarantee that the user has a valid credential available. Since the spec is specifically written to prohibit this level of advance knowledge it makes it difficult to funnel users to the superior webauthn flows vs traditional passwords.

Wouldn't supporting the current credentialID allowlist pattern in Conditional UI be simpler than trying to add a filter on user-id?

Yes that would definitely solve the issue. I almost wrote that into the initial post, but didn't want to focus the issue solely on that solution.

I don't think the Autofill UI is the right pattern for the the step up use case. You generally don't show the user a username field to ask them to step up. The Autofill UI is designed to address initial sign in.

I'm not sure that is accurate. The webauthn Conditional UI autofill token is valid on both a username or a password input field. Conditional UI was designed to work around the privacy concerns of exposing to the user agent the existence of credentials in advance and the poor UI experience otherwise encountered by simply proactively launching the modal flow.

[timcappalli]

edit: I was convinced on the WG call that this is a good idea. Disregard :)

[Firstyear]

Yeah, since we are already authenticated as this specific user id, and we want re-authentication, we can use the user-id to filter credentials on the client rather than listing all user-ids and their credentials that match the rp id since a non-matching user-id would never succeed in this context.

[ChadKillingsworth]

There is another related use case as well: for systems where the username and password fields are on separate steps, it is a bit odd for the password autofill to list all usernames. It is the same basic consideration as the step-up auth scenario, but in this case the user is not yet authenticated.

Also in the separate steps scenario, using a credential from a different username does work (at least on my systems), but it seems like something that should be addressed.

In both cases, filtering by username (or even a allowCredentials list) works. On the un-authenticated version though, the username enumeration privacy considerations become applicable if allowCredentials is utilized for the filtering.

[MasterKale]

I've been out on vacation so I've only just now had a chance to read through this.

There is another related use case as well: for systems where the username and password fields are on separate steps, it is a bit odd for the password autofill to list all usernames. It is the same basic consideration as the step-up auth scenario, but in this case the user is not yet authenticated.

This resonates with Cisco specifically as we allow customers to use WebAuthn for SSO, but only after a username has been submitted to check if that user is authorized to use WebAuthn. If we could trigger Conditional UI after that authorization check to only prompt for credentials for the that approved user ID then we'd have so much more freedom to implement Conditional UI.

[timcappalli]

for systems where the username and password fields are on separate steps, it is a bit odd for the password autofill to list all usernames.

Why wouldn't the user select their passkey in step 1 / screen 1? In theory, you would only show the password field if the user did not select an existing passkey from the username field.