The World Wide Web Consortium published Web Authentication: An API for accessing Public Key Credentials Level 3 as a W3C Recommendation on 25 August 2026, ratifying the passkey behaviour browsers have shipped since 2024 and giving relying parties across commerce, publishing and advertising a finished specification for credential creation, cross-domain reuse and embedded sign-in.

The document carries the identifier REC-webauthn-3-20260825 and supersedes Level 2, which reached Recommendation status on 8 April 2021. Level 1 preceded it on 4 March 2019. According to the Web Authentication Working Group announcement, Level 3 is the successor to Level 2, and new features will be developed in Level 4.

Six editors are credited: Tim Cappalli of Okta, Akshay Kumar of Microsoft, Emil Lundberg of Yubico, Matthew Miller of Cisco, Pascoe of Apple and Nina Satragno of Google. The contributor list runs to a further dozen names drawn from 1Password, Bitwarden, IBM, Nok Nok Labs, PayPal, Qualcomm, SK Telecom and Google.

Nothing in the specification changed in substance between the Candidate Recommendation Snapshot of 26 May 2026 and this publication, according to the status section. The implementation report supporting the transition is dated 26 June 2026 and draws on the web-platform-tests suite. The document is governed by the 18 August 2025 W3C Process Document, the revision that removed the Proposed Recommendation stage and allowed working groups to advance directly from Candidate Recommendation to full Recommendation. That procedural change, covered when it landed, shortened the route this specification took.

The formal language is unambiguous about intent. According to the specification, W3C recommends the wide deployment of the document "as a standard for the Web."

What Level 3 actually adds

The revision history lists new features, changes and deprecations separately. On the new-feature side, the additions are substantial enough that most production passkey deployments already depend on at least one of them.

Three JSON serialisation methods arrive: a toJSON() method on the PublicKeyCredential interface, plus parseCreationOptionsFromJSON() and parseRequestOptionsFromJSON() for converting server-supplied JSON into the binary structures the API expects. Before standardisation, every relying party wrote its own base64url encoding and decoding layer, and mismatches between those hand-rolled implementations were a recurring source of registration failures.

Credential creation inside cross-origin iframes is now specified rather than improvised. Conditional mediation, previously available only for authentication, extends to creation. A getClientCapabilities() method exposes what the browser can actually do. A hybrid value joins the authenticator transport enumeration. Three signal methods let a relying party tell an authenticator that its stored credentials are stale. The client data structure gains a topOrigin attribute. A user-agent hint enumeration lets sites steer the credential picker. Related origin requests allow a single credential across a limited set of domains. The BE and BS authenticator data flags are assigned. A compound attestation statement format arrives, along with the pseudo-random function extension and an attestationFormats registration parameter.

The related origins mechanism is the piece with the clearest commercial consequence for any organisation running more than one domain.

By default, WebAuthn ties a credential to an RP ID that must equal the origin's effective domain or a registrable domain suffix of it. According to the specification, that constraint makes deployment difficult for large environments running country-specific domains such as example.com against example.co.uk and example.sg, for brand or alternative domains, and for organisations using platform-as-a-service providers to support mobile apps.

The workaround is a JSON document hosted at the webauthn well-known URL for the RP ID, served over HTTPS with a content type of application/json. The top-level object must contain an origins key whose value is an array of one or more web origin strings. The example in the specification lists ten origins under a single RP ID, spanning country domains, a delivery brand, a rewards brand and a car brand.

Clients that support the feature must handle at least five registrable origin labels, and the specification states that client policy ought to define an upper limit to prevent abuse. The validation procedure fetches the well-known document without credentials, without a referrer and over the https scheme, requires all redirects to remain on https, and throws a SecurityError if the fetch fails, the content type is wrong, the status code after redirects is not 200, or the origins property is missing or malformed.

The label counting matters more than it first appears. The algorithm tracks a set of labels it has already seen, and once that set reaches the client policy maximum, further origins carrying unseen labels are skipped. A retailer with eleven brand labels under one RP ID will find that whichever labels fall outside the client's limit do not resolve, and the order of the origins array determines which ones survive.

Safari shipped related origins, conditional creation and the prf extension in Safari 18.0 in September 2024, roughly two years before the features reached Recommendation status. That sequence is normal for this working group, and it explains why the publication reads less as a product release than as a ratification of deployed behaviour.

Conditional creation and the silent upgrade

Conditional mediation for registration is the feature with the most direct bearing on how many accounts end up holding a passkey at all.

Setting the mediation option to conditional signals that a relying party wants to register a credential without prominent modal interface, provided the user has already consented to credential creation through some means the browser determines. The specification requires clients to set both requireUserPresence and requireUserVerification to false in that mode, unless those checks can be explicitly performed during the ceremony. Prominent modal interface, according to the document, ought not to be shown unless creation was previously consented to.

