FIDO2 / WebAuthn

WebAuthn attestation per L3 6.5 + FIDO Authenticator Allowed Cryptography List. Attestation provides assurance about the authenticator's origin + characteristics. ATTESTATION FORMATS: packed (most common, FIDO Alliance default - uses authenticator attestation certificate + AAGUID + signature); fido-u2f (legacy U2F format, ECDSA P-256 with x.509); tpm (Trusted Platform Module attestation with AIK certificate + tpmsAttestation); android-key (Android Keystore attestation with key attestation chain); android-safetynet (legacy SafetyNet attestation deprecated 2023 replaced by Play Integrity); apple (Apple anonymous attestation for Touch ID / Face ID); apple-appattest (App Attest for iOS apps); none (no attestation - anonymous). ATTESTATION TYPES: Basic (manufacturer per-batch key); Self (key-pair self-signed); AttCA (Privacy CA model with separate AIK); ECDAA (Elliptic Curve Direct Anonymous

• Attestation verification implementation + tests
• Trust anchor configuration
• AAGUID allow/deny list
• Status indicator check

• Attestation not verified at registration
• Trust anchor missing or stale
• AAGUID consistency not verified
• Status indicator (revoked / fido_certified_l1) ignored

Enterprise attestation per WebAuthn L3 6.5.4 + CTAP2.1. Standard attestation is ANONYMOUS per AAGUID batch (so individual authenticators are not identifiable) to protect privacy. ENTERPRISE ATTESTATION carries the AUTHENTICATOR-UNIQUE IDENTIFIER (e.g. serial number) in the attestation statement, allowing enterprise managed-device deployments to track individual hardware authenticators. REQUIREMENTS: (a) authenticator MUST support enterprise attestation as a feature; (b) authenticator MUST be configured by the device manufacturer or enterprise + tied to a specific RP ID (vendor-facilitated) OR by enterprise platform configuration (platform-managed) to release enterprise attestation only to authorised RPs; (c) client + browser MUST support + honour enterprise attestation per attestation = enterprise option; (d) RP MUST verify enterprise attestation flag + the unique identifier matches the

• Enterprise attestation configuration + audit
• AAGUID enterprise allowlist + inventory
• Privacy boundary (only enterprise RPs)

• Enterprise attestation used for consumer scenarios (privacy gap)
• AAGUID enterprise allowlist not maintained
• RP ID enterprise binding not enforced

FIDO Metadata Service v3 (MDS3) provides the metadata + trust + status for FIDO authenticators. ENDPOINT: https://mds.fido.org/ + signed metadata BLOB updated regularly. METADATA STATEMENT contents per AAGUID: AAGUID; description; authenticator + protocol family (FIDO_2_1 + U2F + UAF + etc.); upv (Universal Authenticator Framework Protocol Versions); authenticationAlgorithms; publicKeyAlgAndEncodings; attestationTypes (BASIC + SELF + ATT_CA); userVerificationDetails; keyProtection (HARDWARE + SECURE_ELEMENT + TEE + SOFTWARE); matcherProtection; attachmentHint; isKeyRestricted; isFreshUserVerificationRequired; cryptoStrength; tcDisplay; attestationRootCertificates; ecdaaTrustAnchors; icon. STATUS REPORTS per AAGUID: NOT_FIDO_CERTIFIED; FIDO_CERTIFIED + FIDO_CERTIFIED_L1 + L2 + L3 + L3+; USER_VERIFICATION_BYPASS (security alert); ATTESTATION_KEY_COMPROMISE; USER_KEY_REMOTE_COMPROMISE; USER

• MDS3 client integration + caching
• AAGUID policy by certification level
• Status alert handling (REVOKED + COMPROMISE)

• MDS3 not consumed (AAGUID not validated)
• Status reports ignored
• Certification level policy too permissive

