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.