Proof of Concept Open Source MIT License

Secure Identity and Access Control for Coalition Networks

DIVE V3 shows how separate groups can share user identity and enforce strict access rules. Each group keeps control of its own data. Users sign in once and can reach shared resources.

Request Access View Live Status
Zero Trust Architecture Multi-National Federation Policy as Code Full Audit Trail
What Is DIVE V3

DIVE V3 stands for Digital Interoperability Verification Experiment, Version 3. It is an open-source project that tests how Identity, Credentials, and Access Management (ICAM) can work across national borders.

The platform uses Zero Trust principles: every request is checked, every decision is logged, and nothing is trusted by default. Access rules use real user data — clearance level, country, and role — not just a username. This approach is called ABAC (rules-based access control).

DIVE V3 is built for teams exploring coalition interoperability. It is not production software, and it carries no warranty. Use it to learn, test ideas, and build on top of.

Key Capabilities

Federated Identity

Each partner organization uses its own identity system (IdP). DIVE V3 links them together using open standards — OIDC and SAML. Users sign in once and can access shared resources across the coalition.

Policy-Based Access (ABAC)

Access rules use real user data — clearance level, country, and job role. This is called ABAC (rules-based access control). Access is never "all-or-nothing." Each decision is precise and logged.

Policy as Code

Access rules are written in a language called Rego. They live in version control and are applied across all instances. You can read, review, and audit them like any other code.

Clearance Enforcement

The platform maps clearance levels across 34 countries using NATO tables. Access is denied by default — a user must meet clear criteria to qualify. No guesswork. No exceptions.

Zero Trust Architecture

Every service uses TLS (encrypted connections). No service trusts another by default. Secrets are stored in HashiCorp Vault, which rotates them and logs all access.

Full Audit Trail

Every access decision and policy change is logged. Logs follow the ACP-240 format, so they are easy to share during audits. Nothing happens without a record.

How It Works

  1. Hub Deploys

    The hub instance starts with 12 core services: identity (Keycloak), authorization (OPA), secrets (Vault), databases, and a reverse proxy. A single CLI command starts them all.

  2. Spokes Enroll

    Partner organizations deploy a spoke instance. They receive an auth code to request enrollment with the hub. The hub admin reviews and approves each request.

  3. Identity Links

    Keycloak connects the hub and spoke identity providers over OIDC. Federation is credential-based — no admin passwords cross the wire. Spoke users can now reach hub resources.

  4. Policy Decides

    Every request is checked against ABAC rules before access is granted. OPA checks clearance level, country, and role in real time. All decisions are logged right away.

Federated Partners

Partner spoke instances that have established a trust relationship with this hub. Each spoke runs its own identity provider and is linked via the Zero Trust federation mesh.

Live data from the hub status API
View full federation status →
Get Updates or Request Access

Get in Touch

All requests reviewed within 2–5 business days

What you can request
  • Project Updates

    Subscribe to milestone announcements and release notes.

  • Documentation Access

    Architecture guides, deployment docs, and API references.

  • API Access

    Direct API integration for research or evaluation purposes.

We collect only what's needed to respond. No marketing. No data sharing.

Used to respond to your request.

Max 1,000 characters.

Disclaimers