Passkey Signing: W3C Group for Document Signatures

Passkeys have won the login. The WebAuthn ceremony is in wide use, which is why the ecosystem has started asking what else that ceremony could carry. Document signing has been on that list for years.

Passkeys Cheatsheet. Practical guidance, rollout patterns and KPIs for passkey programs.

Get Cheat Sheet

The Web never got a signing primitive backed by an authenticator. Every browser can prove that a user is present and, when the site asks for it, verified, but none of them can produce a signature over a contract that a court or an auditor would accept later. The new Passkey Document Signing Community Group at the W3C wants to close that gap without inventing a single new cryptographic primitive.

This post answers three questions:

1. Why is document signing still broken on the Web?
2. What exactly does the Passkey Document Signing Community Group want to specify?
3. How does the WebAuthn signing extension work and how far is it from being usable?

A passkey login and a document signature look similar from the outside. A user taps a sensor, a private key produces a signature, a server verifies it. The difference sits in what gets signed.

A WebAuthn assertion signs a structure built by the browser and the authenticator: the authenticator data, the relying party ID hash, the flags, the signature counter and a hash of the client data containing the server's random challenge. That structure proves one thing well, namely that a specific credential was used on a specific origin a moment ago with user verification present.

It proves nothing about a contract. The document is not in the signed bytes, so the signature carries no statement about what the user agreed to. A relying party can put a document hash into the challenge, which ties the assertion to the document, but the result is still an assertion over authenticator data and client data that only WebAuthn software can read, not a signature a PDF viewer or an auditor's tool understands. In most deployments even that binding is missing and everything that connects the ceremony to the document lives in application logs, which are exactly the evidence a counterparty can dispute. The two byte structures below show where the gap sits.

The second half of the problem is commercial rather than technical. Someone who wants a qualified electronic signature under eIDAS has to prove their identity to each signing provider they use, usually through a video call or an ID check and usually at a cost per identification. The same person repeats that process at the next provider a few months later.

The credentials that could end this are arriving on phones, as mobile driver's licenses and wallet credentials that browsers can request through the Digital Credentials API. Arriving is the right word: as of September 2026 the API ships in Chrome and Safari, but the share of users who hold such a credential and of services that request one is still very small. The building block for a reusable verification exists, the adoption does not.

Business signing today runs on emailed links. The typical flow at an e-signature service such as DocuSign or Adobe Acrobat Sign looks like this: the sender uploads a contract, the service sends the recipient an email with a "Review and sign" button, the recipient clicks it, lands on a page they have never seen before, perhaps types a code that was sent by SMS, and clicks "Sign". In the basic flow the proof that the right person signed is that they had access to the mailbox the link was sent to. Stronger checks such as ID verification or a certificate-based signature with the signer's own digital ID exist, but they are options on top, not the default. In the default flow there is no key on the recipient's side, and the signature the service produces is the service's, not the signer's.

For the recipient that flow is hard to tell apart from a phishing attempt. An attacker who sends a similar email with a similar button gets the same click, and the only defenses are checking the sender and typing the provider's address by hand, which is uncomfortable in an industry that spent a decade teaching users not to click links in emails.

An origin-bound passkey ceremony removes that surface, because the credential only works on the origin it was registered for. A fake signing page cannot trigger it. This is the same property that makes passkeys phishing-resistant for login.

Try digital credentials in a live demo.

Try Digital Credentials

The group was proposed on 9 August 2026 by Mohammed Zakari and launched on 17 August 2026, with Kyle Simpson, Michael Suzuki, Mubarak Awal and Anup Sah supporting the creation. Zakari chairs it. Its charter is unusually explicit about what it will not do: it will define neither new cryptography nor new authenticator behavior.

Three deliverables come out of the composition it describes.

A defined sequence that turns "user approved this document" into a cryptographic fact. The prior research behind the group, the PassSign project, sketches it as the four steps below, from the manifest the signer sees to the evidence bundle that comes out at the end.

A container that any third party can verify offline and without asking the vendor who produced it. This is the part that decides whether a signature survives a dispute five years later. Verification against a published public key beats verification against a provider's audit log, because the provider might not exist by then.

Not every signature needs to be qualified. Signature law grades signatures by how much legal weight they carry and a ceremony that cannot say which grade it reached forces every reader to guess. The group wants that level to be expressed in the evidence itself.

The charter names the pieces it composes and treats all of them as fixed:

• WebAuthn for the approval gesture and the key material
• OpenID4VP and the Digital Credentials API for the identity binding, so an identity verified once can be presented again
• CAdES, PAdES and JAdES as the ETSI signature formats for CMS, PDF and JSON
• CSC API for remote signing, for example against a qualified certificate held by a trust service provider
• RFC 3161 for the trusted timestamp that proves the signature existed at a given time

A passkey cannot produce a qualified signature by itself, because eIDAS requires a qualified certificate and a qualified signature creation device. The composition keeps the QTSP in the picture and replaces only the part that was ad hoc: the ceremony and the evidence.

The cryptographic heart of the plan is a WebAuthn extension that has been an open pull request since May 2024, proposed by Emil Lundberg of Yubico in pull request 2078 and iterated in a separate repository. Version 4, published on 26 August 2025, renamed the extension identifier from sign to previewSign, explicitly in preparation for broader prototype availability.

The examples below illustrate the version 4 draft API. They are not runnable in a standard browser today. Before testing a signing flow, you need:

• A compatible authenticator and client. Both must support previewSign; ordinary passkey support is not enough. For a hardware prototype, Yubico provides native SDK quickstarts for YubiKey firmware 5.8. These use SDK calls rather than the browser JavaScript shown below.
• A working WebAuthn setup. A browser implementation still needs a secure context, normally HTTPS, a valid RP ID and server-generated challenges. The server must verify registration and authentication responses using the normal WebAuthn checks; the snippets omit those standard options.
• A credential created with a signing key. In version 4, request generateKey during registration. An existing login credential without that setup cannot simply start signing. Store the credential ID, signing public key and key handle for later requests. Choose the required user verification policy at creation time.
• Matching algorithm support. The authenticator and verifier must support the selected signing algorithm. Yubico's early-access implementation uses ARKG_P256_ESP256 (-65539), so the generic ES256/RS256 list below is not a YubiKey quickstart. An ARKG prototype also needs public-key derivation and the corresponding signing ticket.

Check the extension outputs before continuing: WebAuthn extensions can be ignored, so a successful registration alone does not prove that a signing key was created. Yubico marks the preview as experimental and explicitly excludes production use.

The extension splits registration and signing across two ceremonies. During a registration ceremony the relying party requests generateKey with a list of acceptable COSEAlgorithmIdentifier values, ordered by preference:

navigator.credentials.create({
    publicKey: {
        // ... standard creation options
        extensions: {
            previewSign: {
                generateKey: { algorithms: [-7, -257] }, // ES256, RS256
            },
        },
    },
});

The authenticator creates a second key pair, separate from the credential key pair, and returns four things: the signing public key in COSE_Key format, a key handle, the chosen algorithm identifier and an attestation object.

What happens to the two halves of that key pair:

• The private key stays in the authenticator and is never exported. WebCrypto can mark a key as non-extractable too, but that key lives in the browser profile and nothing attests where it is. The signing private key does not even have to be stored in the authenticator. One example encoding in the draft puts the algorithm, the policy flags and a seed into the key handle, protected by an HMAC with a per-credential authenticator secret, so the authenticator can derive the private key again from the key handle whenever it is presented. That is how an authenticator can serve signing key pairs without using storage. The key handle is auxiliary data and may even be empty if the authenticator keeps the key internally.
• The public key goes to the relying party, which stores it together with the key handle and the credential ID. It later verifies every signature against that public key and can hand it to whoever needs to verify independently, for example by putting it into a certificate or a verifiable credential. Algorithms can vary this: Yubico's early-access implementation uses ARKG, where the relying party receives seed material and derives a fresh, unlinkable public key for each signature on its own.

To sign, the relying party runs an authentication ceremony and passes the data to be signed per credential:

navigator.credentials.get({
    publicKey: {
        // ... standard request options
        allowCredentials: [{ id: credentialId, type: "public-key" }],
        extensions: {
            previewSign: {
                signByCredential: {
                    [credentialIdBase64Url]: {
                        keyHandle: keyHandle,
                        tbs: documentHash, // to be signed
                    },
                },
            },
        },
    },
});

The draft says the given data is signed unaltered, and that the signed data does not include authenticator data or client data. An assertion does the opposite, which is why an assertion signature cannot go into a PAdES container and this one can. The step can be repeated as often as needed with the same key pair.

Attestation works for signing key pairs too. The attestation signs over the same RP ID, flags, AAGUID and client data hash as the attestation for the associated credential, and it additionally encodes the user presence and user verification policy of the signing key pair, since that key pair never signs an authenticator data structure of its own.

Three constraints in version 4 matter for anyone planning an implementation:

• Each credential carries at most one signing key pair, and its user presence and user verification policy is fixed at creation time. A second policy means a second credential. The upcoming version 5 lifts the first half and allows several key pairs per credential, each with its own fixed policy.
• allowCredentials must not be empty. Signing meaningful data implies you already know which user signs, so the discoverable credential flow does not apply.
• Whether the relying party pre-hashes tbs depends on the algorithm, which the draft signals through distinct algorithm identifiers rather than a global convention.

Igor Gjorgjioski

Senior Product Lead, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users, alongside their existing IDP.

Read the case study

Two timelines run in parallel here and both are early.

Last updated: September 2, 2026

The group has six participants, one chair, a mailing list and a mission statement. No browser vendor, no QTSP and none of the large e-signature vendors have joined so far, and no draft specification has been published yet. That is normal for a community group in its first month. Compare it with the Credential Exchange Protocol, where Apple, Google, Microsoft and the large password managers were in the room from the start and where shipping still took years.

The signing extension is further along technically and no closer to being usable on the Web. A fifth version is in preparation in the draft repository, with the identifier previewSign5 and two relevant changes: a signing key pair can then also be created during an authentication ceremony, not only at registration, and a credential may carry several signing key pairs. The one implementation that exists is Yubico's early-access build in YubiKey firmware 5.8, based on the ARKG algorithm, reachable through Yubico's own SDKs and marked as not for production. What the extension does not have is an implementation in a stable browser release or in platform authenticators, and platform authenticators are where the passkeys of most users actually live. Discussion in the pull request has recently turned to exactly the requirement that document signing creates: registered algorithm identifiers and compatibility with the CMS, JOSE and COSE signature formats, so the signature can be verified by software that knows nothing about WebAuthn.

• Platform support. A signing flow that only works with a security key reaches a small minority of users.
• Identity binding in practice. Reusing a wallet credential across signing providers needs both the wallet ecosystem and the providers to accept the same presentation.
• Regulatory acknowledgment. Signature regulation is technology-neutral, so a passkey-based ceremony is not ruled out, but a trust service provider would have to show in its conformity assessment that the ceremony gives the signer sole control in the sense of a qualified signature creation device.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Nothing about passkey signing requires action this quarter. What decides the reachable share of a later signing rollout is already in your login data, because signing keys are created in a registration ceremony and their user verification policy is fixed at that moment. Whether a signing flow can reach a user is decided by the authenticator that user already has, not by the flow you build later.

Corbado Observe, the authentication observability layer, reads that out of the ceremonies your users already run. It records the AAGUID, the transports, the backup state and the user verification behavior of every credential, and resolves each AAGUID against the FIDO Metadata Service for security keys and a catalog of platform providers for the rest, so a credential reads as "iCloud Keychain" or "Windows Hello" instead of as a hex string.

• Inventory reports which authenticator classes and which FIDO certification levels your user base actually carries. That is the population any future signing flow can draw from.
• Passkey Insights groups credentials by authenticator, transport and sync status over time, which is what tells you whether the device-bound share is large enough for attestation-dependent use cases.
• Passkey Errors collapses failed ceremonies into flavors keyed on subflow, step, error name and duration, so a new extension that behaves differently on one platform shows up as a countable pattern rather than as a vague dip.

The thesis behind passkey signing is that the Web already has every building block for legally meaningful signatures and has never composed them. The Passkey Document Signing Community Group is betting that the composition is the missing work.

The bet is reasonable and the group is tiny. Neither the group nor the extension it depends on has reached the point where a relying party could build on it, and both facts could change quickly, because neither one requires new research.

Watch pull request 2078 rather than the community group, since the extension gates the native signing path that the whole idea rests on.

A passkey login produces an assertion signature over a random challenge plus authenticator data and client data, which proves that a user was present recently but says nothing about a document. Passkey signing produces a signature over the document itself, so the signed bytes are meaningful on their own and a third party can verify later what exactly the signer approved.

Not in browsers. The extension lives in pull request 2078 of the WebAuthn specification, open since May 2024. Version 4 of the draft, published on 26 August 2025, renamed the extension identifier from sign to previewSign in preparation for broader prototype availability. Yubico ships an early-access implementation in YubiKey firmware 5.8, reachable through its own SDKs and marked as not for production. As of September 2026 no stable browser release exposes the extension.

Not on its own. A qualified electronic signature requires a qualified certificate issued by a qualified trust service provider and a qualified signature creation device. A passkey can carry the signer's approval and the identity binding, but the qualified certificate and the timestamp still come from a trust service provider. That composition is exactly what the W3C Passkey Document Signing Community Group wants to specify.

Signing data that is meaningful on its own means the relying party must already know what is being signed and therefore which user is signing it. Discoverable credential flows with an empty allowCredentials exist for anonymous authentication challenges, which is the opposite situation. Requiring a non-empty list also lets authenticators stay stateless and store neither the credential nor the signing key pair.

Signing keys are created during a registration ceremony and their user verification policy is fixed at creation time, so the authenticator mix in your user base decides who can sign at all. Relying parties that plan for signing need to know which AAGUIDs, transports and user verification behaviors their credentials actually show today, because that baseline determines the share of users a signing flow can reach.