Step-up access for sensitive actions

Overview

For high-risk transactions, services can require a Verifiable Credential that proves a specific entitlement, clearance, or role before allowing a sensitive action.

The service can move beyond generic authentication strength and ask for proof that the user is entitled to perform the specific action.

Why it matters

Traditional step-up flows rely on one-off integrations, manual checks, or broad group membership. Those signals may prove that a person can sign in, but not that they are currently authorized for a sensitive decision.

Verifiable Credentials create a cleaner model:

• an authority issues entitlement or clearance credentials
• the user presents the credential only when a high-risk action requires it
• the service verifies issuer trust, status, and scope
• the action is approved only when the presented proof satisfies policy

Ecosystem roles

• Issuer: The authority granting clearance, role, delegation, or entitlement.
• Holder: The user, staff member, or representative storing the credential in a wallet.
• Verifier: The service enforcing step-up access before a sensitive action.
• Trust governance: The rules that define accepted issuers, credential scopes, action policies, status checks, and expiry.

Trust decision

The verifier decision is narrow: can this user perform this sensitive action right now?

That decision may depend on the action, entitlement scope, issuer trust, credential status, expiry, risk score, and any additional authentication step.

Privacy and assurance

Only the minimum attributes needed for the action should be disclosed. A service may need proof of a clearance level or delegated authority, not the full basis on which that authority was granted.

Assurance depends on checking issuer trust, credential status, proof binding, and whether the presented entitlement satisfies the action policy.

Implementation notes

• Map sensitive actions to required credential types and assurance levels.
• Keep credential verification separate from, but coordinated with, authentication and session risk controls.
• Define retry, fallback, and manual approval paths for missing or expired credentials.
• Record the decision and policy basis for audit without over-collecting credential data.

Objective

Require stronger proof before high-risk actions.

Description

Verify a clearance or entitlement credential before approving sensitive access.

Actors

Issuing authority; user or staff member; service owner; access verifier.

Dependencies

Issuer trust registry, entitlement credential schema, action policy, and status endpoint.

Preconditions

The user holds a valid entitlement credential and requests a sensitive action.

Postconditions

The action is allowed, denied, or escalated based on verified entitlement proof and service policy.

flowchart LR
    AUTH@{icon: "tabler:shield", label: "Authority", pos: "b"} -->|Issues entitlement VC| WAL@{icon: "tabler:wallet", label: "Wallet", pos: "b"}
    WAL -->|Present VC| VER@{icon: "tabler:lock", label: "High-risk service", pos: "b"}
    VER -->|Check status| REG@{icon: "tabler:book", label: "Registry/status", pos: "b"}
    VER -->|Allow or deny| ACT@{icon: "tabler: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