Discoverable credentials (formerly Resident Credentials) per WebAuthn L3 6.3 + CTAP2.1 are credentials whose private-key + per-credential metadata (rpId + userHandle + signCount) are stored on the authenticator. The user-handle enables AUTHENTICATION WITHOUT USERNAME - the RP can call navigator.credentials.get() without allowCredentials + the authenticator presents matching credentials to the user for selection. PASSKEYS: marketing name for FIDO2 discoverable credentials that ALSO support multi-device sync. Apple iCloud Keychain (2022) + Google Password Manager (2023) + Microsoft Windows Hello + 1Password + Bitwarden + Dashlane support passkey synchronisation across user devices. BACKUP ELIGIBILITY (BE) + BACKUP STATE (BS) FLAGS in authenticatorData: BE indicates the credential CAN be backed up; BS indicates the credential IS currently backed up. RP USE: BE+BS=11 indicates a synced passk

• Resident key + UV policy at registration
• Multi-device recovery enrolment
• Account recovery procedure + identity verification
• Backup state tracking + risk decisions

• Single-device credential without recovery enrolment
• Backup state not tracked
• Account recovery weakened by easier-than-passkey path
• Passkey portability assumed across ecosystems

User Verification (UV) confirms the user is present + intended the operation. UV factors local to authenticator: PIN (4-63 ASCII + CTAP2.1 setMinPINLength enforcement); BIOMETRIC (fingerprint + face + iris + voice + behavioural - all template-local-to-authenticator never transmitted); PRESENCE-ONLY (UP flag indicates physical interaction like button press without authentication of identity). UV FLAGS in authenticatorData: UP (user presence) - physical interaction; UV (user verified) - identity verified via PIN or biometric. RP UV REQUIREMENT: required = UV flag MUST be set; preferred = UV flag SHOULD be set if authenticator supports; discouraged = UV flag MAY be set but not required. PIN/UV AUTH PROTOCOL: clients obtain pinUvAuthToken with specific permission scope (mc/ga/bi/cm/cv/acfg) for authenticator commands. NIST SP 800-63B coordination: AAL2 typically presence-only sufficient; AAL

• UV requirement policy per RP workflow
• Authenticator UV capabilities + AAGUID
• FIDO Biometric Component Certification check

• UV=preferred when assurance requires required
• Minimum PIN length too low
• Biometric template transmitted off-authenticator
• FAR/FRR/PAD certification not verified

CTAP2 PIN/UV authentication establishes user verification + permission tokens. PIN: 4-63 ASCII character minimum (CTAP2.1 setMinPINLength may force higher); the PIN is hashed + key-derived locally on the authenticator + used in PIN/UV Auth Protocol exchanges; PIN-CHANGE + PIN-RETRIES with throttling + lockout (typically 8 attempts before factory reset). PIN/UV AUTH PROTOCOL: ECDH key exchange between client + authenticator + a derived shared secret + token-based permission scope (mc + ga + bi + cm + cv + acfg); pinUvAuthToken is returned with selected permission set + lifetime + used to authorise subsequent commands without re-prompting. BIOMETRIC UV: authenticator-internal biometric (fingerprint + face + iris) replaces or augments PIN; biometric template never leaves authenticator; UV result returned to client. UV REQUIREMENT in WebAuthn: required = UV must succeed; preferred = UV reque

• PIN/UV policy aligned with RP requirements
• Biometric UV deployment evidence
• UV required for AAL3 workflows

• UV=discouraged for high-assurance scenarios
• Minimum PIN length too low
• Biometric data transmitted off-authenticator (PROHIBITED)

