Platform Phenix®

A network where credentials are issued once and trusted everywhere

Underneath the outcome sit five services. You rarely need all of them on day one.

Phenix logo
Today

Trust is rebuilt every time it's needed.

Every bank re-verifies the same person. Every hospital re-collects the same history. Every enterprise re-onboards the same supplier. AI agents act with shared keys. Identity is verified constantly and reused almost never.

Today
status: fragmented
Every verifier rebuilds the stack.
16
bespoke integrations
Days
to re-verify per user
None
reuse across systems
On iDen2
status: reusable
Four credentials, one reusable wallet.
1
shared trust layer
Seconds
to verify anywhere
Any
verifier in the network

The problem isn't the checks. It's that no two verifiers speak the same language. Every relationship starts from zero.

01 · The engine

iDen2 is the trust engine that makes the layer real.

A shared layer needs a running engine. One that mints credentials from authoritative sources, holds them where the subject controls them, verifies in a single call, and binds AI agents to a named principal. That engine is iDen2.

Standards-first, vendor-neutral, deployable at national scale.

iDen2 architecture
Open standards · vendor neutral
Applications
Government · Banking · Healthcare · Enterprise · AI · Commerce · Travel · Education · Insurance · Telecom · Energy · Logistics · and more
Interfaces
Credential Factory · Verification Gateway · Credential Registry
Trust Engine
Policies · Governance · Audit · Compliance · Controls
Open Standards
W3C VC 2.0 · SD-JWT · ISO 18013-5 · OpenID4VC · eIDAS 2.0
Registries
Issuer keys · Status lists · Trust anchors · Audit log
Why now
“SSI wallets are the security architecture AI has been waiting for. Verifiable credentials give AI systems a trusted identity layer, and APoC gives enterprises the audit trail they need to deploy AI with confidence.”
Marius Scurtescu
Marius Scurtescu
Chief Technology Officer
02 · Interfaces

The product interfaces

A tenant creates the claim. The Credential Factory signs it. The holder keeps it. A verifier checks it against the registries. Same path, every industry.

issues
presents
is an accredited issuer
checks the register
credential is registered
is it still valid?
Issuing
Tenant
Credential Factory
private key
Verification Gateway
Verifying
Tenant
Trust Network
Credential Registry
Holder
Solid lines follow the credential; dotted lines are lookups, registry checks, and tenant wiring.
  1. 01

    A trusted source issues a credential.

    A government, bank, employer, or supplier signs a claim about a subject. Any verifier can check that signature against the issuer's public key, at any point in the future.

  2. 02

    The subject holds it in a wallet.

    The credential lives on the subject's device, not in the verifier's database. Ownership stays with the person or organization it describes.

  3. 03

    A verifier requests only what it needs.

    Selective disclosure returns the exact fields required. A date-of-birth check does not disclose an address. Same credential, safe across every industry.

  4. 04

    An AI agent inherits scoped authority.

    The holder delegates a bounded, revocable mandate. Every counterparty can prove who authorized the action, and on what terms, at the moment it happens.

  • 01

    Credential Factory

    OID4VCI credential issuance for the iDen2 trust network. It orchestrates offers and issuance of SD-JWT and W3C verifiable credentials while signing keys stay in Vault Transit, so private keys never leave Vault. Each issuer maps 1:1:1 to a DID and Vault transit key, can publish multiple credential types, and registers status with the Credential Registry at issue time.

  • 02

    Verification Gateway

    OpenID4VP credential verification for the iDen2 trust network. It creates verification sessions, accepts wallet presentations against configured presentation definitions, and validates VP tokens for relying parties. Sessions can be polled for status, and every check is trust-network aware, including credential status lookups against CRS status lists.

  • 03

    Credential Registry

    Privacy-preserving credential status management for revocation and suspension, using W3C Bitstring Status List 1.0 so verifiers can check status without querying individual credentials. Issuers register and update status; the registry publishes public bitstring lists with history and an audit trail, under Trust Engine governance, and is built for high-volume checks with caching.

  • 04

    Trust Engine

    Source of truth for trust network configuration: members, policies, and credential types, consumed by the rest of the platform. Registry and network config APIs expose member and policy metadata for issuance and verification governance, with hot reload from configuration data and HTTP caching (ETag, Cache-Control) for clients. Credential Registry, Credential Factory, and Verification Gateway all depend on it.

  • 05

    Custody Controls (Wallet)

    Native iOS and Android wallet for holders on the iDen2 trust network. Holders receive, store, and present verifiable credentials via OID4VCI (SD-JWT VC) and OID4VP, with every interaction validated against the Trust Engine before credentials are accepted or shared. It also supports identity verification against government-issued documents.

  • 06

    iDen2 Mobile Wallet SDK

    Flutter SDK that embeds the same wallet capabilities in third-party iOS and Android apps on the iDen2 trust network. Host apps accept OID4VCI credentials (SD-JWT VC), run OID4VP presentation flows, and apply Trust Engine validation of issuers and verifiers before any credential interaction, matching the native wallet’s trust checks.

03 · Open by design

Built on the standards the world is converging on.

No proprietary formats. No lock-in. iDen2 speaks the same language as regulators, banks, and every other wallet.