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 | |
Name | Relying party name | Veridium |
Icon URL | Relying party icon URL | |
Origins | Relying party origins URL | |
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. | Preferred |
Attestation conveyance preference | None indicates that the RP is not interested in authenticator attestation. | 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. | Preferred |
Client Extensions |
After configuring all fields, click Save button and the new relying party will be added.