Security & Governance
Every data breach starts with an implicit trust assumption that shouldn't have been there, a service that wasn't authorized, an API call that wasn't logged, a permission change that nobody reviewed. VDX eliminates implicit trust from your identity infrastructure. Every command is policy-checked before execution. Every action is recorded in a tamper-evident audit trail. Every decision is traceable across services, tenants, and time.
This isn't a security layer bolted onto the platform. It's how the platform works. The same governance model applies whether you're issuing a credential, verifying a presentation, signing a document, or returning a query result. Nothing executes without authorization, nothing happens without a record.
Policy-Driven Authorization
Before any command executes, issuing a credential, reading an identity, signing a document, querying a record, it passes through the policy enforcement layer. The decision is made by an external policy engine, not by application code.
Three policy engines are supported. Cedar (AWS) provides formally verifiable policies that can be mathematically proven correct, you can ask "is there any scenario where an unauthorized user can access this resource?" and get a definitive answer. Open Policy Agent uses the industry-standard Rego language, widely adopted in cloud-native environments. Any AuthZEN-compliant PDP works out of the box.
What makes this different from role-based access control scattered through code:
- Policies are data, not code. Update who can do what without redeployment. Different tenants can have entirely different policy sets.
- Dual-principal evaluation. Both the end user AND the calling service are authorized on every request. A compromised service can't escalate its own privileges.
- Step-up authentication. Policies can require higher assurance for sensitive operations, viewing a record needs
low, but exporting it needshigh. The platform challenges the user automatically. - Fail-closed by default. If the policy engine is unreachable, everything is denied. No security degradation under failure.
- Progressive rollout. Log-only mode lets you see what would be denied before enforcing, validate policies against production traffic without breaking anything.
Immutable Audit Trail
Every operation produces an audit record. Not just "user X did Y", the full context: who, what, when, why it was allowed (or denied), how long it took, which service handled it, and the distributed trace ID linking it to every other operation in the request chain.
The audit pipeline automatically enriches events with tenant and actor context from the session, redacts sensitive data (passwords, tokens, API keys are stripped before persistence), and writes to an append-only store where records cannot be modified or deleted, not even by administrators.
Tamper evidence goes further: every audit event is hash-chained to the previous one. Modifying any event breaks the chain. Periodic signed checkpoints provide independent verification points. An auditor can prove that no records were altered between any two points in time.
What Gets Recorded
| Event type | What it captures |
|---|---|
| Command execution | Every business operation, credential issuance, identity verification, document signing, data queries |
| Authorization decisions | PERMIT and DENY with policy engine reasons, including which rules matched |
| Authentication events | Wallet presentations, OIDC logins, step-up challenges, session lifecycle |
| Data access | Who read what, from which service, at what assurance level |
| Configuration changes | Policy updates, tenant settings, credential schema modifications |
| Security events | Failed authentication attempts, suspicious patterns, credential revocations |
SIEM Integration
Audit records export to your existing security infrastructure in three formats:
- JSON: for Elasticsearch, Splunk, Datadog, Loki, and modern log platforms
- CEF (Common Event Format), for ArcSight, QRadar, and legacy SIEM systems
- OCSF (Open Cybersecurity Schema Framework), the emerging standard for security telemetry
Export is asynchronous, it never blocks command execution. Failed exports retry with exponential backoff and dead-letter queuing so nothing is silently lost.
End-to-End Tracing
A single user action, presenting a credential, signing a document, verifying an identity, might flow through multiple microservices. Without tracing, investigating an incident means correlating logs from different services by timestamp and hoping.
VDX uses OpenTelemetry with W3C Trace Context propagation. A single trace ID follows the request from the API gateway through every service that participates. Spans within the trace show where time was spent. The trace ID appears in every audit record, every log line, and every SIEM export, so investigating an incident starts with one ID and reveals the complete picture.
Cross-Domain Security Signals
When a credential is compromised, a session is revoked, or an account is disabled, every system that trusts that identity needs to know, immediately, not hours later.
VDX implements the OpenID Shared Signals Framework (SSF) for real-time security event exchange. CAEP events handle session revocation and token claim changes. RISC events handle account compromise, disablement, and purge. All signals are transmitted as signed Security Event Tokens (SETs) with replay protection.
This means VDX doesn't operate in isolation. When an upstream identity provider detects a compromise, the signal propagates to VDX, which revokes sessions, invalidates cached decisions, and notifies downstream systems, all within seconds.
Data Protection
Identity data is encrypted at rest with per-identity keys. The organization can access data through its KMS-wrapped grant. The wallet holder can access it through their public key. Optional knowledge-based grants add passphrase protection.
No plaintext identifiers in the database. External identifiers (wallet keys, email addresses, institutional IDs) are stored as HMAC hashes. Canonical attributes are encrypted with AES-256-GCM. Even with full database access, an attacker sees only ciphertext and hashes.
GDPR by architecture:
- Crypto-shredding: destroying one key makes all data for an identity irrecoverable. No data migration, no record-by-record deletion. O(1) erasure.
- Selective disclosure: holders choose which claims to reveal per presentation. The verifier never sees more than what's needed.
- Consent-as-grants: access grants carry purpose, validity period, and revocation. Revoking consent = revoking the grant = immediate access termination.
- Data portability: export command bundles all data for an identity in a portable format.
Attribute Sources as Parties
External systems that feed attributes into the platform, a database, an IAM, a REST API, a static dataset, are not configuration entries. Each registered attribute source is a party: an executable system is a software party, a non-executing dataset is an asset party, and the source carries an ATTRIBUTE_SOURCE capability on that party. The managed-versus-external distinction rides on the party itself (its origin and, for a server, its management mode), the same pattern the platform uses for an external OID4VCI issuer.
Registration creates the full identity picture in one step. The source party receives an identity it owns, and the source's endpoint URL is stored on that identity as a protected correlation identifier under the tenant's protection policy for URLs, so connection endpoints follow the same at-rest protection rules as personal identifiers. Connector secrets are never identifiers and never stored inline; they live in the selected secret backend and the source references them through its software credential's secret reference.
Because sources are parties, they are visible where parties are visible: the polymorphic party API returns them as typed Software and Asset shapes alongside persons and organizations, so a tenant's inventory of participants includes the systems its data comes from.
That visibility makes governance derivable rather than hand-maintained. Governance derivation reads each source's operator and runtime mode from its server-party record and produces complete processor-map entries: a third-party-operated source appears as a processor under its operator, the systems it depends on appear as sub-processors behind that operator, and the result feeds the processor map, transfer facts, and register reporting without a separately maintained inventory. When attribute values flow out of identifiers at issuance time, the attribute pipeline's identity source emits identifier claims protection-aware: reversible values are revealed, and blinded lookup values are never emitted as claims.
Governance at Every Layer
The same governance model applies across all platform operations:
| Layer | How governance applies |
|---|---|
| Credential issuance | Policy check before issuing. Audit record of what was issued, to whom, by which authority. |
| Credential verification | Policy check on what to accept. Audit record of what was verified, from whom, with what assurance. |
| Identity matching | HMAC-hashed links, no plaintext. Audit record of matching decisions and IDV outcomes. |
| Data access | Policy check on every read/write. Encryption at rest. LoA-gated decryption grants. |
| Configuration changes | Policy check on who can modify settings. Audit record of every change with before/after values. |
| Service-to-service | mTLS and workload identity. Dual-principal authorization. No shared secrets. |
The result is a platform where every business decision, from "should we issue this credential?" to "should this service access this record?", goes through the same policy-audit-trace pipeline. No exceptions, no bypasses, no implicit trust.