Skip to main content

Wallet Provider and Verifier Provider

Procivis One lets you operate as a Wallet Provider, a Verifier Provider, or both. You deploy a backend, and your wallet or verifier apps communicate with it directly, meeting EUDI and other ecosystems' requirements.

How it fits together​

You deploy a Wallet Provider and/or Verifier Provider backend, and use the Core SDK to build your wallet or verifier apps. As with the rest of Core, two API surfaces are involved:

  • /api endpoints. This is the layer you and your apps actually call. It includes a set of provider-side endpoints for administering your deployment (listing and inspecting instances, revoking or deleting them), and a set of instance-side endpoints for what your apps do (registering, activating).
  • /ssi endpoints. This is the layer Core uses internally to carry out the protocol mechanics behind those actions: the precise, situation-dependent details of attestation and certificate issuance, along with the public-facing side of other interactions, such as putting a credential offer out once you have asked Core to issue one. These calls are more complex and vary by circumstance, which is why /api exists as a simpler interface in front of them. Core makes these calls on your behalf; you and your apps do not call /ssi directly under typical usage.

This split holds across all of Core, not only the Wallet and Verifier Provider components.

note

APIs and SDK methods. Every /api interaction described in this documentation has a corresponding method in the Core SDK. Your app calls the SDK, and the SDK calls /api on your deployment.

App interactions​

The relationship between an app and your provider deployment consists of a small, fixed set of interactions.

Two are deliberate, initiated once per instance:

  1. Register. The app supplies an authentication key and receives an instance ID.

  2. Activate. The app provides platform-specific proof of integrity (and, for verifier instances, a certificate signing request) to complete onboarding.

After activation, attestation requests happen automatically, triggered by real ecosystem interactions rather than anything the app author orchestrates. For a wallet, this means that when a credential issuer requests a WIA or Key Attestation as part of issuing a credential, the wallet requests them from your deployment at that moment. For a verifier, WIA is requested only when the app needs an Access Certificate: once during onboarding, and again on the rare occasions a new certificate is required. It is not used during presentation requests.

One further interaction is optional but recommended: an app can periodically call the /status endpoint to check whether its instance is still active. This is not strictly required. If an instance has been revoked, an attestation request made during issuance will simply fail. A well-built app checks status proactively, so a revoked instance does not surprise a user mid-interaction.

Trust is transitive​

A key pair generated by an instance proves nothing on its own. Nothing in the key itself demonstrates that it is hardware-backed, or that the application holding it is genuine. What establishes an instance as trustworthy to the rest of the ecosystem is a chain of vouching.

From device to provider​

The device operating system provides mechanisms, Secure Enclave on iOS and Android Keystore on Android, that can attest to facts about a key or application. Your deployment, as a known Provider, combines these OS level guarantees with its own knowledge of the app it distributes, and vouches for the instance by issuing attestations. Wallets receive Key Attestation and Instance Attestation (WIA); verifiers receive an Access Certificate. The ecosystem does not inspect the device itself. It trusts your attestation, because it trusts you as the Provider.

For verifier instances​

Before issuing an Access Certificate, your deployment requires a valid WIA from the verifier instance, so you can be confident the certificate is going to a genuine, unmodified application under your control. This check protects your deployment against the misuse of certificates it has issued. It happens once during onboarding, and again on the rare occasions a verifier instance needs a new certificate.

For wallets in a presentation​

When a verifier instance presents its Access Certificate during an interaction, the wallet performs its own usual checks, such as confirming the certificate traces back to a registered wallet-relying party. The wallet has no visibility into the verifier's app attestation, and no need for it. That check belongs entirely to the relationship between your deployment and your own verifier instances.

Lifecycle management​

You can revoke or delete an instance at any time through the management APIs.

  • Revoking a wallet instance denies all future attestation requests. The effect on already-issued attestations depends on whether Token Status List is enabled. See Wallet unit revocation.
  • Revoking a verifier instance immediately revokes its Access Certificate.

Deleting an instance produces the same effect as revocation, and also removes the instance from your deployment entirely.

Next steps​