Server Requirements (WebAuthn Level 2 and CTAP2.1)

1. Introduction

The WebAuthn specification is fairly simple in its concept: it provides a method for registering new authenticators with a server (navigator.credentials.create()) and another method for authenticating with previously registered authenticators (navigator.credentials.get()). During registration, an authenticator uses an attestation private key that was embedded in the authenticator during its manufacturing to create an attestation statement, thus providing a root of trust for the registration process. Registration creates a new key pair for each account that is registered and the private key of the registration is used to sign an assertion that is sent to the server to demonstrate valid authentication. The sections that follow describe the registration and attestation requirements, and the authentication and assertion requirements.

It should be noted that there is no specific protocol (REST, SOAP, carrier pigeon, quantum teleportation, etc.) required for the server (although there are requirements around having a secure communication channel). It is assumed that servers are receiving some form of the JavaScript objects that were created by the browser, the platform, or the authenticator. Note that these objects are signed over, so protocols MUST NOT alter the signed objects in ways that would cause the signature to be invalid, but otherwise, any form of transporting these objects to the server is acceptable. The requirements and guidelines laid out below do not make any requirements on how these objects are sent or received by the server.

In the case that this specification conflicts with the [WebAuthn] specification, the [WebAuthn] specification takes precedence; however, there may be clarifications or additions in this specification that supersede the [WebAuthn] specification and many of the descriptions of how to implement WebAuthn in a web browser are irrelevant to server implementers.

2. Registration and Attestations

Servers MUST use random challenges for each registration request. While determining the randomness of a challenge is beyond the scope of this specification (see [FIDOSecRef] for more details), using the same challenge, monotonically increasing challenges, or other simple challenges is unacceptable and insecure and it is expected that a cryptographically secure random number generator is used for generating challenges.

2.1. Validating Attestations

Servers MUST validate attestation certificate chains.

Servers MUST support the validation of attestations through the FIDO Metadata Service [FIDOMetadataService].

Servers MAY have policies to allow, disallow, require additional authentication factors, or perform risk analysis for authenticators based on their metadata attributes.

2.2. Attestation Types

• Servers MUST support basic attestation

• Servers MUST support self-attestation

• Servers MAY support Privacy CA attestation

• Servers MAY support Elliptic Curve Direct Anonymous Attestation (ECDAA)

2.3. Attestation Formats

The Web Authentication § 8 Defined Attestation Statement Formats defines multiple attestation formats, and the [WebAuthn-Registries] registry may be updated from time to time to add additional attestation formats as the ecosystem evolves.

• Servers MUST support Packed Attestation: Web Authentication § 8.2 Packed Attestation Statement Format

• Servers MUST support TPM Attestation: Web Authentication § 8.3 TPM Attestation Statement Format.

• Servers MAY support Android Key Attestation: Web Authentication § 8.4 Android Key Attestation Statement Format

• Servers MUST support U2F Attestation: Web Authentication § 8.6 FIDO U2F Attestation Statement Format

• Servers MUST support Android SafetyNet Attestation: Web Authentication § 8.5 Android SafetyNet Attestation Statement Format

• Servers MAY support other attestation formats as defined by [WebAuthn-Registries], which may be updated from time to time. If authenticators or servers create new attestation formats, they SHOULD be registered with the [WebAuthn-Registries] registry.

2.3.1. Packed Attestation

Servers MUST validate a Packed attestation using the "Validation Procedure" defined in Web Authentication § 8.2 Packed Attestation Statement Format

2.3.2. TPM Attestation

Servers MUST validate a TPM attestation using the "Validation Procedure" defined in Web Authentication § 8.3 TPM Attestation Statement Format

2.3.3. Android Key Attestation

Servers MAY validate an Android Key attestation using the "Validation Procedure" defined in Web Authentication § 8.4 Android Key Attestation Statement Format. This comes in the form of a DER-encoded x.509 certificate.

2.3.4. Android SafetyNet Attestation

Servers MUST validate an Android SafetyNet attestation using the "Validation Procedure" defined in Web Authentication § 8.5 Android SafetyNet Attestation Statement Format

2.3.5. U2F Attestation

Servers MUST validate a U2F attestation using the "Validation Procedure" defined in Web Authentication § 8.6 FIDO U2F Attestation Statement Format

3. Authentication and Assertions

