|
Registration Policy
|
Relying Party Application
|
Lists all the integrated relying parties.
|
|
Relying Party Entity Name
|
A unique name to identify the relying party entity.
|
|
Relying Party ID
|
A unique registrable domain URL or the domain suffix of the relying
party's domain, for example, utopia.net or utopiatenant.utopia.com.
Note: For Entra ID, this field is not available. For Unifyia and Okta, this field is not visible in the edit mode.
|
|
Signature Algorithms
|
Required signature algorithms to use for the Public Key Credential.
|
|
Attestation Conveyance Preference
|
It defines how and whether the attestation information provided by the authenticator
(such as a security key or biometric device) should be conveyed to the relying party
(the service or application requesting the registration). Attestation provides
evidence that a particular authenticator is genuine and that its cryptographic keys
are securely stored. From the below-listed options, you can select the preferred method
to
generate attestation statements when communicating with the authenticator device.
- Not specified: No specific preference or requirement.
- None: This value indicates that the Relying Party is not
interested in authenticator attestation. Hence, no attestation information is
conveyed to
the relying party.
- Indirect: Attestation information is conveyed in a way that
does not directly identify the specific authenticator model to the relying
party. This is
typically done through anonymized or aggregated data provided by an intermediary
(such as an attestation CA).
- Direct: Full attestation information is conveyed directly to
the relying party, including the attestation certificate, which identifies the
specific model and possibly the batch of the authenticator.
- Enterprise: This value indicates that the Relying Party wants
to receive an attestation statement that may include uniquely identifying
information. This is intended for controlled deployments within an enterprise
where the
organization wishes to tie registrations to specific authenticators.
|
|
Authenticator Attachment
|
Authenticator Attachment refers to the way an authenticator (e.g., a security key or
a built-in biometric sensor) is integrated or connected to the device (e.g., a
computer or smartphone) used for authentication. Possible values are:
- Not specified: No specific preference or requirement,
- Platform: Select this option if you want to support an
authenticator built into the device (built-in authenticators), such as a
fingerprint sensor or facial recognition camera in a smartphone or laptop for
authentication.
- Cross-Platform: Select this option if you want to support an
authenticator that is an external device and that
connects to the host device through various means such as USB (Yubikey), NFC
(security keys), or Bluetooth (smartphones).
|
| Credential Blob |
The credential Blob contains information about a
user, securely managed by the authenticator, to ensure proper authentication. This
extension allows a small, fixed amount of data to be stored with a credential.
Select which user detail must be stored in the credential blob from the below-listed
options.
- Not specified: No specific preference or requirement.
- First Name: The name of the user.
- User Name: The unique username.
- Organization: The organization name to which the user belongs.
|
|
Large Blob
|
This extension enables the Relying Party and authenticator to store opaque data
associated with a credential in compressed form on the authenticator after
successful assertion. Possible values are:
- Not specified: No specific preference or requirement.
- Preferred: This option suggests that the system prefers or
recommends the use of large blobs but doesn’t strictly require them.
- Required: This option indicates that large blobs are mandatory
for the authentication process to proceed.
|
|
Passkey - Discoverable Credential
|
It refers to a setting related to how the platform interacts with the user's
authenticator device (like a security key or smartphone). Select this option if the
Relying Party does not need to first identify the user during authentication as this
option ensures that the user details are discovered from the device. Available options
are:
- Not specified: No specific preference or requirement.
- Preferred: The relying party prefers that discoverable
credentials be used, but it is not mandatory.
- Discouraged: The relying party discourages the use of
discoverable credentials.
- Required: The relying party mandates the use of discoverable
credentials for authentication.
|
|
User Verification Requirement
|
It refers to specifying whether an authenticator device (like a security key or
smartphone) should perform additional user verification steps beyond the initial
presence test (typically involving possession of the device). Possible values are:
- Not specified: No specific preference or requirement regarding
user verification beyond the initial presence test.
- Preferred: The relying party prefers that the authenticator
device performs additional user verification steps when possible, but it is not
mandatory.
- Discouraged: The relying party discourages the use of
additional user verification steps beyond the initial presence test.
- Required: The relying party mandates the authenticator device
to perform additional user verification steps beyond the initial presence test.c
|
|
Credential Protect
|
This extension allows relying parties to specify a credential protection policy when
creating a credential. Available options are:
- Not specified: No specific preference or requirement.
- User verification is optional: It means that user verification
during credential creation is optional.
- User verification is optional with credential ID list: It means
that user verification during credential creation is optional, but it requires
the
use of a credential ID list.
- User verification is required: Mandates that user verification
through additional steps beyond the initial presence test must be performed
during credential creation.
|
|
PIN Length
|
Choose a PIN length for the authentication. Possible lengths are 4, 6, and 8.
|
|
Type of PIN
|
PINs can be numeric or alphanumeric.
- FIDO2.0 - For devices supporting FIDO2.0 specification,
PINs can contain numeric characters.
- FIDO2.1 - For devices supporting FIDO2.1 specification, PINs
can contain alphanumeric characters.
|
|
Timeout
|
The timeout value, in seconds/minutes, for registering an authenticator and
authenticating the user by using the registered authenticator.
|
|
Minimum PIN Length
|
Enable this option to ensure a check if the current minimum PIN length value
configured on an authenticator meets the set PIN length in this policy
configuration. If the PIN Length does not match, the authentication will fail.
|
|
Enable Revocation Check
|
|
Enable this option to allow the relying party to verify the attestation certificate
to confirm if it is active or revoked.
|
|
Authentication Policy
|
Authenticator Verification Preference
|
During the registration process of a new FIDO credential (like a security key or
device), the relying party checks if the credential being registered is present on
the trusted list.
- Not Specified: No specific preference or requirement.
- FIDO Alliance Metadata Service: The FIDO Alliance Metadata
Service (MDS) provides a centralized repository of metadata related to certified
authenticators. This includes information about authenticator capabilities,
security features, and attestation types. Using the MDS allows relying parties
(services or websites) to verify and trust authenticators based on standardized
metadata.
- Custom Metadata Statement: This option suggests using a custom
metadata statement for verifying authenticators. It allows relying parties to
define their own set of metadata criteria or specifications for authenticator
verification, which may be tailored to specific organizational needs or security
requirements.
- Enterprise Attestation: Enterprise attestation involves using a
specific attestation method where the authenticity and security properties of
the authenticator are verified within an enterprise environment. This method may
leverage enterprise-specific policies, trust anchors, or attestations to ensure
the authenticity and trustworthiness of the authenticators used.
- HMAC Secret: An HMAC Secret refers to a cryptographic key used
for HMAC (Hash-based Message Authentication Code) operations. Enable this
option if you require the HMAC secret to be used to bind a registered
authenticator to the platform to ensure that authentication assertions coming
from the
authenticator during subsequent authentication attempts are verified for
integrity and
authenticated by the platform.
|
|
User Verification:
|
Select this option, if the authenticator needs to use additional confirmation for the
verification of a user. Select an option from
the below:
- Not specified: No specific preference or requirement regarding
user
verification beyond the initial presence test.
- Preferred: The relying party prefers that the authenticator
device performs additional user verification steps when possible, but it is not
mandatory.
- Discouraged: The relying party discourages the use of
additional
user verification steps beyond the initial presence test.
- Required: The relying party mandates the authenticator device
to
perform additional user verification steps beyond the initial presence test.
NOTE: If the User Verification Requirement
in the
registration section has been set to a value say for example
Preferred, it is mandatory to use the same value here, i.e. the
value Preferred must be selected.
|
|
Get Cred Blob
|
Select this option if retrieving or obtaining a credential blob (a small, fixed
amount of data stored in the authenticator) associated with the user's FIDO2
credential is required. The credential blob contains information necessary for the
authentication process, such as cryptographic keys or other identifiers specific to
the user's registered credential.
- Not specified: No specific preference or requirement.
- False: Do not retrieve data for authentication.
- True: Retrieve data for authentication.
NOTE: If the Get Credential Blob in the
registration section has been set to a value other than Not
specified, then it is mandatory to set the value as
True.
|
|
Get Large Blob
|
Select this option if retrieving or obtaining a credential blob (a small, fixed
amount of data stored in the authenticator) associated with the user's FIDO2
credential is required. The credential blob contains information necessary for the
authentication process, such as cryptographic keys or other identifiers specific to
the user's registered credential.
- Not specified: No
specific preference or requirement
- False: Do not
retrieve data for authentication.
- True: Retrieve
data for authentication.
NOTE: If the Large Blob in the
registration section has been set as Preferred,
then it is mandatory to set the value as True.
|
|
Write Large Blob
|
This extension allows the Relying Party to store opaque compressed data on the
authenticator by associating it with a credential after successful assertion. This
action involves writing or sending a large data structure or payload as part of the
authentication process. It could be used, for example, when the relying party needs
to transmit extended information to the authenticator during authentication, beyond
what is typically exchanged in a standard authentication request. Possible values are:
- Not specified: No specific preference or requirement.
- Certificate: A certificate is required.
|
|
Allow Credentials
|
Enable this setting to share the registered authenticator details with the browser
during user authentication.
|