CTAP2 transports define how the client communicates with the authenticator. USB-HID: USB Human Interface Device class for security keys (YubiKey + Token2 + Feitian + SoloKeys + Trezor + others); FIDO2 HID protocol with CTAPHID frames. NFC: ISO 14443 Type A/B for NFC-capable security keys + phones acting as authenticators; CTAPNFC protocol. BLE-ROAMING: Bluetooth Low Energy GATT service profile for roaming authenticators; FIDO BLE service UUID 0xFFFD. HYBRID TRANSPORT (formerly caBLE - Cloud Assisted BLE): cross-device authentication via QR code + BLE proximity proof + cloud-mediated key exchange; the desktop browser displays a QR code containing a tunnel server URL + the phone scans + executes the FIDO2 ceremony on the phone + relays the assertion back via BLE proximity + tunnel server; specified in CTAP2.2 + WebAuthn L3 hints. PLATFORM-INTERNAL: built-in platform authenticators (Touch I

• Supported transports declared in authenticatorGetInfo
• Hybrid transport QR + BLE proximity flow
• Platform authenticator detection + use

• Transports incorrectly declared
• Hybrid transport BLE proximity gap
• Platform authenticator misidentified as cross-platform

FIDO Client-to-Authenticator Protocol 2.1 (CTAP2.1, FIDO Alliance Proposed Standard). The protocol between the client (operating system + browser) + authenticator devices. CTAP2.1 COMMANDS: authenticatorMakeCredential (registration); authenticatorGetAssertion (authentication); authenticatorGetInfo (capabilities + AAGUID + transports + algorithms + extensions); authenticatorClientPIN (PIN setup + change + token); authenticatorReset (factory reset); authenticatorBioEnrollment (biometric enrollment); authenticatorCredentialManagement (list + delete credentials on the authenticator); authenticatorSelection (selection between multiple authenticators); authenticatorLargeBlobs (large blob storage); authenticatorConfig (turn pinUvAuthToken on/off; setMinPINLength); authenticatorReset. CTAP2.1 features over 2.0: PIN minimum length enforcement (configurable per RP); PIN/UV authentication tokens fo

• CTAP2.1 version + capability negotiation
• authenticatorGetInfo + AAGUID validation
• Credential management on authenticator
• Enterprise attestation configuration

• CTAP2.0 only support (missing 2.1 features)
• Minimum PIN length not enforced
• Credential management without UV token
• Enterprise attestation misconfigured

FIDO Alliance certification programmes ensure interoperable + secure implementations. PROGRAMMES: (a) FIDO2 Authenticator Certification (L1 + L2 + L3 + L3+) - tests CTAP2 + WebAuthn compliance + cryptographic implementation + side-channel resistance + secure-element integration; (b) FIDO2 Server Certification - tests RP-side compliance with WebAuthn + attestation verification + extension handling; (c) UAF Authenticator + Server Certification (legacy mobile FIDO 1.x); (d) U2F Authenticator + Server Certification (legacy second-factor only); (e) FIDO Biometric Component Certification - tests biometric subsystem against FAR + FRR + PAD (Presentation Attack Detection) targets per ISO/IEC 30107-3. ACCREDITED LABS: SGS Brightsight + Cigital + Riscure + Synopsys + UL + others - independent test labs accredited by FIDO Alliance. CONFORMANCE TESTS: published test suites for authenticators + serve

• Certification level policy in MDS3
• Authenticator inventory + cert level
• Server certification status if applicable

• Non-certified authenticators accepted for high-assurance
• Biometric component without FIDO Biometric Component Certification
• MDS3 status (revoked / compromise) not enforced

FIDO2/WebAuthn implementation status as of 2026. STANDARDS BASE: W3C WebAuthn Level 3 Recommendation (2024); FIDO CTAP2.1 (FIDO Alliance Proposed Standard 2021 + 2.2 Editor Draft for hybrid transport); FIDO Metadata Service v3 (FIDO Alliance 2021); WebAuthn Level 4 in development with extensions for credential-exchange-protocol + PRF improvements + cross-device coordination. PASSKEY ADOPTION: Apple iCloud Keychain (2022) + Google Password Manager (2023) + Microsoft Windows Hello (2023) + 1Password + Bitwarden + Dashlane (2023-2024) all support passkeys with sync; major sites including Google + Microsoft + Apple + GitHub + PayPal + Shopify + Best Buy + eBay + Amazon (2024-2025) support passkey login; the FIDO Alliance Passkey Pledge campaign (2024) tracks passkey adoption metrics. GOVERNMENT: NIST SP 800-63B AAL3 phishing-resistant + 2022 OMB M-22-09 + 2024 ZTA strategy mandate FIDO2 + PI

• WebAuthn + CTAP version tracking
• Passkey rollout plan + recovery enrolment
• Government mandate compliance evidence
• Threat-monitoring + standard-evolution tracking

• Implementing legacy U2F + UAF without FIDO2 migration plan
• Passkey recovery weakened by easier non-passkey path
• Government mandate not aligned (e.g. AAL3 needs UV + FIDO2)
• Hybrid-transport proximity downgrade not mitigated

WebAuthn authentication ceremony per W3C L3 5.2 (Credential Assertion). FLOW: (1) RP server generates PublicKeyCredentialRequestOptions: challenge + rpId + (optional) allowCredentials + userVerification + hints + extensions + sends to client. (2) Client calls navigator.credentials.get({publicKey: options}) with user activation + secure context. (3) Browser presents UI + selects authenticator + may use conditional UI for autofill. (4) Authenticator authenticatorGetAssertion CTAP2 command: locates matching credential + verifies user (presence + UV per requirements) + increments signCount + signs (authenticatorData + clientDataHash) with credential private key. (5) Browser returns AuthenticatorAssertionResponse: credentialId + clientDataJSON + authenticatorData + signature + userHandle + clientExtensionResults. (6) RP server VERIFIES: clientDataJSON.type=webauthn.get + challenge match + ori

• Authentication validation code + tests
• SignCount tracking + clone detection
• Backup state tracking for passkey detection

• Challenge or origin not validated
• Signature verified against wrong public key
• SignCount not validated (clone undetected)
• Backup state ignored for risk-based decisions

WebAuthn registration ceremony per W3C L3 5.1 (Credential Creation). FLOW: (1) RP server generates PublicKeyCredentialCreationOptions including challenge + user + rp + pubKeyCredParams + authenticatorSelection + attestation + extensions + sends to client. (2) Client (browser) calls navigator.credentials.create({publicKey: options}) with user activation + secure context + origin matching rpId. (3) Browser presents UI for authenticator selection + user activation. (4) Authenticator authenticatorMakeCredential CTAP2 command: generates new key pair + stores credential (resident if requireResidentKey) + outputs attestation object (authenticatorData with RP ID hash + flags including UP + UV + BE + BS + AT + ED + counter + AAGUID + credentialId + credentialPublicKey + extensions + attestationStatement). (5) Browser returns PublicKeyCredential to RP including clientDataJSON (challenge + origin +

• Registration validation code + tests
• Per-step verification log
• Counter init + tracking
• Credential storage schema

• Challenge or origin not validated
• RP ID hash not validated
• Flag UP/UV requirements not enforced
• Algorithm not in pubKeyCredParams accepted
• Counter not initialised at registration

FIDO2 PHISHING RESISTANCE properties + the channel binding + anti-replay + privacy mechanisms. PHISHING RESISTANCE: WebAuthn ceremonies bind the authentication to the ORIGIN (cryptographically verified by the client + RP server); a phishing site at evil.example.com cannot complete a WebAuthn assertion for legitimate.example.com - the browser + authenticator refuse the binding. NIST SP 800-63B Section 5.2.5 + the 2024 OMB M-22-09 + ZTA strategy mandate phishing-resistant authentication for high-impact federal systems + recommend FIDO2 + PIV/CAC. CHANNEL BINDING (legacy via Token Binding RFC 8471/8472, now deprecated) bound the assertion to the TLS channel preventing relay; the current model relies on origin binding + clientDataJSON inclusion in the signed authenticatorData + clientDataHash. ANTI-REPLAY: challenge-based per ceremony + signature counter (signCount monotonic) + anti-replay t

• Origin binding verification + tests
• SignCount monotonic enforcement
• Clone-detection response procedure
• Privacy boundary documentation

• Origin binding bypassed via misconfiguration
• SignCount not checked
• Clone not handled with revocation or step-up
• Enterprise attestation used outside managed-device scope

RP ID + origin binding define the SCOPE of a credential. RP ID: an effective domain (e.g. example.com) - a credential created with rpId=example.com works for example.com + www.example.com + login.example.com but NOT for evil.com NOR sub.different.com. The RP ID hash is in authenticatorData + verified by RP server. ORIGIN: the full origin (scheme + host + port, e.g. https://login.example.com:443) - the client always validates the origin against the rpId effective-domain rule. CROSS-ORIGIN AUTHENTICATION: WebAuthn L3 permits authentication ceremonies in iframes via Permissions Policy + the crossOrigin flag in clientDataJSON; cross-origin registration is NOT permitted. CONDITIONAL UI / AUTOFILL: navigator.credentials.get({mediation: conditional}) + autocomplete=webauthn attribute on form fields enables passkey autofill UI integrated with browser password autofill - no explicit user activati

• RP ID + origin enforcement code
• Cross-origin Permissions Policy configuration
• Conditional UI integration
• Rate limiting + session token policy

• RP ID too broad (e.g. com or single-character)
• Cross-origin allowed for registration (PROHIBITED)
• Rate limiting missing
• Session token without binding or with weak expiration

W3C Web Authentication Level 3 Recommendation (W3C TR). The WebAuthn API provides: (a) navigator.credentials.create() for REGISTRATION of a new PublicKeyCredential; (b) navigator.credentials.get() for AUTHENTICATION assertion. The API operates between the relying party + the client (user agent / browser) + the authenticator. Level 3 (Recommendation 2024) extends Level 2 (2021) + Level 1 (2019) with: PRF extension for symmetric secret derivation + HMAC operations; conditional UI improvements; cross-origin authentication via iframes; backup eligibility + backup state flags for passkey synchronisation indication; large blob extension for binding additional data; hints for authenticator-selection UX. Extensions: appid + appid-exclude for FIDO U2F migration; hmac-secret; credProtect; credBlob; minPinLength; largeBlobKey; payment for Secure Payment Confirmation; prf for derived keys. RP must u

• RP integration with WebAuthn API L3
• Extensions used + version pinned
• Secure context + user-activation enforcement

• Using WebAuthn L1/L2 features incompatible with L3
• Extensions not feature-detected
• Insecure context (non-HTTPS) deployment

PublicKeyCredentialCreationOptions (registration) + PublicKeyCredentialRequestOptions (authentication) parameters. CREATION OPTIONS: rp (RP ID + name); user (id + name + displayName); challenge (cryptographically random 16+ byte); pubKeyCredParams (algorithm priority list - ES256/EdDSA/RS256); timeout; excludeCredentials (prevent re-registration); authenticatorSelection (authenticatorAttachment platform/cross-platform + requireResidentKey/residentKey + userVerification required/preferred/discouraged + hints); attestation (none/indirect/direct/enterprise); attestationFormats; extensions. REQUEST OPTIONS: challenge; rpId; allowCredentials (optional); userVerification; hints; extensions. ALGORITHM PRIORITIES: ES256 (ECDSA on P-256) + EdDSA (Ed25519) recommended; RS256 acceptable for legacy; AVOID ES384 + RS384 unless required; PREFER public-key algorithm support negotiation through pubKeyCr

• Server-side challenge generation + entropy
• RP ID + origin verification
• Algorithm priority list configuration
• Authenticator selection policy

• Challenge insufficient entropy or reused
• RP ID mismatched with origin
• Algorithm priority too permissive (e.g. RS256 accepted)
• UV preferences inconsistent with assurance level