Struct RelyingParty 

pub struct RelyingParty {
    pub id: String,
    pub allowed_origins: Vec<String>,
    pub name: String,
    pub require_user_verification: bool,
    pub reject_cross_origin: bool,
    pub allowed_algorithms: Vec<i64>,
    pub require_backup_eligible: bool,
    pub reject_backup_eligible: bool,
    pub trust_anchors: Vec<Vec<u8>>,
    pub used_challenges: Option<Arc<Mutex<HashSet<Vec<u8>>>>>,
}

The relying party — your server application.

RelyingParty is the main entry point for ceremony verification. It is stateless with respect to credentials; callers pass in the data and receive result types back. This keeps the library storage-agnostic.

Create one instance per application configuration and reuse it across ceremonies. RelyingParty is Clone, so it can be shared via Arc in an async context.

Example

use webauthn::RelyingParty;

// Single origin — typical production setup.
let rp = RelyingParty::new("example.com", "https://example.com", "My Service");

// Multiple origins — e.g. prod + local dev in one instance.
let rp = RelyingParty::with_origins(
    "example.com",
    ["https://example.com", "http://localhost:8080"],
    "My Service",
);

Fields

id: String

Relying party ID, e.g. "example.com".

Must match the rpId used in the browser’s navigator.credentials.create() / get() call options.

allowed_origins: Vec<String>

The set of origins this RP accepts, e.g. ["https://example.com"].

Each entry must match window.location.origin exactly — scheme, host, and port all matter. A client-supplied origin is accepted if it equals any entry in this list.

name: String

Human-readable name shown to users, e.g. "My Service".

require_user_verification: bool

Whether the UV (User Verification) flag must be set in every authentication assertion. Defaults to false.

Set to true when your threat model requires the authenticator to verify the user’s identity (PIN, biometric, pattern) on every sign-in. See RelyingParty::require_user_verification to enable this at construction time using the builder pattern.

reject_cross_origin: bool

Whether to reject clientDataJSON that contains crossOrigin: true. Defaults to false.

A cross-origin credential use occurs when the WebAuthn call is made from an iframe whose origin differs from the top-level page. When your application never embeds WebAuthn in an iframe, set this to true to close that attack surface (§7.1 step 10 / §7.2 step 12). See RelyingParty::reject_cross_origin to enable this using the builder pattern.

allowed_algorithms: Vec<i64>

COSE algorithm identifiers this RP accepts at registration time.

When non-empty, verify_registration returns crate::error::WebAuthnError::UnsupportedAlgorithm if the credential’s algorithm is not in this list. An empty list (the default) accepts any algorithm the library supports (ES256, EdDSA, RS256).

Use RelyingParty::allowed_algorithms to set this at construction time.

require_backup_eligible: bool

Whether to reject credentials that are not backup-eligible (BE flag not set). Defaults to false.

Set to true for consumer passkey deployments that require cross-device sign-in via platform sync services (iCloud Keychain, Google Password Manager). See RelyingParty::require_backup_eligible to enable via the builder.

reject_backup_eligible: bool

Whether to reject credentials that are backup-eligible (BE flag is set). Defaults to false.

Set to true for high-security environments (banking, SSH) that require hardware-bound keys that cannot leave the device. See RelyingParty::reject_backup_eligible to enable via the builder.

trust_anchors: Vec<Vec<u8>>

DER-encoded root CA certificates used to verify the x5c attestation chain returned by the authenticator.

When non-empty, verify_registration walks the chain returned in x5c and checks that its root is signed by one of these anchors. A successful check upgrades the result to crate::credential::AttestationType::BasicVerified.

When empty (the default), the chain order is still validated (each certificate must be signed by the next), but the root is not checked against any CA set and AttestationType::Basic is returned instead.

Use RelyingParty::trust_anchors to set this at construction time.

used_challenges: Option<Arc<Mutex<HashSet<Vec<u8>>>>>

Opt-in set of challenge bytes already consumed by a completed ceremony.

None when single-use enforcement is disabled (the default). Enable via RelyingParty::enforce_single_use_challenges.

The Arc lets Cloned instances share the same tracking set so all ceremony paths that use copies of the same RelyingParty (e.g. behind an Arc<RelyingParty> in an async web handler) enforce the policy collectively rather than independently.

Implementations

impl RelyingParty

pub fn verify_authentication( &self, stored_credential: &Credential, challenge: &Challenge, response: &AuthenticatorAssertionResponse, ) -> Result<AuthenticationResult>

Verify an authentication ceremony response (W3C WebAuthn §7.2).

Call this after the client returns an AuthenticatorAssertionResponse. On Ok, update the stored credential’s sign_count to result.new_sign_count before responding to the client.

Arguments

• stored_credential — Retrieved from your database by credential ID.
• challenge — The challenge you issued for this ceremony.
• response — The assertion response from the authenticator.

Errors

Returns a crate::error::WebAuthnError variant indicating exactly which verification step failed, including SignCountInvalid for suspected authenticator clones.

impl RelyingParty

pub fn new(id: &str, origin: &str, name: &str) -> Self

Create a new RelyingParty that accepts a single origin.

Arguments

• id — Relying party ID, e.g. "example.com".
• origin — Full app origin, e.g. "https://example.com".
• name — Human-readable service name.

