FIDO2 / WebAuthn

FIDO2 defines two primary classes of authenticators, which are hardware or software components that generate and store cryptographic credentials:

• Platform Authenticators: These are integrated into a user's device, such as a Trusted Platform Module (TPM), Apple Secure Enclave, or Android Keystore. They are typically used for device-specific biometric authentication (e.g., Windows Hello, Touch ID).
• Roaming Authenticators: These are cross-platform, portable devices like USB security keys (YubiKey), NFC, or Bluetooth tokens. They can be used to authenticate across multiple devices and browsers, providing stronger phishing resistance as credentials are bound to the physical key.

FIDO2 replaces shared secrets (passwords) with asymmetric public key cryptography. During registration, the authenticator generates a unique public/private key pair for each relying party (website).

• The private key never leaves the authenticator's secure element.
• The public key and a randomly generated credential ID are sent to the relying party for storage.
• Attestation is an optional process where the authenticator cryptographically signs the public key with a certificate from its manufacturer, allowing the relying party to verify the make and model of the authenticator for policy enforcement (e.g., requiring a specific security key).

The Relying Party (RP) is the server-side component (the website or application) that verifies FIDO2 authentications. Its responsibilities are critical to security:

• Challenge Generation: Creates cryptographically random challenges for each registration and authentication ceremony to prevent replay attacks.
• Public Key Storage: Securely stores the user's public key, credential ID, and signature counter linked to their account.
• Assertion Verification: Validates the signed assertion returned by the authenticator, checking the challenge, origin, and relying party ID to prevent phishing.
• Policy Enforcement: Defines acceptable authenticator types, user verification requirements (e.g., PIN, biometric), and attestation preferences.

FIDO2 distinguishes between two forms of user consent, which are signaled to the relying party:

• User Verification (UV): Proof that the user is present and has authorized the action through a local authentication mechanism. This requires a PIN, biometric (fingerprint/face scan), or similar secret known only to the user. It provides a higher level of assurance.
• User Presence (UP): A simple proof that the user is physically interacting with the authenticator, such as pressing a button on a security key. It prevents remote attacks but is a lower assurance than UV. The relying party's policy dictates whether UV, UP, or both are required for a given operation, balancing security and user experience.

Zero Trust Architecture is a security model that eliminates implicit trust and requires continuous verification of every access request, regardless of origin. FIDO2 is a core enabling technology for Zero Trust, providing strong, phishing-resistant authentication for users and services. For agentic systems, this means every API call to read or write to a memory store must be authenticated and authorized.

• Principle: "Never trust, always verify."
• FIDO2's Role: Provides the foundational user and device authentication component.
• Agentic Application: An autonomous agent's identity (via a machine-bound passkey) must be verified before it can access isolated memory partitions or execute privileged tool calls.

The Principle of Least Privilege dictates that users, processes, and systems should be granted the minimum levels of access necessary to perform their function. FIDO2/WebAuthn authenticates an entity (user or agent). Authorization policies, such as Role-Based Access Control (RBAC), must then enforce least privilege on top of this authentication. In agentic memory systems, this controls which memory segments an agent can read or modify.

• Core Concept: Minimize attack surface by restricting access rights.
• Workflow: 1. FIDO2 authenticates who is making the request. 2. Policy engines determine what they are allowed to do.
• Example: An agent tasked with analyzing support tickets may be authenticated via a passkey but authorized to read only the ticket_analysis memory namespace, not the financial_records namespace.

Immutable logs are append-only, tamper-evident records of events that cannot be altered or deleted after creation. FIDO2 transactions generate cryptographic signatures that are ideal for inclusion in such logs. For agentic memory consistency, logging all authentication events and major memory operations (writes, accesses) creates an auditable trail of agent activity.

• Key Property: Cryptographic integrity (e.g., via chained hashes).
• FIDO2 Data: Logs include the credential ID, relying party ID, signature counter, and attestation data.
• Security Benefit: Provides non-repudiation and enables forensic analysis if an agent's behavior needs to be investigated, supporting memory isolation breach detection.

A Hardware Root of Trust is an immutable, secure cryptographic engine embedded within a hardware component that serves as the foundational source for verifying system integrity. In FIDO2, the authenticator (a security key or device's TPM/secure element) acts as this root of trust. It securely generates and protects the private key, ensuring the credential cannot be cloned or extracted.

• Examples: Trusted Platform Module (TPM), Secure Enclave, dedicated security chip.
• FIDO2 Implementation: Enables device-bound passkeys where the private key is non-exportable.
• Agentic System Impact: Guarantees that an agent's authenticated identity is tied to a specific, verified piece of hardware, crucial for memory access control in high-security deployments.