Servers MUST use random challenges for each authentication request. While determining the randomness of a challenge is beyond the scope of this specification (see [FIDOSecRef] for more details), using the same challenge, monotonically increasing challenges, or other simple challenges is unacceptable and insecure and it is expected that a cryptographically secure random number generator is used for generating challenges.

Servers MUST validate assertion signatures.

Upon receiving an assertion response, the server MUST validate the assertion response using the procedure defined in Web Authentication § 7.2 Verifying an Authentication Assertion

Servers SHALL validate UP and/or UV flags.

4. Communication Channel Requirements

If servers are implementing TLS and Token Binding is available they SHOULD implement [TokenBindingProtocol] using [TokenBindingOverHttp].

5. Extensions

Servers MAY support extensions.

Servers SHOULD support Web Authentication § 10.1.1 FIDO AppID Extension (appid) for backward compatibility with FIDO U2F. Note that browsers, platforms, and other clients may or may not support extensions.

If a server implements a new extension, it SHOULD be registered in the [WebAuthn-Registries] registry.

6. Other

Servers MUST observe the security requirements in [WebAuthn] Section 5.3.5.

Servers MUST implement the algorithms below marked as Required and MAY implement those marked as Recommended and Optional. Servers MAY also implement other algorithms.

Name: RS1

• Value: -65535

• Description: RSASSA-PKCS1-v1_5 w/ SHA-1

• Reference: Section 2 of [RFC8812]

• Status: Required

Name: RS256

• Value: -257

• Description: RSASSA-PKCS1-v1_5 w/ SHA-256

• Reference: Section 2 of [RFC8812]

• Status: Required

Name: RS384

• Value: -258

• Description: RSASSA-PKCS1-v1_5 w/ SHA-384

• Reference: Section 2 of [RFC8812]

• Status: Optional

Name: RS512

• Value: -259

• Description: RSASSA-PKCS1-v1_5 w/ SHA-512

• Reference: Section 2 of [RFC8812]

• Status: Optional

Name: PS256

• Value: -37

• Description: RSASSA-PSS w/ SHA-256

• Reference: [RFC8230]

• Status: Optional

Name: PS384

• Value: -38

• Description: RSASSA-PSS w/ SHA-384

• Reference: [RFC8230]

• Status: Optional

Name: PS512

• Value: -39

• Description: RSASSA-PSS w/ SHA-512

• Reference: [RFC8230]

• Status: Optional

Name: ES256

• Value: -7

• Description: ECDSA using P-256 and SHA-256

• Reference: [RFC9053]

• Status: Required

Name: ES384

• Value: -35

• Description: ECDSA using P-384 and SHA-384

• Reference: [RFC9053]

• Status: Recommended

Name: ES512

• Value: -36

• Description: ECDSA using P-521 and SHA-512

• Reference: [RFC9053]

• Status: Optional

Name: EdDSA

• Value: -8

• Description: EdDSA signature algorithms

• Reference: [RFC8037]

• Status: Required

Name: ES256K

• Value: -47

• Description: ECDSA using secp256k1 curve and SHA-256

• Reference: [RFC8812]

• Status: Optional

Servers MUST implement the curves below marked as Required and MAY implement those marked as Recommended and Optional. Servers MAY also implement other curves.

Name: P-256

• Value: 1

• Description: EC2 NIST P-256 also known as secp256r1

• Reference: [RFC9053]

• Status: Required

Name: P-384

• Value: 2

• Description: EC2 NIST P-384 also known as secp384r1

• Reference: [RFC9053]

• Status: Recommended

Name: P-521

• Value: 3

• Description: EC2 NIST P-521 also known as secp521r1

• Reference: [RFC9053]

• Status: Optional

Name: Ed25519

• Value: 6

• Description: Edwards-curve Digital Signature Algorithm on curve 25519

• Reference: [RFC8032]

• Status: Required

Name: Ed448

• Value: 7

• Description: Edwards-curve Digital Signature Algorithm on curve 448

• Reference: [RFC8032]

• Status: Optional

Name: secp256k1

• Value: 8

• Description: SECG secp256k1 curve

• Reference: [RFC8812]

• Status: Optional

Note that, by design, only algorithms and curves actually being used by authenticators as of the time of this writing are included in the list of Required algorithms and curves. Servers wanting to be prepared in advance for possible future cryptographic developments ought to consider implementing the Recommended algorithms and curves in addition to the Required ones.

Servers MUST comply with the FIDO privacy principles [FIDOPrivacyPrinciples].