WebAuthn Conditional Registration Extension

1. Introduction: Conditional UI is the Booster for Passkeys

In the digital age, the concept of 'ease of access' has become important in shaping user experiences. Passkeys have been at the forefront of this revolution, offering a seamless authentication process. This process is not only passwordless but can also be extended to being usernameless or, to put it more aptly, account-less. However, this convenience, made possible by Conditional UI / Conditional Mediation / Passkey Autofill is currently only possible for login processes, with sign-up processes still requiring the provision of a user handle and manual user interaction to start the process. Could the principles of Conditional UI transform the sign-up processes as profoundly as they have logins? Let's delve into the potential of Conditional UI for sign-ups.

2. The Current State: Conditional UI in Logins

Conditional UI, a cutting-edge passkey feature that simplifies logins by eliminating unnecessary steps, has significantly bolstered passkey adoption. The idea of extending this to sign-ups seems like a logical next step, doesn't it?

The arguments for an introduction of such a feature can be quickly outlined:

• Maximum User Convenience: By integrating passkeys with Conditional UI during the registration process, the same seamless experience that exists for logins can be achieved for signups. It make the login process even easier than a passkey creation process with a modal / pop-up.
• Consistent Sign-up Screens: Users would not need to differentiate between the sign-up with a passkey or the sign-up in with a password, as the process could be streamlined to support both authentication methods in the same screen and process.
• Higher Security From the Very Beginning: Encouraging the creation of passkeys via a password manager's or browsers autofill feature could enhance security by fostering stronger credentials in the form of passkeys instead of suggesting passwords.

Yet, the introduction of this feature hasnt happened and is not even specified yet, as there were quickly found some contra arguments:

• User Confusion: Introducing Conditional UI during sign-up processes could lead to user confusion since the sign-up typically requires additional information (e.g. name, user handle, birthday, further personal information) compared to the login process that often is just fine with a user handle. In the particular case of passkeys / WebAuthn, one would also need to provide the name and display name for a new user.
• UI Overhead: The proposal might add additional complexity to the user interface, as developers would need to accommodate both password creation and passkey generation within the same layout without confusing the user.
• Lack of Necessity: Some argue that Conditional UI is not needed for sign-up processes as it does not address a specific problem in that context since the user's passkey status is inherently unknown during registration.

3. A Shift in Perspective: Conditional UI for Registrations

Recent real-life implementations have reopened the discussion which culminated in a new explainer for a WebAuthn Conditional Registration Extension. With no best practices for promoting passkey creation among existing user bases, two approaches are gaining traction: encouraging passkey setup post-login or integrating passkey creation options within account settings. For new users, some avant-garde players have even begun offering 100% passwordless / passkey, pointing to an industry on the cusp of change.

Lets take a look what at these three potential scenarios for creating a passkey via Conditional UI and how they could look like in practice:

3.1 Existing, Authenticated User Creates New Passkey

When a user who is already authenticated (perhaps via traditional authentication method, e.g. passwords) engages with a web application, they could encounter a new interface inviting them to create a passkey. This interface could materialize as an HTML element (e.g. input field) that upon interaction, triggers the operating system's passkey creation dialog. Imagine a discrete pop-up window, possibly appearing at the center of the screen or sliding in like Google's One Tap, that is context-aware and adapts to the OS's design language. This would look a small further improvement compared to the current best demonstrated practice by companies like Google or GitHub who offer users, who authenticated via a traditional authentication method, to create a new passkey. Its also what we offer at Corbado.

Google:

GitHub:

Corbado:

Technical Consideration:

For this to function smoothly, the web application must recognize the users device as Conditional UI compatible and start the passkey creation ceremony. This will typically involve leveraging the WebAuthn API to generate public- private key pairs that constitute the passkey, which will be stored securely on the users device. The users identity is then verified via biometrics or another secure method, after which the passkey is bound to their account for future login attempts.

Pros:

• Simple Integration: Integration is relatively easy as developers would only have to add the HTML element to a web page where they want the passkey creation to happen. It would even be a dedicated web component.
• Only Authenticated Users: Passkeys are created in a context that is only available to already authenticated users.

Cons:

• Confusing for Authenticated Users: Users might find the prompt disruptive if they're not expecting it or are not interested in creating a passkey immediately post-login. In contrast, in current implementations at Google, GitHub or Corbado, users could still skip the passkey modal.
• No Standardized HTML Element: Industry standards for the UX design of such prompts are not yet established, possibly leading to inconsistent implementations. This is simplified in the difference of the passkey creation at Google and KAYAK. While Google provide more insights about passkeys, KAYAK directly triggers the passkey modal after a click on the sign-up button and does not provide too much explanation.

Google's passkey explainer:

KAYAK's straight-forward passkey creation:

3.2 Existing, Non-Authenticated User Creates New Passkey

Consider a user who has an account but isnt logged in. Upon visiting the login page, a conditional UI popup detects a passkey-compatible device and suggests creating a passkey. Technically, this requires a bit more nuance. The website would need to execute a robust yet user-friendly mechanism to link the newly created passkey with the existing user account. This necessitates a two- step process: a legacy authentication method to verify the users identity followed by the passkey binding to the users account.

Technical Consideration:

This process hinges on the successful execution of a legacy login (perhaps via legacy password, an OTP or email magic link) to ensure that the user creating the passkey is the legitimate owner of the account. Subsequently, the service provider must seamlessly transition the user from the legacy authentication method to passkey-based authentication, storing the new credentials securely. This is also what the recent Explainer for Conditional Registration Extension proposes.

