FIDO2 / WebAuthn
FIDO2/WebAuthn: Relying Party Implementation, Phishing Resistance and Security

FIDO2 / WebAuthn FIDO2-RP-Identity: Relying Party Identifier, Origin Binding, Cross-Origin and Conditional UI

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 activation required + presented as a suggestion in autofill chip. RATE LIMITING + ACCOUNT LOCKOUT: RP server should rate-limit ceremony attempts per user + per IP + per session to prevent enumeration + DoS; authenticator-level PIN throttling complements RP limits. SESSION BINDING: after successful authentication issue a SESSION TOKEN bound to the user-agent + IP-class + with appropriate expiration; token binding (RFC 8471 + 8472) provides cryptographic binding but is now deprecated; current best practice is mTLS or DPoP + secure cookies (HttpOnly + Secure + SameSite=Lax/Strict).

Maintained by Gerard BlokdykVerified against the published standard Control text last updated

Other controls in FIDO2/WebAuthn: Relying Party Implementation, Phishing Resistance and Security

Query this from an agent

The graph holds this control, the 0 it maps to, and the evidence behind each claim, over MCP and REST.