Overview
For high‑risk transactions, services can require a Verifiable Credential that proves a specific entitlement or clearance before allowing a sensitive action.
Why it matters
Traditional step‑up flows rely on one‑off integrations and manual checks. Verifiable Credentials make step‑up assurance portable across services while preserving privacy.
Ecosystem roles
- Issuer: The authority granting clearance or entitlement.
- Holder: The user or staff member.
- Verifier: The service enforcing step‑up access.
Assurance and access
Only the minimum attributes needed for the action are disclosed. Status checks ensure the entitlement remains valid.
| Objective | Require stronger proof before high‑risk actions. |
| Description | Verify a clearance or entitlement Verifiable Credential before approving sensitive access. |
| Actors | Issuing authority; User; Service owner |
| Dependencies | Issuer trust registry and status endpoint. |
| Preconditions | User holds a valid entitlement credential. |
| Postconditions | Sensitive action is allowed or denied based on Verifiable Credential proof. |
flowchart LR
AUTH@{icon: "fa:shield", label: "Authority", pos: "b"} -->|Issues entitlement VC| WAL@{icon: "fa:wallet", label: "Wallet", pos: "b"}
WAL -->|Present VC| VER@{icon: "fa:lock", label: "High-risk service", pos: "b"}
VER -->|Check status| REG@{icon: "fa:book", label: "Registry/status", pos: "b"}
VER -->|Allow or deny| ACT@{icon: "fa:bolt", label: "Sensitive action", pos: "b"}
sequenceDiagram
participant Authority
participant Wallet
participant User
participant Service as High-risk service
participant Registry as Registry/status
Authority-->>Wallet: Issue entitlement VC
User->>Service: Request sensitive action
Service->>Wallet: Request proof
Wallet-->>Service: Present VC proof
Service->>Registry: Validate issuer and status
Registry-->>Service: Valid
Service-->>User: Action approved