Practically, this is the mechanism behind automatic upgrades from password accounts to passkey accounts. A site that already authenticated a user with a password can mint a passkey in the background rather than interrupting the session with a dialogue that a meaningful share of users dismisses.

The specification pairs the feature with a check. Relying parties are advised to call getClientCapabilities() and confirm the conditionalCreate capability before attempting the operation, to avoid surfacing an error the user did not ask for.

Nine capability flags

The ClientCapability enumeration defines nine values: conditionalCreate, conditionalGet, hybridTransport, passkeyPlatformAuthenticator, userVerifyingPlatformAuthenticator, relatedOrigins, signalAllAcceptedCredentials, signalCurrentUserDetails and signalUnknownCredential.

The method takes no arguments and returns a record mapping capability keys to boolean values, sorted in ascending lexicographical order. A true value means the feature is currently supported, false means it is not, and an absent key means availability is unknown. Clients may also expose a key for each implemented extension, formed by prefixing the extension identifier with the string extension:.

The privacy trade-off is acknowledged in the document, which routes readers to a section on disclosing client capabilities. Any capability probe is also a fingerprinting surface, and the specification permits clients to omit keys as they judge necessary. It also warns that an extension flagged true at the client says nothing about whether the authenticator involved in a given ceremony supports it.

Signal methods that report nothing

Three signal methods let a relying party correct an authenticator's view of the world: signalUnknownCredential, signalAllAcceptedCredentials and signalCurrentUserDetails.

The design decision worth noting is that none of them tells the caller whether anything happened. According to the specification, signal methods do not indicate whether the operation succeeded, and a resolved promise only means the options object was well formed. The document is explicit that this avoids revealing information about a user's credentials without consent, and that the methods deliberately do not wait for authenticators to finish their work, because response timing would itself leak whether a credential exists.

Authenticators are permitted to deviate from the recommended actions, including by ignoring a change they judge contrary to the user's wishes or by asking the user first. Where an authenticator cannot process an action at all, clients may fall back to existing credential management commands in the FIDO CTAP protocol.

Cross-origin frames and topOrigin

The client data dictionary gains topOrigin alongside the existing crossOrigin boolean. It carries the fully qualified top-level origin of the requester and is set only when the call came from a context that is not same-origin with its ancestors.

Both API entry points remain gated by permissions policy. The specification defines two policy-controlled features, publickey-credentials-create and publickey-credentials-get, each with a default allowlist of self. The API is disabled by default in cross-origin frames, and embedding sites must name the relevant token in the frame's allow attribute to enable it. The document points implementers toward its own sections on interface redressing and on cross-origin usage before deploying in embedded contexts.

For embedded commerce and payment flows, which increasingly run inside frames served by a processor rather than the merchant, that combination decides whether authentication can happen in place or requires a redirect.

Attestation changes and what is going away

The compound attestation statement format allows multiple self-contained attestation statements in a single ceremony. Verification runs each substatement against its own format procedure, and the relying party decides by policy how many must verify successfully.

Deprecations run in the other direction. The Android SafetyNet attestation statement format carries a note stating it is deprecated and expected to be removed in a future revision. The registration parameter for a relying party name is deprecated. The tokenBinding field is marked reserved so the name cannot be reused, with the document noting that Token Binding was present in Levels 1 and 2 but is not expected in Level 3. In-field language and direction metadata is no longer recommended for the relying party name, the user name or the display name. The user verification method extension is gone entirely, with implementers referred back to Level 2.

Other changes are narrower but consequential for anyone parsing attestation objects. The AAGUID in attested credential data is no longer zeroed when the attestation preference is none. ESP256, ESP384 and ESP512 public keys, carrying COSE identifiers -9, -51 and -52, must use uncompressed form, and the specification adds a recommendation against using those three identifiers and -19 in credential parameters. A previous recommendation to abort ceremonies when the document loses focus has been removed.

Timeout guidance now sets a recommended range of 300000 to 600000 milliseconds with a default of 300000 milliseconds, five minutes, referencing the accessibility guideline on allowing enough time. A new test vectors section supplies paired registration and authentication examples using the RP ID example.org, the origin https://example.org and, where relevant, a topOrigin of https://example.com.

Backup flags and the recovery problem

The BE and BS flags in authenticator data encode credential backup eligibility and current backup state. The specification defines three valid combinations and rules one out: eligibility clear with state set is not allowed. Eligibility is fixed at creation and cannot change; state can vary over the life of the credential.

The document recommends that relying parties store the most recent values with the user account. A credential whose eligibility flag is clear is a single-device credential that will never be backed up, which means the account is not resilient to the loss of that device. The specification directs relying parties in that position toward registering additional authenticators or maintaining an account recovery path.

For any service where account recovery routes through a support queue, that flag is the difference between a self-service reset and a manual identity check.

Why this matters for the marketing community

