Add support for WebAuthn's conditional create

[MasterKale]

Describe the issue

At WWDC 24 this week Apple debuted macOS Sequioa Dev Beta 1, which includes Safari 18.0 Beta. According to the WebKit blog, Safari 18.0 Beta supports "conditional create" added to WebAuthn L3. This is what Apple is referring to when it mentions "automatic passkey upgrades."

This new capability allows an RP to "silently" trigger a passkey registration after a successful traditional authentication (i.e. username+password auth) without the user needing to click through any browser modals. From that point on the RP could switch the user to passkeys at the next login.

Supporting this isn't much different than supporting conditional UI during auth; it's an otherwise normal call to navigator.credentials.create() with some specific options passed in. I can easily add such a capability to @simplewebauthn/browser's startRegistration() method similar to how I added conditional UI support with startAuthentication(..., true).

Additional Resources

Safari flow chart for when an RP can trigger conditional create:

• https://webkit.org/blog/15443/news-from-wwdc24-webkit-in-safari-18-beta/
• https://w3c.github.io/webauthn/#sctn-createCredential
• https://developer.apple.com/wwdc24/10125?time=38

[lmarschall]

Hey @MasterKale,

a few months ago, I was trying to implement the conditional UI flow with the browser package, but I wasn't able to get it working properly without eventual fails.

https://simplewebauthn.dev/docs/packages/browser#browser-autofill-aka-conditional-ui

As you described here, we should add the startAuthentication workflow in the head section or let the UI wait some n seconds, is this workaround still required, or are there any better solutions, because I find it quite unpleasant to implement the startAuthentication in the head section or wait n seconds :disappointed:

[lmarschall]

@MasterKale

Would it be possible to create a new passkey on login with an existing passkey, with Conditional Create, as well?

[MasterKale]

As you described here, we should add the startAuthentication workflow in the head section or let the UI wait some n seconds, is this workaround still required, or are there any better solutions, because I find it quite unpleasant to implement the startAuthentication in the head section or wait n seconds 😞

Good question @lmarschall, let me ask around and see what the consensus is.

Would it be possible to create a new passkey on login with an existing passkey, with Conditional Create, as well?

Hmm, conditional create in the L3 draft says this...

It is up to the user agent to decide when it believes an authentication ceremony has been completed. That authentication ceremony MAY be performed via other means than the Web Authentication API.

Which means the answer is "maybe, but it's up to the browser" 🤔

[lmarschall]

@MasterKale Sound great, I'm looking forward to tinker a bit with the conditional create workflow, presenting users with only one webauthn dialogue in the browser when switching devices would be awesome.

[MasterKale]

I'm gearing up to tackle this Soon™ and realized that I need to consider how to allow the user presence bit to be false. Conditional create makes this a first for WebAuthn; it's otherwise required to be true.

[MasterKale]

I need to add a new option to startRegistration() like useBrowserAutofill in startAuthentication(). For those following this issue, I need to decide on a name for the new option. This is a flag to "silently request the creation of a WebAuthn credential from the password manager (which is also a passkey provider) that the user just used to facilitate login."

Potential candidates include:

• silentlyCreate
• useAutomaticUpgrade (very Apple-centric though; maybe I try to coin a new term?)
• useQuietCreation maybe? 🤔

I'm open to suggestions.

[lmarschall]

Maybe useCredentialsUpgrade gives a more broader term for this use case, because in the end an authenticated users credentials gets upgraded to passkeys.

[MasterKale]

I went with useAutoRegister in #623, this'll go out as part of a v11 major release (after I close another issue or two)

[MasterKale]

@lmarschall Check out the new @simplewebauthn/[email protected] - startRegistration() has the new useAutoRegister option that should enable use of conditional create.

Just a heads up, the API of startRegistration() changed to accept a single argument object, with the positional arguments as properties within. See the CHANGELOG for more info about this:

https://github.com/MasterKale/SimpleWebAuthn/blob/master/CHANGELOG.md#browser-positional-arguments-in-startregistration-and-startauthentication-have-been-replaced-by-a-single-object

[swagliquido]

EDIT: nevermind, I realized it requires Apple passwords and enabling "Allow automatic passkey upgrades", so it's an apple only thing, wasn't clear from the changelog

@MasterKale Hi, sorry for the noob question, I wanted to try this new functionality even tho it's not documented yet, but adding useAutoRegister to startRegistration doesn't seem to do anything on chrome browser v130 on both windows 11 and android, am i missing something? Maybe this is expected to work only on Safari 18? This is how I added it, but it works just the same as if I just passed options alone, so the UI to create passkeys is being displayed.

attestationResponse = await SimpleWebAuthnBrowser.startRegistration({ optionsJSON: options, useAutoRegister: true });

[lmarschall]

@MasterKale Thank you for the advancements in this project, definitely going to take a look at the new functions this week :+1:

[MasterKale]

EDIT: nevermind, I realized it requires Apple passwords and enabling "Allow automatic passkey upgrades", so it's an apple only thing, wasn't clear from the changelog

@swagliquido Support for conditional create must exist in the passkey provider and the operating system (and/or browser depending on what's talking to the passkey provider.) Right now Apple's operating system and iCloud Keychain are the first combination of that I know of to have pretty reliable support for this. Microsoft and Google will gradually implement support in Windows and Android respectively, and it's likely Chrome will be able to broker some of this as well/in the meantime while the OSs get updated.