Passkey Configuration

Trivore ID supports passkeys (WebAuthn/FIDO2 credentials) as an authentication method. Passkeys let users sign in with a device-bound or synced credential — such as a fingerprint, face scan, PIN, or a hardware security key — instead of (or in addition to) a password.

This page explains the settings available under System Preferences → Platform → Base settings → Passkey authentication, and how each one affects the behavior of the passkey system.

note

Trivore ID's passkey support is built on top of the webauthn4j library. If a setting on this page seems unusually specific or low-level, it's likely a direct reflection of a WebAuthn concept exposed by that library. You do not need to understand WebAuthn internals to configure passkeys correctly — the explanations below describe what each option does in practical terms.

Feature under development

The passkey authentication flow (the actual sign-in and registration experience for end users) is still under active development. This document focuses on the configuration options available today, which may evolve as the feature matures.

Enabling passkey authentication

Field: Passkey authentication enabled Options: Disabled / Enabled Default: Disabled

This is the master switch for the feature. When set to Disabled, users cannot register or sign in with passkeys, and the rest of the settings on this page have no effect. Set this to Enabled once you have configured the relying party settings below.

Relying party configuration

In WebAuthn terminology, the relying party (RP) is the service that a passkey is registered for — in this case, your Trivore ID installation. These settings define how your service identifies itself to users' authenticators (phones, security keys, password managers, etc.) and to the browser.

Identifier

Field: Identifier Type: text field

The relying party identifier (RP ID). This is typically your service's domain name (for example, login.example.com or example.com). It determines which domains a passkey created for your service can be used on.

A passkey is only valid for the domain it was registered against — and, depending on how the identifier is set, its subdomains. Changing this value after passkeys have already been registered will invalidate those existing passkeys, so it should be set carefully before rolling the feature out and left unchanged afterward.

Name

Field: Name Type: text field

A human-friendly name for your service, for example Example Service. This name may be shown to users by their browser or authenticator (such as a password manager) when they are registering or using a passkey, to help them recognize which service the credential belongs to. It has no effect on security or validation — it's purely for display purposes.

Origins

Field: Origins Type: multi-line text field (one origin per line)

