What fields are included in the create arguments when making a passkey?

The server provides an RP ID (relying party), the username, and a unique challenge. These are returned to the browser as part of the create arguments to initialize the credential creation process and prevent replay attacks.

What is attestation data in WebAuthn/passkeys?

Attestation data includes signatures and certificate chains that verify the hardware/software used to create the credential (e.g., TPM attestation). It helps servers decide whether to trust the authenticator hardware.

What is a credential ID in WebAuthn?

The credential ID is a randomly generated identifier for the public/private key pair created for that user on that device. It lets the server know which credential to use for future sign-ins.

How does login with a passkey differ from a password login?

For passkeys, the server issues a challenge that the device signs with the private key held on the device (via the TPM). The server then verifies the signature and the origin. There is no password sent over the network, and the private key never leaves the device.

What proves possession of the private key during authentication?

The device signs a challenge with the private key, producing a signature that the server validates using the corresponding public key. This proves the user has the private key without revealing it.

Where does TPM fit into passkey creation?

TPM provides a secure root for signing credentials during creation and attestation, tying the credential to hardware-backed trust on the device.

What is the role of the public key in the login flow?

The server stores the public key (associated with the credential ID). During login, the client proves possession of the private key by producing a signature over the challenge, which the server can verify with the stored public key.

Implementing Passkeys in Practice - Computerphile

Computerphile

Education6 min read15 min video

Jan 22, 2026|94,804 views|3,628|342

computers computerphile computer science

Save to Pod

Key Moments

On this page

TL;DR

TLDR: Build and login with WebAuthn passkeys using TPM/OS, with server-side checks.

Key Insights

Passkeys replace passwords by using a hardware-backed public/private key pair; the private key never leaves the device, and authentication proves possession rather than knowledge.

Creation flow centers on server-provided creation arguments (RP ID, username, challenge) and browser-based navigator.credentials.create to generate and store a new credential.

Attestation data and certificates provide hardware/software provenance for the credential, offering optional high-assurance verification for certain environments.

Each credential is identified by a unique credential ID stored in the server database, enabling multiple devices or authenticators per user.

Authentication flow uses server-supplied get arguments and navigator.credentials.get to sign a fresh challenge, proving possession of the private key without revealing it.

Server-side checks validate origin, user, credential, and signature, updating session state and counters to prevent reuse or replay.

WHAT PASSKEYS ARE AND WHY THEY MATTER

Passkeys are public key credentials that replace passwords by binding a private key to a device and a site. In practice, a website asks the browser to create a new credential; the browser then uses a hardware or software module (TPM, OS, or a password manager) to generate a key pair, store the private key securely, and share the public key with the server. This arrangement means authentication relies on possession of the device and its key rather than a text password, reducing phishing risk.

SYSTEM ARCHITECTURE: SERVER, CLIENT, AND AUTHENTICATOR

From a high level the flow splits into server, client (the browser), and the authenticator. The server provides creation options (creation arguments) and later login options (get arguments). The client requests these options, the browser prompts the user and the authenticator handles the cryptographic work, and the server stores the resulting credential. The video demonstrates this in a localhost demo, wiring the pieces together without heavy libraries so you can trace every data item that moves.

CREATION FLOW: FETCH ARGUMENTS AND SERVER CONFIG

To create a passkey the code first requests creation arguments from the server. These include the relying party ID (the site), the username, and a unique challenge to prevent replay. The server returns these values in JSON, the browser feeds them into the create call, and the authenticator responds with a credential containing an attestation, a credential ID, a public key, and user verification flags. If server checks pass, the credential is stored and associated with the user in the database.

CLIENT-SIDE CREATION: INTERACTION WITH THE AUTHENTICATOR

The browser calls navigator.credentials.create, which interacts with the operating system or TPM to generate the key pair and a credential blob. The user is prompted to approve with a PIN or other method, and the TPM signs the attestation data. The response includes client data, the attestation data, and the credential ID plus public key. The server validates the attestation chain and stores the new credential, linking it to the user account.

HARDWARE-BACKED VERIFICATION: USER PRESENCE AND VERIFICATION

