Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for WebAuthn's conditional create #582

Open
MasterKale opened this issue Jun 13, 2024 · 1 comment
Open

Add support for WebAuthn's conditional create #582

MasterKale opened this issue Jun 13, 2024 · 1 comment

Comments

@MasterKale
Copy link
Owner

MasterKale commented Jun 13, 2024

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:

Screenshot 2024-06-11 at 1 17 58 PM

@lmarschall
Copy link

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 😞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants