---
url: 'https://www.corbado.com/blog/passkey-signing'
title: 'Passkey Signing: W3C Group for Document Signatures'
description: 'Passkey signing aims to bring legally binding e-signatures to the Web. Learn what the new W3C group builds and how the WebAuthn sign extension works.'
lang: 'en'
author: 'Vincent Delitz'
date: '2026-09-07T07:01:36.147Z'
lastModified: '2026-09-07T07:08:02.542Z'
keywords: 'passkey signing, passkey document signing, webauthn sign extension, previewSign, qualified electronic signature passkeys'
category: 'WebAuthn Know-How'
---

# Passkey Signing: W3C Group for Document Signatures

## Key Facts

- **Passkey signing** aims to sign documents with authenticator-backed keys, rather than only prove a login.
- The **W3C Passkey Document Signing Community Group** brings existing authentication, identity and signature standards together.
- The proposed **previewSign extension** creates a signing key separate from the login key and signs arbitrary data.
- **Still experimental:** no stable browser supports the extension. YubiKey 5.8 offers an early-access implementation through Yubico's SDKs.

## 1. Introduction: Passkey signing

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.

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](https://www.w3.org/community/passkey-signing/)
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?

## 2. Problem: Why logging in is not signing

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.

### 2.1 Assertions sign a challenge, not a document

A WebAuthn assertion signs a structure built by the browser and the authenticator: the
authenticator data, the [relying party](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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.

### 2.2 Identity gets verified again for every provider

The second half of the problem is commercial rather than technical. Someone who wants a
[qualified electronic signature](https://www.corbado.com/glossary/qualified-electronic-signature) under
[eIDAS](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/mobile-drivers-license) and wallet credentials that
browsers can request through the
[Digital Credentials API](https://www.corbado.com/blog/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.

### 2.3 Signing links are a phishing surface

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](https://www.corbado.com/blog/passkeys-phishing-resistant) for login.

## 3. Solution: What the Passkey Document Signing Community Group builds

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.

### 3.1 Signing ceremony

A defined sequence that turns "user approved this document" into a cryptographic fact. The
prior research behind the group, the [PassSign](https://github.com/codedpills/pass-sign)
project, sketches it as the four steps below, from the manifest the signer sees to the
evidence bundle that comes out at the end.

### 3.2 Evidence format

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.

### 3.3 Legal strength of a signature

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.

### 3.4 Building blocks it reuses

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](https://www.corbado.com/blog/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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/qtsp) in the picture and replaces only the part that was ad hoc: the
ceremony and the evidence.

## 4. WebAuthn signing extension: how `previewSign` works

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](https://github.com/w3c/webauthn/pull/2078) and iterated in a
[separate repository](https://github.com/yubicolabs/webauthn-sign-extension). Version 4,
published on 26 August 2025, renamed the extension identifier from `sign` to
`previewSign`, explicitly in preparation for broader prototype availability.

### 4.1 Prerequisites

The examples below illustrate the [version 4 draft API](https://yubicolabs.github.io/webauthn-sign-extension/4/#sctn-sign-extension). 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](https://github.com/YubicoLabs/build-with-us/tree/main/quickstart) 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](https://www.w3.org/TR/webauthn-3/#sctn-rp-operations); 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](https://developers.yubico.com/Passkeys/Passkey_concepts/Security_key_capabilities/Signing_Extension_Preview.html) 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](https://www.w3.org/TR/webauthn-3/#sctn-extensions), 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.

### 4.2 Creating a signing key pair

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:

```javascript
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.

### 4.3 Signing data

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

```javascript
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.

### 4.4 Attestation and constraints

Attestation works for signing key pairs too. The attestation signs over the same RP ID,
flags, [AAGUID](https://www.corbado.com/glossary/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.

## 5. Current status of passkey signing in 2026

Two timelines run in parallel here and both are early.

_Last updated: September 2, 2026_

| Building block                                         | Status                                     | Where it lives                 |
| :----------------------------------------------------- | :----------------------------------------- | :----------------------------- |
| **Passkey Document Signing Community Group**           | 🆕 Launched 17 August 2026, 6 participants | W3C Community Group            |
| **WebAuthn signing extension (`previewSign`)**         | 🧪 Open draft, version 4 of 26 August 2025, early access on YubiKey 5.8 | WebAuthn WG, pull request 2078 |
| **Signature formats (CAdES / PAdES / JAdES)**          | ✅ Published ETSI standards                | Reused as-is                   |
| **Timestamping (RFC 3161)**                            | ✅ Published IETF standard                 | Reused as-is                   |
| **Identity binding (Digital Credentials API)**         | ✅ Chrome 141 and Safari 26, protocol support differs | Reused as-is        |

### 5.1 Community group

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](https://www.corbado.com/blog/credential-exchange-protocol-cxp-credential-exchange-format-cxf),
where Apple, Google, Microsoft and the large password managers were in the room from the
start and where shipping still took years.

### 5.2 Extension status

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.

### 5.3 What is missing

- **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.

## 6. How Corbado can help

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](https://www.corbado.com/observe), the
[authentication observability](https://www.corbado.com/blog/authentication-observability) layer, reads that out
of the ceremonies your users already run. It records the
[AAGUID](https://www.corbado.com/glossary/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.

[Video: Authenticator inventory](https://www.corbado.com/videos/features/authenticator-inventory.mp4) ([See Authenticator Inventory in Corbado Observe](https://www.corbado.com/observe/authenticator-inventory))

- **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.

## 7. Conclusion

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.

## Frequently Asked Questions

### What is passkey signing and how does it differ from a normal passkey login?

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.

### Does the WebAuthn sign extension work in browsers today?

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.

### Can a passkey produce a qualified electronic signature under eIDAS?

Not on its own. A
[qualified electronic signature](https://www.corbado.com/glossary/qualified-electronic-signature) requires a
qualified certificate issued by a [qualified trust service provider](https://www.corbado.com/glossary/qtsp) 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.

### Why does the WebAuthn signing extension not allow an empty allowCredentials list?

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.

### What does passkey signing change for a relying party that already runs passkeys?

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](https://www.corbado.com/glossary/aaguid), transports and user verification behaviors their credentials
actually show today, because that baseline determines the share of users a signing flow
can reach.