View Zero Trust Service Catalogue 1 Match IdentityVerifiable Credentials
Zero Trust Service Catalogue
UNIFY's identity-first catalogue spanning the core Zero Trust pillars.
Capabilities that establish, migrate, and assure digital identities.
- Trusted Sign-in
- Streamlined Identity Lifecycle
- Verifiable Credentials
- Identity Protection
- Migration to Entra
- Identity Verification and Proofing
- Application Provisioning
- Identity SOC
Controls that govern how users, customers, and partners gain the right access.
- Secure External Access
- Organisational Identity Access Management
- Controlled Delegation
- Partner Identity Access Management
- Just-In-Time Privilege
- Adaptive Access
- Multifactor Identification
- Risk-Based Authentication
Oversight capabilities that enforce policy, compliance, and least privilege.
- Enterprise Governance
- Controlled Delegation
- Access Lifecycle
- Entitlement Management
- Data Protected
- Access Reviews
- Just-In-Time Privilege
- Adaptive Access
Security operations services that protect, detect, and respond across identities.
- Intelligent Threat Detection
- Dark Web & Supply Chain Insight
- Information Protection and Governance
- Endpoint & Cloud Protection
- Vulnerability Management
- Security Operations Centre as a Service (SOCaaS)
- Risk Management
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. VCs 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 VC 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 VC 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