--- title: "Solutions · iDen2" description: "Trust is fragmented. Every industry rebuilt it in isolation. See why the internet needs a shared trust layer, and how iDen2 is the engine that makes it reusable." last_updated: 2026-10-10 canonical: https://www.iden2.com/platform/phenix --- 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](https://www.iden2.com/assets/phenix-logo-BbOqOxG4.webp) 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](https://framerusercontent.com/images/PcCnZrOK8Ga7y6fWErC4nGPemY.jpeg?width=325&height=325) 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. [Documentation](https://docs.iden2.com/) 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. * [W3C VC 2.0](https://www.w3.org/TR/vc-data-model-2.0/) * [SD-JWT](https://datatracker.ietf.org/doc/html/rfc9901) * [mdoc / ISO 18013-5](https://www.iso.org/standard/69084.html) * [OpenID4VC](https://openid.net/sg/openid4vc/) * [OpenID4VP](https://openid.net/specs/openid-4-verifiable-presentations-1%5F0.html) * [eIDAS 2.0](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation) * [EUDI Wallet](https://digital-strategy.ec.europa.eu/en/policies/eudi-wallet) * [OIDC](https://openid.net/specs/openid-connect-core-1%5F0.html) * [SAML 2.0](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html) * [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) [Documentation](https://docs.iden2.com/) ## Sitemap - [Sitemap](https://www.iden2.com/sitemap.md) - [llms.txt](https://www.iden2.com/llms.txt) - [HTML version](https://www.iden2.com/platform/phenix)