Hardware-backed verification is revealed in fields such as user presence and user verification. They indicate that a real user interaction occurred, not an automatic generation. Depending on the device, the authenticator might require a PIN or biometric confirmation. The TPM signs the attestation and the server can inspect the certificate chain to confirm hardware provenance. Importantly the private key never leaves the device; what travels over the network is the public key and the signed attestation.

ATTESTATION DATA AND CERTIFICATES: PROVING HARDWARE ORIGIN

Attestation data collects signatures and certificate chains proving the hardware that created the credential. The format references TPM or software-based attestations with intermediate and root certificates. Servers may ignore most of this data, but in high assurance environments it can be used to verify that credentials originate from the intended hardware or software stack. The attestation does not expose the private key; it simply proves that the credential was created by a trusted authenticator.

CREDENTIAL IDENTIFIERS AND DATABASE STORAGE

Each credential is identified by a random credential ID, which the server stores with the user and device details. This ID lets the server distinguish multiple credentials for the same user, such as one on a laptop and another on a phone, and map sign-in attempts to the correct public key. In production you typically maintain a database table linking credential IDs to public keys and user accounts, enabling future authentications against the right credential.

AUTHENTICATION FLOW: GET ARGUMENTS AND SIGNING CHALLENGES

During login the client asks the server for get arguments, which include a fresh challenge and a list of allowed credentials for the user. The server can indicate the specific credential IDs it accepts, letting the authenticator pick the proper key. The browser then calls navigator.credentials.get, prompting the user to use their passkey. The authenticator signs the challenge using the stored private key and returns the result along with client data and authenticator data for server verification.

SIGNATURES AND THE PROOF OF POSSESSION

The signature is the core proof: it binds the client data, the authenticator data, and the private key. The server checks the response type, confirms the origin matches the site, ensures the correct username, and verifies the signature against the stored public key. The authenticator data includes a user verification flag and a sign count, which helps detect misuse. Because the private key never leaves the device, you cannot derive the password or reuse secrets from the server.

SERVER-SIDE VERIFICATION: CHECKS AND BALANCE

On the server side the verification step ensures the response is valid and corresponds to a known credential for the user. It checks that the challenge is fresh, the origin is correct, and the signature matches the public key stored for that credential ID. A successful verification leads to a login session and updates such as sign counts. This approach eliminates password transmission and reduces risk from password reuse and credential theft because the secret never traverses the network.

REPLAY PROTECTION, COUNTERS, AND SECURITY NOTES

Replay protection in passkeys relies on fresh challenges and monotonic sign counts. Each login attempt uses a new challenge; signCount increments ensure cloned credentials or replays are detectable. Attestation data supports additional trust, though many servers ignore it. Together these safeguards limit phishing and credential stuffing. The end result is a flow that proves possession of a hardware-backed credential without exposing or transmitting a password-like secret to the server.

REAL-WORLD TAKEAWAYS AND POTENTIAL IMPROVEMENTS

TAKEAWAYS: The video provides a concrete end-to-end passkey workflow: requesting creation data, generating keys with the OS/TPM, and using those keys to sign login challenges. It highlights the benefit of tracing raw data instead of relying on libraries to understand the exchanges. Key lessons include credential ID mapping to public keys, when attestation matters, and how user verification prompts affect UX. Potential improvements include better tooling, error handling, and stronger server side validation patterns.

Mentioned in This Episode

●Tools & Products

WebAuthn Passkey Implementation Cheat Sheet

Practical takeaways from this episode

Do This

Fetch creation arguments from the server (getCreationArguments) and pass them to navigator.credentials.create.

Handle TPM-backed attestation, and store the credential ID and public key server-side for future authentication.

During login, fetch allowed credentials and challenge, then call navigator.credentials.get with the correct user and credential list.

Verify clientData.origin, challenge, and the signature on the server side; store credentials securely in your database.

Avoid This

Do not skip user verification where available; respect userPresence/userVerification requirements.

Do not reuse old challenges; rely on unique, non-replayable challenges and fresh attestation data.

Common Questions

The browser requests creation parameters from the server (creation args), then calls navigator.credentials.create to generate a new key pair on the device. The private key is stored securely (e.g., in a TPM), and the server stores a credential ID and the public key for future logins. This flow is designed to prevent password reuse and replay attacks.