The list of web origins (scheme + domain + port, e.g. https://login.example.com) that are allowed to complete passkey registration and authentication. This acts as an allow-list: requests coming from an origin not on this list will be rejected, even if the RP identifier matches.

If left empty, Trivore ID defaults to a single origin of the form https://<identifier>, using the value configured in Identifier above. In most single-domain setups, leaving this field empty is sufficient. You only need to list origins explicitly if you serve sign-in pages from multiple origins (for example, a marketing domain and a separate app domain that share the same relying party identifier).

Allow any origin port

Field: Allow any origin port Options: Allowed / Not allowed Default: Not allowed

Controls whether the port number is enforced when validating the origin of a passkey request.

• Not allowed (default): the origin's port must match exactly what's expected (or the standard port for the scheme). This is the stricter, recommended setting for production use.
• Allowed: requests are accepted regardless of which port they come from, as long as the rest of the origin matches. This can be useful in development or testing environments where the application may run on a non-standard or changing port.

Allow any origin subdomain

Field: Allow any origin subdomain Options: Allowed / Not allowed Default: Not allowed

Controls whether requests from subdomains of a configured origin are accepted.

• Not allowed (default): the origin must match one of the configured Origins exactly.
• Allowed: any subdomain of a configured origin is also accepted. For example, if https://example.com is configured as an origin, enabling this would also accept requests from https://app.example.com.

Only enable this if you genuinely need passkeys to work across multiple subdomains, as it broadens the set of origins that can complete authentication.

Allow untrusted attestation

Field: Allow untrusted attestation Options: Allowed / Not allowed Default: Allowed

During registration, an authenticator can optionally provide an attestation — a statement, signed by the device manufacturer, that vouches for the type and authenticity of the authenticator. Verifying this signature requires trusting a certificate chain back to the manufacturer.

• Allowed (default): passkey registration is accepted even if the attestation cannot be verified against a trusted certificate chain (which is the case for most consumer devices and password managers, such as phones and browser-based passkey managers). This is the recommended setting for general-purpose passkey support.
• Not allowed: registration will be rejected unless the attestation can be cryptographically verified against a trusted source. This is a stricter setting typically only relevant if you need to guarantee that only specific, vetted hardware authenticators can be registered.

For most deployments, especially those supporting everyday consumer devices, this should be left as Allowed.

Validate signature counter

Field: Validate signature counter Options: Validate / Don't validate Default: Validate

Many authenticators maintain a counter that increments each time the passkey is used, as a way to help detect cloned credentials (if the counter ever goes backward or fails to increase, it can indicate the credential was duplicated).

• Validate (default): Trivore ID checks the signature counter on each authentication and rejects requests where the counter doesn't behave as expected.
• Don't validate: the counter is ignored.

Note that many modern passkey implementations — particularly synced passkeys stored in a cloud-based password manager — do not meaningfully increment this counter, since the same credential can be used from multiple devices. Disabling this check can avoid false rejections in those cases, but it also removes one signal that could otherwise help detect a cloned authenticator.

Authenticator selection

These settings apply during registration — that is, when a user is creating a new passkey — and tell the browser or authenticator what kind of credential to create.

Authenticator attachment

Field: Authenticator attachment Options: (empty) / Platform / Cross-platform Default: (empty) — both types allowed

Controls what kind of authenticator the user is prompted to use when registering a passkey:

• (empty) (default): no restriction — the user can choose either a platform or a cross-platform authenticator.
• Platform: the passkey must be created using an authenticator built into the user's device, such as Windows Hello, Apple Touch ID/Face ID, or an Android device's built-in biometrics.
• Cross-platform: the passkey must be created using a portable/external authenticator, such as a USB or NFC security key (e.g. a YubiKey), or a passkey synced from another device.

Leave this empty unless you have a specific reason to restrict which type of authenticator your users can register.

Resident key requirement

Field: Resident key requirement Options: (empty) / Required / Preferred / Discouraged Default: Required

A "resident key" (also called a "discoverable credential") is a passkey that is stored on the authenticator itself in a way that lets it be found without the service first having to supply a username or credential ID. In practice, this is what enables passwordless, "usernameless" sign-in flows where the user simply picks their passkey from a list.

• Required (default): the authenticator must create a discoverable/resident credential. This is necessary if you want to support sign-in without the user typing a username first.
• Preferred: a discoverable credential is requested but not mandatory; the authenticator will use one if it supports it.
• Discouraged: the authenticator is asked to avoid creating a discoverable credential, which may save storage space on the authenticator when this capability isn't needed.
• (empty): no preference is sent; the authenticator's own default behavior applies.

User verification requirement (Authenticator selection)

Field: User verification requirement Options: (empty) / Required / Preferred / Discouraged Default: Required

"User verification" refers to the authenticator confirming that the person present is actually the owner of the passkey — for example, via a fingerprint, face scan, or device PIN — as opposed to merely proving that some physical authenticator was present (user presence, e.g. a simple button tap).

• Required (default): the authenticator must perform user verification during registration, or the registration will fail. This ensures every registered passkey is backed by a verified user, which is important if the passkey may later be used as a strong, standalone sign-in method.
• Preferred: user verification is requested if the authenticator supports it, but registration will still succeed if it doesn't.
• Discouraged: the authenticator is asked to skip user verification where possible (typically to speed up or simplify the registration, e.g. with security keys that don't have a PIN configured).
• (empty): no preference is sent.

Assertion

These settings apply during authentication (also called "assertion" in WebAuthn terminology) — that is, when an existing passkey is used to sign in.

User verification requirement (Assertion)

Field: User verification requirement Options: (empty) / Required / Preferred / Discouraged Default: Preferred

Same concept as the registration-time setting above, but applied when a user signs in with an existing passkey:

• Required: the authenticator must perform user verification (e.g. biometric or PIN check) for the sign-in to succeed.
• Preferred (default): user verification is requested if supported, but sign-in can still succeed without it.
• Discouraged: user verification is not requested.
• (empty): no preference is sent.

Since the default at registration time is Required, most registered passkeys will already be capable of user verification — so setting this to Preferred or Required at sign-in time will generally have the same practical effect for those credentials.

Timeout

Field: Timeout Type: duration, specified in minutes or seconds

The maximum amount of time the user has to complete the passkey sign-in ceremony (for example, to unlock their device and confirm their passkey) before the request expires. If the user doesn't respond within this window, the authentication attempt fails and the user must retry.

Choose a value long enough for users to comfortably locate and use their authenticator, while still expiring stale requests in a reasonable time.

Hints

Field: Hints Type: text area

Optional hint values passed to the user's browser to influence how it presents authenticator options during sign-in — for example, suggesting that the browser prioritize showing security keys or a QR-code flow for a phone-based passkey. Hints are advisory: the browser is free to ignore them, and they do not affect which credentials are actually accepted.

Leave this empty unless you have a specific UX reason to nudge the browser's authenticator selection UI.

Summary of defaults

Setting	Default
Passkey authentication enabled	Disabled
Origins (if left empty)	https://<identifier>
Allow any origin port	Not allowed
Allow any origin subdomain	Not allowed
Allow untrusted attestation	Allowed
Validate signature counter	Validate
Authenticator attachment	(empty — both allowed)
Resident key requirement	Required
User verification requirement (registration)	Required
User verification requirement (assertion)	Preferred

Recommended starting point

For most deployments, the default values are a reasonable starting point: they favor broad device compatibility (allowing untrusted attestation, no attachment restriction) while still requiring verified, discoverable credentials at registration. Adjust individual settings only if you have a specific security or compatibility requirement that calls for it.