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.

Instance Attestation​

Verifier instances do not use WIA. WIA is sent to a credential issuer, and verifiers never issue credentials. Instead, a verifier instance provides an attestation directly to your provider backend, proving the app is genuine and unmodified.

This attestation is used only between the verifier instance and your backend; the wallet a verifier interacts with has no visibility into it.

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

App integrity verification​

The system verifies app integrity 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, no Access Certificate is issued.

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.

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.