webauthn-0.4.1.1: Relying party (server) implementation of the WebAuthn 2 specification
Stabilityexperimental
Safe HaskellSafe-Inferred
LanguageHaskell2010

Crypto.WebAuthn.Operation.Registration

Description

This module implements attestation of the received authenticator response. See the WebAuthn specification for the algorithm implemented in this module. Assertion is typically represented as a "register" action in the front-end. Section 7 of the specification describes when the relying party must perform attestation. Another relevant section is Section 1.3.1 which is a high level overview of the registration procedure.

Synopsis

Documentation

verifyRegistrationResponse Source #

Arguments

:: Origin

The origin of the server

-> RpIdHash

The relying party id

-> MetadataServiceRegistry

The metadata registry, used for verifying the validity of the attestation by looking up root certificates

-> DateTime

The current time, used for verifying the validity of the attestation statement certificate chain

-> CredentialOptions 'Registration

The options passed to the create() method

-> Credential 'Registration 'True

The response from the authenticator

-> Validation (NonEmpty RegistrationError) RegistrationResult

Either a nonempty list of validation errors in case the attestation FailedReason Or () in case of a result.

(spec) The resulting rrEntry of this call should be stored in a database by the Relying Party. The rrAttestationStatement contains the result of the attempted attestation, allowing the Relying Party to reject certain authenticators/attempted entry creations based on policy.

data RegistrationError Source #

All the errors that can result from a call to verifyRegistrationResponse

Constructors

RegistrationChallengeMismatch

The received challenge does not match the originally created challenge

Fields

RegistrationOriginMismatch

The returned origin does not match the relying party's origin

Fields

RegistrationRpIdHashMismatch

The rpIdHash in the authData is not a valid hash over the RpId expected by the Relying party

Fields

RegistrationUserNotPresent

The userpresent bit in the authdata was not set

RegistrationUserNotVerified

The userverified bit in the authdata was not set

RegistrationPublicKeyAlgorithmDisallowed

The algorithm received from the client was not one of the algorithms we (the relying party) requested from the client.

Fields

forall a.AttestationStatementFormat a => RegistrationAttestationFormatError a (NonEmpty (AttStmtVerificationError a))

There was some exception in the statement format specific section

data RegistrationResult Source #

The result returned from verifyRegistrationResponse. It indicates that the operation of registering a new credential didn't fail.

Constructors

RegistrationResult 

Fields

data AuthenticatorModel k where Source #

Information about the authenticator model that created the public key credential. Depending on the constructor, this information can be used to base security decisions.

Constructors

UnknownAuthenticator :: AuthenticatorModel 'Unverifiable

An unknown authenticator, meaning that we received no information about what authenticator model was used to generate the public key credential. We therefore also cannot assume any security guarantees regarding how the key is stored and other properties of the authenticator. This is expected to be the case when the "none" Attestation Conveyance Preference was selected.

UnverifiedAuthenticator

An authenticator that provided a verifiable attestation type, see Verifiable, but the certificate chain in the attestation statement failed to be verified. This is an indication that the uaIdentifier and uaMetadata fields cannot be trusted currently. This can happen when the root certificate of the chain is not trusted or known. Root certificates are discovered using both the AttestationStatementFormats asfTrustAnchors method, and the passed MetadataServiceRegistry. The relying party can decide what to do in such a case, for example:

  1. Treating it as if it was an UnknownAuthenticator, but logging the SomeAttestationStatement structure, so that the admin can be informed of this and perhaps add custom entries to the MetadataServiceRegistry to allow such authenticators to be verified in the future
  2. Only using the uaIdentifier and uaMetadata for non-security-critical decisions. For example in order to show the user which authenticator they used to register.

Fields

VerifiedAuthenticator

An authenticator that provided a verifiable attestation type, see Verifiable and whose certificate chain in the attestation statement could successfully be verified. This is an indication that the uaIdentifier and uaMetadata fields can be trusted, meaning that we can be sure that the CredentialEntry was created from the authenticator model with these fields as properties. In this case, the Relying Party can reasonably do the following:

Fields

data SomeAttestationStatement Source #

Some attestation statement that represents both the attestation type that was returned along with information about the authenticator model that created it. This result may be inspected to enforce relying party policy, see the individual fields for more information.

Constructors

forall k. SomeAttestationStatement 

Fields