FIDO2 Core Concepts

This document provides a quick reference to the essential concepts in FIDO2 authentication with the Arculus Authenticate system.

Two Core Operations

There are two core authentication operations used when working with a FIDO2 server: Registration and Authentication. Registration creates a new credential on the authenticator solution (the Arculus card and the Arculus FIDO2 server). The Authentication operation is used to prove ownership of an existing credential.

1. Registration (Attestation)

User -> App -> Server: "I want to register"
Server -> App: Challenge + Options
App -> Authenticator: Create credential
Authenticator -> App: New public key + attestation
App -> Server: Store credential

2. Authentication (Assertion)

User -> App -> Server: "I want to authenticate"
Server -> App: Challenge + credential list
App -> Authenticator: Sign challenge
Authenticator -> App: Signed assertion
App -> Server: Verify signature
Server -> App: Success + token

Authentication Factors

The Arculus Authenticate solution provides multi-factor authentication in a single gesture:

Factor	What It Proves	Provided By
Something you have	Possession of the authenticator	Arculus Authenticate (Arculus Card)
Something you know	PIN verification	Arculus Authenticate (PIN)
Something you are	Biometric verification	Customer Primary Authentication (Platform Authenticators: Touch ID, Face ID, Windows Hello)

User Verification Levels

Level	Meaning	Use Case
discouraged	Skip verification	Convenience-focused
preferred	Verify if available	Balanced (default)
required	Must verify	High-security

Attestation Types

Type	Data Provided	Privacy
none	No device info	Maximum
indirect	Anonymized info	Medium
direct	Full device info	Minimum

Authenticator Attachment

Type	Description	Use Case
platform	Built-in to device	Same device authentication
cross-platform	External, portable	Arculus Card, security keys
all	No preference	Maximum compatibility

Challenge-Response Flow

1. Server generates random challenge
2. Client receives challenge
3. Authenticator signs challenge with private key
4. Server verifies signature with stored public key
5. Success if signature valid

Security Properties:

• Challenge is random and one-time use

• Signature proves private key possession

• No replay attacks possible

Credential Storage

On Authenticator (Private)

• Private key (never exported)

• Credential ID

• User handle (optional)

• Counter

On Server (Public)

• Public key

• Credential ID

• User ID

• AAGUID (authenticator model)

• Registration metadata

• Signature counter

Multi-Device Support

Users can register multiple authenticators:

User "[email protected]"
  |
  +-- Arculus Card (credential A)
  +-- YubiKey (credential B)
  +-- Face ID (credential C)

Any registered authenticator can authenticate the user.

Session Flow

Begin Request -> Create Session -> Store Challenge
     |
     v
[User interacts with authenticator]
     |
     v
Complete Request -> Retrieve Session -> Verify Challenge
     |
     v
Clear Session -> Return Result

Session Timeout: 60 seconds default

Error Categories

Category	HTTP Status	Meaning
Validation	400, 401	Invalid request format
Not Found	403, 404	User or credential not found
Timeout	408	Session expired
Server Error	500, 507	Server-side failure

Security Counter

Protects against authenticator cloning:

Registration: counter = 0
Auth #1: counter = 1 (valid, > 0)
Auth #2: counter = 2 (valid, > 1)
Clone attempt: counter = 1 (INVALID, <= 2)

AAGUID (Authenticator Model)

16-byte identifier for authenticator type:

• 00000000-0000-0000-0000-000000000000 = Unknown/anonymous

• Specific GUID = Registered authenticator model

Used for:

• Metadata Service (MDS) lookup

• Authenticator whitelisting

• Security policy enforcement

API Endpoints Summary

Action	Endpoint
Begin Registration	POST /fidoapi/certify/attestation/options
Complete Registration	POST /fidoapi/certify/attestation/result
Begin Authentication	POST /fidoapi/certify/assertion/options
Complete Authentication	POST /fidoapi/certify/assertion/result
Health Check	GET /status
Version	GET /getversion

Integration Checklist

1. Configure relying party domain

2. Set up MongoDB connection

3. Deploy PyFIDO Server

4. Integrate SDK in your application

5. Implement registration flow

6. Implement authentication flow

7. Handle session management

8. Set up error handling