The flow in the proposed extension looks like this:

• When a user visits a website with username and password form (the legacy authentication method), a WebAuthn Conditional UI request with conditionalCreate: true is triggered in the background.
• The browser offers to autofill a saved username and password, which is accepted by the user.
• The relying party on the server-side verifies the username and password and on the users device a new passkey is created. This happens in the form of a modal (e.g. the familiar Face ID, Touch ID, Windows Hello popup).
• After successful passkey creation, the user has both a password and passkey for their account. Next time, they try to log in, they can use the passkey via Conditional UI for login processes.

Pros:

• Familiar Touchpoint: Encourages the adoption of passkeys by interfacing with users at a familiar touchpoint.
• Promote Synced Passkeys: This scenario also has the potential to migrate users from single-device passkeys to synced passkeys in an automated manner if its technically detected that a user only has a single-device passkey and could be upgraded to synced passkeys.
• Leverage of Password Managers: If the user uses a password manager, the browser knows when autofill happens. Many password managers also require biometrics anyway when autofilling passwords which could be used for the passkey creation as well.

Cons:

• Legacy Authentication Method Required: Users must still go through the legacy authentication method, which could detract from the seamless experience promised by passkeys.
• Technically Complex: Linking a new passkey to an existing account requires careful handling of user data and can introduce complexity in the backend process. However, the new explainer would standardize many of the technical complexities.
• Navigation Issues: After successful login with traditional auth methods most sites often redirect the user, which could interfere with potential conditional UI requests. However, browsers could take care of that if they also adopt the standard.

Following discussions of the FIDO working group, apparently, many members actually favor this use case. In particular, Apple often quite silent in public FIDO discussions is very bullish on this scenario (also shown that the Conditional Registration Extension explainer was created by an Apple employee). For a better understanding of the reasoning behind the extension, see this GitHub discussion.

3.3 New User Signs Up Via Passkey

This scenario simplifies the sign-up process to a considerable extent. A new user, upon visiting a website, encounters a passkey creation prompt that could be activated by simply browsing or during engagement with cookie and privacy consents. The user authenticates biometrically, and an account is created behind the scenes. This initial interaction does not necessitate the provision of an email address, deferring that step until the user opts into features that require email communication.

Technical Consideration:

From a technical standpoint, the website would generate a unique identifier for the user (it could also use the credential ID of a passkey) upon successful biometric authentication and tie this to the passkey. This sets up a minimalistic, yet secure, account that can later be expanded with additional user information as needed. This would be particularly advantageous for e-commerce websites looking to streamline the checkout process.

Pros:

• Privacy Enhancing: Enhances user privacy by minimizing the collection of personal information at the sign-up stage.
• Customized UX: Could potentially improve customized UX as website owners can tailor the experience in a privacy-centric manner, amidst the phasing out of traditional cookies.

Cons:

• Unexpected Passkey Modal: Users unfamiliar with passkeys may be confused or mistrustful of the modal, potentially impacting sign-up rates.
• Not Overwhelming the User: The user experience must be carefully crafted to ensure clarity and trust, avoiding the appearance of intrusive or malicious pop-ups.
• Already Possible Today to Some Extent: As websites would have to guide users to a sign-up page anyways, there is some user interaction needed. Either you need to click on a Create account button or you need to redirect users to a dedicated page for defining a password (this page could be completely skipped if the passkey creation was successful though). This interaction could already be used to start the passkey creation process, so a Conditional UI might not be too beneficial.
• User Handle Required: For creating a new account some form of user handle (e.g. email address, phone number, username) is required. Asking a user in a conditional UI modal would be probably more confusing than helpful

The tone of FIDO working group discussions regarding this use case is rather negative, as its actually almost possible today without a new introduction of this mode, see this GitHub discussion for more background information.

4. Architectural Considerations for WebAuthn Conditional Registration Extension

The path to integrating Conditional UI in sign-up processes requires thoughtful design decisions, from potential dual-purpose API calls to managing user interaction without friction. Here are the architectural aspects that need to be considered:

• Split API Calls: Separate the processes into two distinct calls: one for conditional login and another for sign-up, which can be made after the initial authentication is completed.
• Handling Page Reloads: Both Single Page Applications (SPAs) and server-rendered sites need to manage the registration process without losing context, even with page navigation or reloads.
• Callbacks for Dynamic Data: Using callbacks to provide dynamic user information during the registration process to overcome the issue of not having user details at the time of the WebAuthn request.
• User Interaction Flow: The flow needs to be carefully crafted to avoid interruptions or confusions, especially if the registration process involves multiple steps or pages.

5. Update: iOS 18 Introduces Conditional Passkey Creation

After we have written this blog post initially in September 2023, the presentation of iOS 18 in June 2024 came with a surprise: iOS 18 supports the automatic upgrade to passkeys via conditional passkey creation. We have written a detailed blog post here.

6. What the Future Holds: Passkey Registration and Conditional UI

Passkeys Registration and Conditional UI represent new challenges, but also new opportunities to help passkeys become more widely adopted. As we look to the horizon, it's clear that these advances are not a matter of 'if' but 'when'. The scenarios we've explored today could very well define the next wave of passkey adoption among more users, shaping a future where security, convenience, and user experience converge seamlessly from the very first interaction.