Skip to main content

Verifier Provisioning Flows

This page walks through the mechanics of verifier provisioning: the concrete sequence, endpoints, and payload fields behind registration, activation, and certificate issuance. For the concepts behind this component, and why these steps exist, see Wallet Provider and Verifier Provider. For configuration instructions, see Configure Verifier Provider.

Workflow overview​

Understanding the basic verifier providing workflows helps you integrate they system correctly. The following diagrams show the key processes verifiers follow when interacting with a verifier provider.

Verifier registration and activation​

Verifiers register during onboarding to establish their identity with the verifier provider:

During registration, the verifier supplies an authentication key that becomes bound to the verifier instance. The verifier provider returns a verifier instance ID that the verifier uses for all subsequent provider interactions. If app integrity verification is enabled, the verifier must also activate immediately after registration, providing platform-specific attestations along with a certificate signing request (verifierAccessCertificateCsr) and a user access token. Activation both confirms app integrity and issues the verifier's Access Certificate in a single step.

Access Certificate​

Your deployment issues a verifier instance's Access Certificate during activation, using the certificate signing request (verifierAccessCertificateCsr) supplied in that call, combined with your configured signature provider and Access Certificate configuration. The certificate is returned as accessCertificate in the activation response.

Instance Attestation (WIA)​

WIA is used only between a verifier instance and your provider backend. It has no role in a presentation request; the wallet a verifier interacts with has no visibility into it.

A verifier instance provides a WIA during activation, before your deployment issues its Access Certificate, and again on the occasions a new certificate is required. Like wallet WIA, it is short-lived and single-use, with a configurable expiration time.

There is no verifier equivalent to Attestation during credential issuance in the wallet flow: a verifier instance never requests attestations mid-interaction.

App integrity verification​

The system can optionally verify app integrity before issuing attestations using platform-specific mechanisms:

  • iOS: App Attest validates that the app was distributed through the Apple App store and matches expected bundle identifiers.
  • Android: Key attestation validates app integrity and the use of a genuine Android device.

When integrity verification is enabled, the system validates certificate chains against trusted platform certificate authorities and confirms app bundle identifiers match configured values. If integrity verification is disabled, attestations are issued without these platform-specific checks.

Revocation​

Revoking a verifier instance immediately revokes its Access Certificate, through the same management APIs used for wallet instances. Deleting an instance has the same effect and also removes the instance from your deployment.

User authentication​

When the userAuthentication block is present in the verifier provider configuration, the verifier onboarding flow includes an authentication step with the configured identity provider. If required is set to true, users must complete authentication to activate their wallet unit. If false, authentication is optional.

During onboarding, the verifier instance registration generates a nonce which the verifier passes back as part of activation alongside a JWT from the identity provider. The token is validated against the verifier provider configuration, the nonce is verified, and the user's sub is extracted and stored against the verifier unit.

Once verifier users have a stored sub, you can use the Notification Service to send them templated, translation-ready emails. See Notification Service.