Web Authentication API (WebAuthn) Level 3 · Timbits↓<br>Skip to main content
Table of Contents<br>Table of Contents
Overview<br>The Web Authentication API (WebAuthn) Level 3 specification is officially a W3C Recommendation.<br>In W3C terms, this means the specification is stable, has received wide review, and is ready for implementation by browsers and platforms.<br>In practice, Level 3 features are already implemented by most components of the ecosystem.<br>While Level 2 brought us the core standardization of phishing resistant authentication, Level 3 can best be described as the “Passkey Release.”<br>It formalizes the technical features required to support passkeys across different ecosystems.<br>It also addresses the biggest pain points developers faced with Level 2, particularly around usability, cross-domain management, and the notorious difficulty of handling binary data in a JSON-native web.<br>This release marks the maturity of WebAuthn from a niche security standard into a mainstream phishing-resistant authentication layer for the web.
NOTE: “Credential manager” and “authenticator” are used interchangeably throughout this post. Authenticator is the “spec-official” term.
Features to Support Passkeys<br>Additional Authenticator Data Flags<br>Two additional flags were allocated in authenticator data:<br>Backup Eligible (BE)<br>Backup State (BS)<br>The Backup Eligible flag is useful in workforce scenarios, where Credential Managers may create both synced and device-bound passkeys.<br>The flags allow a Credential Manager / Authenticator to indicate to a Relying Party whether a given credential is allowed to be backed up (aka a synced passkey) or not (aka a device-bound passkey).<br>This flag can only be set during a creation ceremony.
Note
In the consumer passkey ecosystem, unattested passkeys, which are the default, should always be assumed to be backup eligible (aka synced passkeys).
The Backup State flag is useful in both consumer and workforce scenarios to indicate whether a backup eligible credential (aka a synced passkey) is currently backed up.<br>This flag can change across each authentication ceremony.<br>Imagine you deleted a passkey from your Credential Manager (CM), and your CM wanted to be sure you weren’t going to lose access to your account.<br>They could put that passkey into a pending deletion state and flip the BS bit to 0, then pop open your default browser to that site.<br>When you sign in using that passkey, the RP could detect that the BS bit is now 0 (whereas all previous authentications were 1).<br>The RP could now take you through a flow to ensure you have other credentials on your account, preventing you from losing access.
Note
Backup State is currently not widely used in the ecosystem in the way described above.<br>Most Credential Managers always set synced passkeys to BS=1.<br>This may change in the future.
Conditional Mediation (Autofill UI & Passkey Upgrades)<br>Conditional Mediation is a major new “mode” for the Credential Management API which underpins WebAuthn.<br>This capability powers the “Passkey Autofill UI” and “Passkey Upgrade” features.<br>Conditional Get<br>Conditional Get is the technical name for the passkey autofill UI .<br>With a button-based flow (e.g., “Sign in with a passkey”), the user needs to know that they already have a passkey (which they typically won’t know).<br>Developers must also make visual changes to their login screens, which can be disruptive and require long approvals.<br>The passkey autofill UI solves these challenges by simply bringing passkeys into the existing autofill experience provided by the browser.<br>Since the UI is handled by the browser / client, nothing is disclosed to the Relying Party until the user selects a credential and interacts with their Credential Manager.<br>This experience is sometimes described as non-modal (whereas a traditional flow is modal).<br>Instead of calling WebAuthn when a button is clicked, you call WebAuthn automatically on page load, with a new mediation: 'conditional' parameter.<br>You also add a webauthn autocomplete token to the username (and/or password) fields on the login page.<br>If the user doesn’t have a passkey, they just proceed normally with the existing forms-based sign-in.<br>Example: Autofill UI enabled on a login page with passkeys in three different Credential Managers (for three different accounts)<br>Add the webauthn autocomplete token:<br>div><br>label for="username">Username:label><br>input name="username" id="username" autocomplete="username webauthn"><br>div>
Call WebAuthn in conditional mediation mode on page load:<br>// 1. Create an AbortController<br>const abortController = new AbortController();
async function startConditionalGet() {<br>// Get Client Capabilities<br>const caps = await PublicKeyCredential.getClientCapabilities();
// check for conditional get support<br>if (caps.conditionalGet) {<br>try {<br>const response = await fetch('/auth/passkey/get-options');<br>const optionsJSON =...