Understanding WebAuthn credential protection policy

https://news.ycombinator.com/rss Hits: 1
Summary

Understanding WebAuthn credential protection policy This post assumes you're already familiar with the basics of WebAuthn. When creating a WebAuthn credential, you can specify whether it should be discoverable using the residentKey option. const credential = await navigator.credentials.create({ publicKey: { authenticatorSelection: { residentKey: "required", // ... }, // ... }, }); However, the relying party cannot control when or how the credential can be discovered. You may want it to become discoverable only after user verification and hide the account’s existence from snooping users. This can be especially important for security keys, where unlike devices or password managers that usually require initial authentication, physical possession alone is often sufficient to reveal registered credentials. To address this, the CTAP 2.1 specification defines a new credential protection extension, available through the credentialProtectionPolicy extension input. CTAP is the specification that defines how platforms (devices/browsers) and roaming authenticators (security keys) interact. const credential = await navigator.credentials.create({ publicKey: { extensions: { credentialProtectionPolicy: "userVerificationRequired", enforceCredentialProtectionPolicy: true, }, // ... }, }); If the default value userVerificationOptional is used, the credential can be discovered and used without user verification. If userVerificationOptionalWithCredentialIDList is used, the credential cannot be discovered without user verification, but it can still be discovered and used without user verification if the credential ID is provided by the relying party. This matches the security of non-discoverable credentials. Finally, userVerificationRequired indicates that the credential cannot be discovered or used without user verification. It’s important to highlight that the extension controls credential discovery within the authenticator. It is still up to the relying party to verify whether the ass...

First seen: 2026-05-24 21:00

Last seen: 2026-05-24 21:00