WebAuthn Autofill (Conditional UI) for credential registration

[nov]

Description

We're starting WebAuthn support, heavily relying on WebAuthn Autofill UX.
However, WebAuthn Autofill is only available for authentication, not registration.

We'd be happy if we can let password managers register WebAuthn credential in a way similar to what password manager registers strong password via Autofill UX.

Related Links

[emlun]

What would be shown in the autofill UI in this case?

[nov]

"iPhone created a strong passkey for this site" or something?

[serianox]

"strong passkey" implies "weak passkey".

Though I'm pretty sure some will have an ECDSA keygen failure sooner or later. 😅

My opinion would be to have a "Use Passkey" button, and have a dimmed "Use Strong Password" and "Choose My Own Password" links below.

[timcappalli]

Today, you have to land on a page to create a password. That page could either be the same page where other account details are requested or it could be a dedicated password page as shown in your example.

In the first one (a registration page), you can just call WebAuthn when the user clicks "Create account".

For the second one, you ultimately need to get the user to the "create password" page. So instead of a top level nav, just directly invoke WebAuthn on that link / button instead.

I don't see a scenario where conditional UI is needed for registration.

[nov]

"iPhone created a passkey for this site" should be fine.

When user authenticates via WebAuthn Autofill, they won't distinguish whether they are authenticating by password or passkey.
I'd want the same level of seamless UX on registration.

I don't want to put both "create passkey" button and password input field in the flow.
I'd like to password manager create passkey when user focused on the password input field on the registration page.

[timcappalli]

Why would you ask for both a password and passkey at the same time? If you want the user to create a passkey, and the platform supports passkeys, there shouldn't be a password field shown to the user.

[nov]

We can use the same layout on login page because of WebAuthn Autofill feature.
Why do we have to have the different layout on registration?

I'm not asking to create password AND passkey at the same time.
I'm asking password managers to create password OR passkey, without changing page layout, and without letting users think about "should I create passkey or password?".

[timcappalli]

Why do we have to have the different layout on registration?

In most cases, you're asking for different information on a registration flow vs a sign in flow. But even in that case, if the platform supports passkey, your "create account" button (or whatever your button says) can just result in calling WebAuthn. The user doesn't have to think about it.

[nov]

In that case, users have to see the special WebAuthn dialog, so they have to understand what it is.
In WebAuthn Autofill login UX, users really don't notice whether they're logging-in w/ password or passkey.
I want the same level of seamless UX for registration.

[Kieun]

WebAuthn registration flow requires other mandatory information comparing to password registration to create the key. Typically, the auto-fill is triggered by the user and the challenge is provided when the page loads. So, before populating the challenge, the web page should somehow knows the such information. It might be possible to offer such features, but I'm not sure how the user interacts with it.
While deploying passkey into the system, it's hard to communicate with the customers by just leveraging platform provided UI (or guide) at the moment. So, including us, many RPs describes and introduces what passkeys (webauthn credentials) are in the registration page.

[nov]

many RPs describes and introduces what passkeys (webauthn credentials) are in the registration page.

I believe that's why FIDO is not widely adopted for years.
As an RP, we don't want to explain it.

[timcappalli]

In that case, users have to see the special WebAuthn dialog, so they have to understand what it is.

Users will always see the platform's passkey dialog, regardless of how they enter the flow. Autofill UI doesn't change that.

I believe that's why FIDO is not widely adopted for years.

In my experience, that is not true.

As an RP, we don't want to explain it.

You don't have to explain it. Instead of a "Create account" button that just form POSTs, call WebAuthn there as well. The result will be the same as if there was an autofill UI and the user clicked it.

I'd actually argue that autofill UI for registration would make this more confusing.

Possible today:

if (passkeysSupported) {
    showPasskeyEnabledCreateButton();
} else {
    showPasswordSection();
    showRegularCreateButton();
}

passkeyEnabledCreateButtonSubmit() {
    getChallenge();
    webAuthnCreate();
    postCompleteResponse();
}

(just pseudocode obviously)

[MasterKale]

I agree that autofill UI for registration would probably create more confusion than during auth. The typical autofill UI experience is a user either:

1. Chooses an entry from the autofill UI
2. Starts typing, at which point the autofill UI disappears

If we assume a simple passkeys-first signup form like this...

...I can't see how autofill UI would fit into this experience. Users should specify their username/email address before creating a passkey, so the RP can populate user.name in registration options, but this means typing that in which means autofill UI would disappear once the user starts typing. I guess autofill here might recommend a username/email to enter (based on common ones you've used before?), but this isn't a current capability of any autofill UI I've used in a browser anyway.

[nsatragno]

I agree with Tim and Matthew that this feature would not be all that useful. We discussed this at the working group meeting today, and agreed to close this issue. To summarize,

• Relying parties can provide more or less the same experience by adding a button that triggers a webauthn registration with the text of their choosing. They can show or hide the button depending on conditional mediation, isuvpaa availability, or any other inputs depending on their policies, instead of delegating its presentation to the browser.
• The relying party needs to provide a user's name and displayName, and it would be awkward to do so when autofilling the same registration form.
• Conditional UI solves the problem of not knowing in advance if your user has passkeys or not, but this problem does not exist during registration.