Authentication has become the load-bearing wall of first-party data strategy, and the specification standardised here decides how much of a logged-in base a business can actually hold.

The commercial logic is visible in what platforms have already built on top of passkeys. Google Ads began requiring a passkey for sensitive account actions from 15 July 2026, covering account linking updates and user access changes, and surfaced the requirement to developers through a passkey_enabled boolean field in Google Ads API v24.1 released on 13 May 2026. A second deadline followed on 5 August 2026, when generating new OAuth 2.0 refresh tokens through the Ads API authentication workflow began requiring a passkey. Because a passkey cannot be shared, that requirement forced agencies operating on shared logins to assign individual accounts to each person performing sensitive operations.

The identity economics run parallel. Authenticated inventory commands its own pricing and its own measurement claims: the Video Advertising Bureau isolated a 42 percent revenue gap between authenticated television viewers and others in July 2026. Deterministic joins depend on the same substrate, whether through LiveRamp's RampID reaching programmatic audio inventory in May 2026, through Google's Confidential Publisher Match with Roku in March 2026, or through the PAIR protocol that the IAB Tech Lab published as an industry standard in September 2024. Each of those depends on a user who logged in. None of them creates that user.

Conditional creation is the feature that moves the number. A retailer with millions of password accounts can convert them to passkey accounts without an interruption prompt, which raises the share of the base that returns without a friction point that costs sessions. Related origins is the second lever, and it applies most directly to multi-market and multi-brand operators, where the same customer previously needed a separate credential for every country domain.

There is a boundary worth stating plainly, because the vocabulary invites confusion. A passkey is not an advertising identifier and cannot become one. The specification scopes each credential to a single relying party, enforces that scoping jointly through browsers and authenticators, and states that relying parties cannot detect the properties or even the existence of credentials scoped to other relying parties. The privacy architecture is explicitly anti-correlation. Whatever cross-site value a login produces has to be created afterwards, in a clean room, an identity graph or a hashed-email join, under whatever consent framework applies.

That distinguishes WebAuthn from the browser-mediated identity work running alongside it. FedCM, which Google Identity Services moved to from April 2024, mediates federated sign-in and survived when Chrome retired most Privacy Sandbox technologies on 17 October 2025. WebAuthn handles the credential itself. Both now sit inside the browser, and both are governed by specifications the browser vendors help write.

The wider standards picture points the same direction. W3C published an updated Geolocation API as a Recommendation on 24 March 2026, moved Decentralized Identifiers v1.1 to Candidate Recommendation in March 2026, and opened a comment window on DID Resolution v1 closing on 3 September 2026. The FIDO Alliance, which developed the passkey work WebAuthn implements, formed working groups on agentic payments in May 2026, and Mastercard has already anchored an agent-completed payment to a passkey confirmation step. Cryptographic credential infrastructure is being extended from human sign-in toward machine delegation, and the human layer is the part that just became final.

Level 4 is where the next set of features lands. Until then, the behaviour described in this document is the behaviour relying parties can build against without waiting for a specification to settle.

Timeline

Summary

Who: The World Wide Web Consortium and its Web Authentication Working Group, with editors Tim Cappalli of Okta, Akshay Kumar of Microsoft, Emil Lundberg of Yubico, Matthew Miller of Cisco, Pascoe of Apple and Nina Satragno of Google. The audiences named in the document are relying party web application developers, web framework developers, user agent developers, operating system platform developers and authenticator developers.

What: Web Authentication: An API for accessing Public Key Credentials Level 3, published as a W3C Recommendation under the identifier REC-webauthn-3-20260825. New features include JSON serialisation methods, credential creation in cross-origin frames, conditional mediation for creation, a getClientCapabilities() method exposing nine capability flags, three signal methods, related origin requests, user-agent hints, the BE and BS backup flags, compound attestation and the prf extension. Deprecations cover Android SafetyNet attestation, the relying party name parameter and in-field language metadata, while the user verification method extension is removed outright.

When: Published 25 August 2026, following a Candidate Recommendation Snapshot on 26 May 2026 and an implementation report dated 26 June 2026. It succeeds Level 2 from 8 April 2021 and Level 1 from 4 March 2019.

Where: Published by W3C at the technical reports index and applicable to browsers, operating systems, authenticators and any website operating as a WebAuthn relying party. The related origins feature depends on a JSON document hosted at a well-known URL under the relying party's own domain.

Why: According to the specification, the API exists so web applications can create and use strong, attested, scoped, public key credentials for authenticating users, with browsers mediating access to preserve privacy and authenticators ensuring no operation happens without user consent. For the marketing and advertising industry, the ratified feature set governs how many accounts can hold a durable credential, how far one credential travels across a brand portfolio and whether authentication can complete inside an embedded frame. It does not create a cross-site identifier: credentials remain scoped to a single relying party by design.