Skip to main content
Skip table of contents

Add a new Relaying party

In order to add a new Relying Party, click Add Relying Party button.

The default values for a new relying party are:

Name

Basic Description

Default Value

ID

Relying party identifier

veridium-dev.com

Name

Relying party name

Veridium

Icon URL

Relying party icon URL

Origins

Relying party origins URL

https://dev1.veridium-dev.com

Allowed Origins

Relying party allowed origins URLs

App ID

The AppID is a URL carried as part of the protocol message sent by the server and indicates the target for this credential. By default, the audience of the credential is restricted to the Same Origin of the AppID.

VeridiumID

FIDO registration URL

https://shib.dev1.veridium-dev.com/idp/profile/SAML2/Unsolicited/SSO

FIDO registration ID parameter

FIDO registration identifier

providerId

Public Key Credential Type

Public key

COSE Algorithms

CBOR Object Signing and Encryption (COSE) algorithm identifiers

RS256, RS512, ES256, ES512, PS256, PS512

Allow unknown extensions

Extensions can be defined in a way such that a processing entity which doesn't understand the meaning of a specific extension must abort processing, or they can be specified in a way that unknown extension can (safely) be ignored.

Switched on

Allow missing attestation

The attestation is specific to a device model and can be used to cryptographically prove that a user has a specific model of device when they register.

Switched on

Signature counter validation

Authenticators send a monotonically increasing signature counter that a Relying Party can check to possibly detect cloned authenticators.

Switched on

Authenticator transport

Requests and responses are conveyed to roaming authenticators over specific transports (e.g., USB, NFC, Bluetooth). For each transport technology, message bindings are specified for this protocol.

BLE, INTERNAL, NFC, USB

Authentication attachment type

This enumeration’s values describe authenticators' attachment modalities. Relying Parties use this to express a preferred authenticator attachment modality when creating a credential.

Unspecified

User verification requirement

Preferred indicates that the RP prefers user verification for the operation if possible, but will not fail the operation if the response does not have the authenticator data flags set.
Required indicates that the RP requires user verification for the operation and will fail the operation if the response does not have the authenticator data flags set.
Discouraged indicates that the RP does not want user verification employed during the operation.

Preferred

Attestation conveyance preference

None indicates that the RP is not interested in authenticator attestation.
Indirect indicates that the RP prefers an attestation conveyance yielding verifiable attestation statements, but allows the client to decide how to obtain such attestation statements.
Direct indicates that the Relying Party wants to receive the attestation statement as generated by the authenticator.

Indirect

Resident key required

Client-side discoverable credentials (formerly known as resident credentials or resident keys)

Switched on

Resident key requirement

Preferred indicates the Relying Party strongly prefers creating a client-side discoverable credential, but will accept a server-side credential.
Required indicates the Relying Party requires a client-side discoverable credential, and is prepared to receive an error if a client-side discoverable credential cannot be created.
Discouraged indicates the Relying Party prefers creating a server-side credential, but will accept a client-side discoverable credential.

Preferred

Client Extensions

After configuring all fields, click Save button and the new relying party will be added.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.