pub fn with_origins( id: &str, origins: impl IntoIterator<Item = impl Into<String>>, name: &str, ) -> Self

Create a new RelyingParty that accepts multiple origins.

Use this when your app is served from more than one origin — for example, https://example.com in production and http://localhost:8080 in development — and you want a single RelyingParty instance to handle both environments.

Arguments

• id — Relying party ID, e.g. "example.com".
• origins — Iterator of accepted origins.
• name — Human-readable service name.

pub fn require_user_verification(self, required: bool) -> Self

Require the UV (User Verification) flag on every authentication assertion.

When true, verify_authentication returns crate::error::WebAuthnError::UserNotVerified if the authenticator’s UV bit is not set — meaning the user was not verified via PIN, biometric, or another local gesture.

Example

use webauthn::RelyingParty;

let rp = RelyingParty::new("example.com", "https://example.com", "My Service")
    .require_user_verification(true);

pub fn reject_cross_origin(self, reject: bool) -> Self

Reject clientDataJSON that contains crossOrigin: true (§7.1 step 10).

When true, any registration or authentication response from a cross-origin iframe is rejected with crate::error::WebAuthnError::CrossOriginNotAllowed.

Example

use webauthn::RelyingParty;

let rp = RelyingParty::new("example.com", "https://example.com", "My Service")
    .reject_cross_origin(true);

pub fn allowed_algorithms(self, algs: impl IntoIterator<Item = i64>) -> Self

Restrict which COSE algorithms this RP accepts at registration time.

When the list is non-empty, verify_registration rejects any credential whose algorithm is not in this list with crate::error::WebAuthnError::UnsupportedAlgorithm. An empty list (the default) accepts ES256, EdDSA, and RS256.

Example

use webauthn::{RelyingParty, COSE_ES256};

let rp = RelyingParty::new("example.com", "https://example.com", "My Service")
    .allowed_algorithms([COSE_ES256]);

pub fn require_backup_eligible(self, required: bool) -> Self

Require that credentials are backup-eligible (BE flag must be set).

When true, verify_registration and verify_authentication return crate::error::WebAuthnError::BackupEligibilityRequired for any credential whose BE flag is not set.

Example

use webauthn::RelyingParty;

let rp = RelyingParty::new("example.com", "https://example.com", "My Service")
    .require_backup_eligible(true);

pub fn reject_backup_eligible(self, reject: bool) -> Self

Reject credentials that are backup-eligible (BE flag must not be set).

When true, verify_registration and verify_authentication return crate::error::WebAuthnError::BackupEligibleNotAllowed for any credential whose BE flag is set.

Example

use webauthn::RelyingParty;

let rp = RelyingParty::new("example.com", "https://example.com", "My Service")
    .reject_backup_eligible(true);

pub fn trust_anchors(self, roots: impl IntoIterator<Item = Vec<u8>>) -> Self

Provide DER-encoded root CA certificates used to verify the x5c chain.

When a non-empty set is supplied, verify_registration verifies that the root of the attestation certificate chain is signed by one of these anchors and returns crate::credential::AttestationType::BasicVerified on success, or crate::error::WebAuthnError::AttestationRootUntrusted on failure. Chain structure (each cert signed by the next) is always checked regardless of this setting.

Example

use webauthn::RelyingParty;

let fido_root_der: Vec<u8> = std::fs::read("fido-root.der").unwrap();
let rp = RelyingParty::new("example.com", "https://example.com", "My Service")
    .trust_anchors([fido_root_der]);

pub fn enforce_single_use_challenges(self, enforce: bool) -> Self

Opt in to server-side single-use challenge enforcement.

When true, the library maintains an internal set of challenge bytes that have already been processed. After the challenge passes the normal expiry and binding checks, it is looked up in this set:

• If already present → the ceremony fails with crate::error::WebAuthnError::ChallengePreviouslyUsed.
• If absent → it is inserted and the ceremony continues.

A challenge is consumed even if later verification steps (e.g. signature check) fail, so a failed ceremony with a valid challenge cannot be retried with the same challenge bytes.

The tracking set is shared across Cloned instances of this RelyingParty via Arc, so all ceremony paths using copies of the same instance enforce the policy collectively.

When false (the default), single-use enforcement is the caller’s responsibility — track issued challenges in your session store and delete each one after it is presented to a ceremony.

Example

use webauthn::RelyingParty;

let rp = RelyingParty::new("example.com", "https://example.com", "My Service")
    .enforce_single_use_challenges(true);

pub fn verify_registration( &self, challenge: &Challenge, response: &AuthenticatorAttestationResponse, user_id: &[u8], ) -> Result<RegistrationResult>

Verify a registration ceremony response (W3C WebAuthn §7.1).

Call this after the client returns an AuthenticatorAttestationResponse. On Ok, persist result.credential in your database. On Err, reject the registration and return an appropriate error to the client.

Arguments

• challenge — The challenge you issued for this ceremony.
• response — The raw attestation response from the authenticator.
• user_id — Your application’s identifier for this user.

Errors

Returns a WebAuthnError variant indicating exactly which verification step failed.

Trait Implementations

impl Clone for RelyingParty

fn clone(&self) -> RelyingParty

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for RelyingParty

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.