Trait AuthenticatorBackendHashedClientData 

pub trait AuthenticatorBackendHashedClientData {
    // Required methods
    fn perform_register(
        &mut self,
        client_data_hash: Vec<u8>,
        options: PublicKeyCredentialCreationOptions,
        timeout_ms: u32,
    ) -> Result<RegisterPublicKeyCredential, WebauthnCError>;
    fn perform_auth(
        &mut self,
        client_data_hash: Vec<u8>,
        options: PublicKeyCredentialRequestOptions,
        timeout_ms: u32,
    ) -> Result<PublicKeyCredential, WebauthnCError>;
}

Available on crate features ctap2 only.

AuthenticatorBackend with a client_data_hash parameter, for proxying requests.

Note: unless you’re proxying autentication requests, use the AuthenticatorBackend trait instead. There is an implementation of AuthenticatorBackend for T: AuthenticatorBackendHashedClientData.

Normally, AuthenticatorBackend takes the origin and options.challenge parameters, serialises it to JSON, and then hashes it to produce client_data_hash, which the authenticator signs. That JSON and the signature are returned to the relying party, which it can check contain expected values and are signed correctly.

This doesn’t work when proxying an authenticator, where an initiator (web browser) has already produced a client_data_hash for the authenticator to sign, and changing it will cause the authenticator to sign something else (and fail verification).

This trait instead takes a client_data_hash directly, and ignores the options.challenge parameter. The downside is that this can’t return a client_data_json (the value is unknown), because the authenticator wouldn’t normally get a client_data_json.

This is similar to BrowserPublicKeyCredentialCreationOptions.Builder.setClientDataHash() on Android (Google Play Services FIDO API), which Chromium uses to proxy caBLE requests (which only contain client_data_json) to an authenticator stored in the device’s secure element.

AuthenticatorBackendHashedClientData provides a AuthenticatorBackend implementation – so backends should only implement one of those APIs, preferring to implement AuthenticatorBackendHashedClientData if possible.

This interface won’t be feasiable to implement on all platforms. For example, Windows’ Webauthn API takes a client_data_json and always hashes it, and Apple’s Passkey API takes relyingPartyIdentifier (origin) and challenge parameters and generates the client_data_json for you.

Most clients should prefer to use the AuthenticatorBackend trait.

See also: perform_register_with_request, perform_auth_with_request

Required Methods

fn perform_register( &mut self, client_data_hash: Vec<u8>, options: PublicKeyCredentialCreationOptions, timeout_ms: u32, ) -> Result<RegisterPublicKeyCredential, WebauthnCError>

fn perform_auth( &mut self, client_data_hash: Vec<u8>, options: PublicKeyCredentialRequestOptions, timeout_ms: u32, ) -> Result<PublicKeyCredential, WebauthnCError>

Implementors

impl AuthenticatorBackendHashedClientData for SoftPasskey

Available on crate features softpasskey only.

impl AuthenticatorBackendHashedClientData for SoftToken

Available on crate features softtoken only.

impl AuthenticatorBackendHashedClientData for SoftTokenFile

Available on crate features softtoken only.

impl<'a, T: Token, U: UiCallback> AuthenticatorBackendHashedClientData for CtapAuthenticator<'a, T, U>

Wrapper for Ctap20Authenticator’s implementation of AuthenticatorBackendHashedClientData.

impl<T: Token, U: UiCallback> AuthenticatorBackendHashedClientData for Ctap20Authenticator<'_, T, U>