Overview

The Holder Policy service offers a powerful mechanism to enforce rules and logic before a credential is received or presented from a wallet. This allows for fine-grained control, ensuring that data sharing meets specific organizational or security requirements when using the silent verification or issuance flows. You can learn more about it here.

Policies are evaluated in a prioritized sequence, and their outcome can either allow or block the presentation or issuance flow. This guide details the complete workflow, from setting up the necessary services to defining and enforcing policies during a specific flow.

Core Concepts

Policy Store: A dedicated service (policy-store) that manages the lifecycle of your holder policies. It must be created and then explicitly attached to a wallet service as a dependency.

Holder Policy: A rule composed of three key parts:

  • Priority: A number that dictates the order of execution (a lower number means higher priority).
  • Check: The condition to evaluate. This can be a simple check (e.g., BasicHolderPolicyCheck for the presence of a claim) or a complex one (e.g., DcqlHolderPolicyCheck using a Decentralized Credential Query Language query).
  • Action: The result if the check is true. This can be ALLOW or BLOCK.

Policy Evaluation: When a flow is initiated with policies enabled, the wallet queries its attached Policy Store. It evaluates policies in order of priority (lowest number first). The first policy that matches its check condition will have its action (ALLOW or BLOCK) executed, and the evaluation process stops.

Getting Started

Last updated on July 21, 2025
Hashicorp VaultSetup