Trait webauthn_rs::core::WebauthnConfig[−][src]

pub trait WebauthnConfig {

Show 13 methods    fn get_relying_party_name(&self) -> &str;

    fn get_origin(&self) -> &str;

    fn get_relying_party_id(&self) -> &str;

    fn get_credential_algorithms(&self) -> Vec<COSEAlgorithm> { ... }

    fn get_authenticator_timeout(&self) -> u32 { ... }

    fn get_attestation_preference(&self) -> AttestationConveyancePreference { ... }

    fn get_authenticator_attachment(&self) -> Option<AuthenticatorAttachment> { ... }

    fn get_require_resident_key(&self) -> bool { ... }

    fn get_require_uv_consistency(&self) -> bool { ... }

    fn ignore_unsupported_attestation_formats(&self) -> bool { ... }

    fn require_valid_counter_value(&self) -> bool { ... }

    fn policy_verify_trust(&self, pad: ParsedAttestationData) -> Result<(), ()> { ... }

    fn allow_cross_origin(&self) -> bool { ... }

}
Expand description

The WebauthnConfig type allows site-specific customisation of the Webauthn library. This provides a set of callbacks which are used to supply data to various structures and calls, as well as callbacks to manage data persistence and retrieval.

Required methods

Returns a reference to your relying parties name. This is generally any text identifier you wish, but should rarely if ever change. Changes to the relying party name may confuse authenticators and will cause their credentials to be lost.

Examples of names could be My Awesome Site, https://my-awesome-site.com.au

Returns a reference to your sites origin. The origin is the URL to your site with protocol and port. This should rarely, if ever change. In production usage this value must always be https://, however http://localhost is acceptable for testing only. We may add warnings or errors for non-https:// urls in the future. Changing this may cause associated authenticators to lose credentials.

Examples of this value could be. https://my-site.com.au, https://my-site.com.au:8443

Returns the relying party id. This should never change, and is used as an id in cryptographic operations and credential scoping. This is defined as the domain name of the service, minus all protocol, port and location data. For example: https://name:port/path -> name

If changed, all associated credentials will be lost in all authenticators.

Examples of this value for the site https://my-site.com.au/auth is my-site.com.au

Provided methods

Get the list of valid credential algorithms that this service can accept. Unless you have speific requirements around this, we advise you leave this function to the default implementation.

Return a timeout on how long the authenticator has to respond to a challenge. This value defaults to 60000 milliseconds. You likely won’t need to implement this function, and should rely on the defaults.

Returns the default attestation type. Options are None, Direct and Indirect. Defaults to None.

DANGER: The client may alter this value, causing the registration to not contain an attestation. This is not a verified property.

You must also implement policy_verify_trust if you change this from None else this can be BYPASSED.

Get the preferred policy on authenticator attachment hint. Defaults to None (use any attachment method).

Default of None allows any attachment method.

WARNING: This is not enforced, as the client may modify the registration request to disregard this, and no part of the registration response indicates attachement. This is purely a hint, and is NOT a security enforcment.

Get the site policy on if the registration should use a resident key so that username and other details can be embedded into the authenticator to allow bypassing that part of the interaction flow.

Defaults to “false” aka non-resident keys. See also: https://www.w3.org/TR/webauthn/#resident-credential

WARNING: This is not enforced as the client may modify the registration request to disregard this, and no part of the registration process indicates residence of the credentials. This is not a security enforcement.

Enforce that the UV bit as set at registration is the same during authentication. This applies to certain classes of authenticators that if registered with userVerification::Discouraged, will still perform and enforce that userVerification is true.

For these authenticators, since they always enforce userVerification, we can use this as an extra security check, and continue to enforce that they provide user verification in all subsequent authentication operations.

Defaults to true.

If in doubt, you should leave this as the default (true).

If the attestation format is not supported, should we ignore verifying the attestation

Decides the verifier must error on invalid counter values

A callback to allow trust decisions to be made over the attestation of the credential. It’s important for your implementation of this callback to follow the advice of the w3c standard, notably:

Assess the attestation trustworthiness using the outputs of the verification procedure in step 19, as follows:

  • If no attestation was provided, verify that None attestation is acceptable under Relying Party policy.
  • If self attestation was used, verify that self attestation is acceptable under Relying Party policy.
  • Otherwise, use the X.509 certificates returned as the attestation trust path from the verification procedure to verify that the attestation public key either correctly chains up to an acceptable root certificate, or is itself an acceptable certificate (i.e., it and the root certificate obtained previously may be the same).

The default implementation of this method rejects Uncertain attestation, and will “blindly trust” self attestation and the other types as valid. If you have strict security requirements we strongly recommend you implement this function, and we may in the future provide a stronger default relying party policy.

Get the site policy on whether cross origin credentials are allowed.

A credential is cross origin if the ECMAScript context in which the credential creation functions were invoked belonged to a different origin than that of the RP the credential is being created for.

WARNING: Most browsers do not currently send the crossOrigin value so we assume where the key is absent that the credential was not created in a cross-origin context.

Implementors