Passkey Reflect

Register a passkey, then read back everything the exchange actually contained — the challenge, the flags, the attestation, and the public key itself.

This site was written by an AI assistant (GitHub Copilot) — the server, the deployment scripts and the guides — from a written specification, and it has not been audited. Read the code before you trust it.

1 Choose what to ask for

These become the PublicKeyCredentialCreationOptions that the server sends after you press register. Change them and watch how the response changes.

Start from a typical setup

Most consumer sites ask for almost exactly this: no attestation, a resident (“discoverable”) credential preferred so the passkey can usually be offered without a username, user verification left to the device, no restriction on which authenticator, and the two algorithms that everything supports. It is the shape of the passkey flows on large consumer sites such as GitHub — representative of the pattern rather than a byte-for-byte copy of any one site.

Whether the authenticator keeps the credential on itself, so it can be found without the site naming it.

Whether the authenticator must check it is really you, rather than only that someone is present.

Restricts the choice to a built-in authenticator or to a removable one.

Algorithms offered, strongest first

The authenticator picks one, and whichever it picks signs the attestation and every later assertion. The number in brackets is that algorithm’s COSE algorithm identifier from the IANA COSE Algorithms registry. It is not a version or a strength rating: it is the same value you will later see inside the public key as the alg member, and again in the signature panel. Every registered signature algorithm happens to sit in the negative range, which is why they all have a minus sign. The link opens in a new tab, because navigating away would end this session and everything in it.

They are ordered strongest first, by the security level of the parameters each one names, taking RSA at the 2048-bit modulus authenticators actually use — roughly 112 bits. For RSA the hash choice does not raise that level, only the modulus does, so all three PSS variants sit below the 128-bit elliptic curve options, and PKCS#1 v1.5 comes last because it is the weaker padding construction. Hover any option for its nominal strength.

That is a different order from the one most sites use. ES256 is the most widely supported algorithm in the list; put it first and an authenticator that could have used something stronger will still work, so leading with ES512 is a deliberate choice in favour of strength over compatibility. Only algorithms this server can actually verify are listed: ES384 (−35) is a real WebAuthn algorithm, but the verifying library has no identifier for it, so offering it would produce a response that could never be checked.

Hints (advisory only)

These suggest a kind of authenticator to the browser but restrict nothing.

2 What the server is holding about you

This is the whole of the server’s memory about you: one encrypted cookie, and nothing on the server side at all. No other browser can reach it, because there is nothing to look up and the cookie cannot be read or forged without the server’s key.