Bind human identity, credentials, biometrics, devices and Agents
1. VERIFY
Establish a trusted person or organization
2. BIND
Issue scoped, time-bound, cryptographically sealed authority to an agent
3. DELEGATE
Agent presents proof with the requested action
4. CHECK
Counterparty verifies identity scoped and status
5. AUDIT
Record evidence; revoke authority when needed
You can't trust an agent's credentials unless it's delegated from a trusted human's credentials, so whoever holds the human wallet owns agent trust.
Custody Control: Intelligent Wallet
The ecosystem at a glance
Issuers verify facts, the wallet holds them, and relying parties accept them with the person's consent.
System view
A modular trust operating system
Issuance · Phenix®
Credentials Factory
Creates verifiable digital IDs from any identity source, with a full audit trail.
Verification
Trust Engine
Checks that credentials are real, current and policy compliant, in real time.
Intelligent wallets
Custody Control
Consent, delegation and revocation in one place. Hosts policy governed agents.
AI control
CAPoC Engine
Proves an AI agent is authorized. Every action signed by a real person.
Integration
Verification Gateway
Connects to existing identity platforms and all major credential formats.
No rip and replace required, five modules, one root of trust.
Data flow
How a credential moves between the components
A tenant creates the claim. The Credential Factory signs it. The holder keeps it in the wallet. A verifier checks the presentation against the registry and the trust engine, and the relying party gets a yes or a no. Same path, every industry.
Solid lines carry the credential, dashed lines are live checks against shared status and trust data.
Continuous Agentic Proof of Control
Authority an AI agent can prove, moment by moment
When an AI agent acts on someone's behalf, buying, transacting, filing, calling another agent, the party on the receiving end has no way to tell whether a real person stands behind it. A token proves someone once said yes. It says nothing about whether that person is still in control, or whether the agent is still the agent they approved. Continuous Agentic Proof of Control closes that gap: every time an agent acts, it presents live proof on three questions at once.
Delegation
Who authorized this agent, and for what?
The agent carries a signed chain back to the human or company that delegated to it, with the scope, the limits and the time bounds that principal actually approved, including one level of sub-delegation.
Control freshness
Is the principal still in control right now?
Authority is kept alive by a regular signal from the principal's wallet rather than assumed until a token expires. If the signal stops, or the principal withdraws it, the agent's authority stops being usable within one interval.
Agent integrity
Is this still the agent that was approved?
Each presentation attests that the agent has not been altered since it was authorized, so a swapped tool, a changed model or an injected instruction shows up as a failed check instead of passing unnoticed.
Verifiable without calling us
A relying party evaluates the whole presentation on its own, with no call back to iDen2, so checks work offline and in air-gapped environments.
Withdrawal takes effect in seconds
Stopping an agent is not a support ticket or a token revocation queue: the principal withdraws control, and authority lapses within one interval plus the freshness window they configured.
Verification Gateway
Connecting iDen2 to the systems already in place
The Verification Gateway is the translation and mediation layer in the Phenix® platform that connects the Trust Mesh to enterprise identity platforms such as Entra, Okta and Ping. It came out of three completed platform integration guides, which showed that roughly 70% of the integration logic was the same across all three. Rather than building a bespoke integration for every platform, the Gateway abstracts that shared logic into one layer.
Its scope is deliberately narrow. The Gateway is not a policy engine: it does not decide who gets access. It translates, binds and carries evidence between the Trust Mesh and the identity platform already in place, and leaves access decisions to the components that own them.
Nine components
PB-INGRESS, PB-BIND, PB-MAP, PB-DECIDE, PB-ORCH, PB-LIFE, PB-AGENT, PB-EVIDENCE and PB-TRUST, each with a defined responsibility inside the layer.
Seven integration patterns
Patterns A to G cover the ways an enterprise platform can be connected, backed by 84 numbered requirements and a platform support matrix.
Built for production
The specification includes a threat model, a failure mode table and a four phase delivery roadmap, so behavior under failure is defined before rollout.
Services
What each part does
Credential Factory
Issue credentials people can carry and reuse, with signing keys that never leave your control.
The Credential Factory runs credential issuance for the trust network on open standards (OID4VCI), producing SD-JWT and W3C verifiable credentials. Each issuing organization gets its own identifier and its own signing key, and those keys stay sealed in a hardware-backed vault: signing happens inside the vault, so the private key never leaves it. Every credential is registered with the Credential Registry at the moment it is issued, so status is known from day one.
Standards-based credential offers and issuance
SD-JWT and W3C verifiable credential formats
One issuer, one key, one identifier, cleanly separated
Multiple credential types per issuing organization
Status registered with the Credential Registry at issue time
Verification Engine
Check a credential is genuine and still valid, without calling whoever issued it.
Trust Engine is the checkpoint. It opens a verification session, asks the holder's wallet for exactly the proof required for that interaction (OpenID4VP), and validates what comes back against the rules you configured, the right issuer, the right credential type, the right claims. It confirms the credential has not been revoked by reading a published status list, so the issuer is never contacted and never learns who checked.
Verification sessions and wallet presentation flows
Configurable rules for what proof each interaction requires
Trust-network-aware checks on who is allowed to issue
Live session status for the service waiting on the result
Revocation checked against published status lists
Credential Registry
Revoke or suspend a credential, and let anyone check status without revealing who they checked.
The Credential Registry is where a credential's life is managed after it is issued: still valid, suspended, or revoked. It publishes status as a compressed public list (W3C Bitstring Status List), so a verifier answers the question locally instead of asking about one named person, nobody learns who was checked or when. Every change is recorded with a full history for audit.
Register, update and query credential status
Public status lists for revocation and suspension
Full status history and audit trail
Governed by the Trust Network at registration
Built for high-volume checks with caching
Trust Network
Decide who is allowed to issue and verify what, across every organization in the network.
The Trust Network is the single source of truth every other service reads before it acts: which organizations are members, what each is permitted to issue or verify, and which credential types exist. Change a policy in one place and issuance, verification and the registry all follow it, no bilateral agreements, no drift between participants. Configuration updates take effect without downtime.
Network and membership configuration in one place
Policies governing who may issue and who may verify
Updates applied live, with no service interruption
Efficient distribution to every connected service
Consumed by the Factory, the Trust Engine and the Registry
Custody Controls (Wallet)
Give people one place to hold their own identity and the identity of the agents acting for them.
A native iOS and Android app holding two kinds of credentials. Human credentials come from issuers the world already trusts and are selectively disclosed, so iDen2 never sees the attributes. Agent credentials are issued under the person's own authority, with scope, limits and time bounds, and stay valid only while that person's control is live. Every exchange is checked against the Trust Network first.
Human identity credentials from issuers the world already trusts
Selective disclosure, so attributes stay with the holder
A DID for every AI agent, issued under the holder's authority
Delegation with scope, limits and time bounds the holder approved
Agent credentials cryptographically bound to the person's live control
Both sides of every exchange checked against the Trust Network
Native iOS and Android, with government-document identity verification
Wallet SDK
Put the same wallet capability inside your own mobile app.
The SDK gives your existing mobile app everything the iDen2 wallet does, receiving credentials, holding them, presenting them, without asking your customers to install a second app. It ships for Flutter and drops into iOS and Android host apps, and it carries the same Trust Network checks, so every credential interaction inside your product is validated against network policy.
Same credential acceptance and presentation as the wallet
Flutter integration for iOS and Android host apps
Trust Network validation of issuers and verifiers built in
Your brand, your app, your customer journey
Credential Factory
Issue credentials people can carry and reuse, with signing keys that never leave your control.
The Credential Factory runs credential issuance for the trust network on open standards (OID4VCI), producing SD-JWT and W3C verifiable credentials. Each issuing organization gets its own identifier and its own signing key, and those keys stay sealed in a hardware-backed vault: signing happens inside the vault, so the private key never leaves it. Every credential is registered with the Credential Registry at the moment it is issued, so status is known from day one.
Standards-based credential offers and issuance
SD-JWT and W3C verifiable credential formats
One issuer, one key, one identifier, cleanly separated
Multiple credential types per issuing organization
Status registered with the Credential Registry at issue time
Verification Engine
Check a credential is genuine and still valid, without calling whoever issued it.
Trust Engine is the checkpoint. It opens a verification session, asks the holder's wallet for exactly the proof required for that interaction (OpenID4VP), and validates what comes back against the rules you configured, the right issuer, the right credential type, the right claims. It confirms the credential has not been revoked by reading a published status list, so the issuer is never contacted and never learns who checked.
Verification sessions and wallet presentation flows
Configurable rules for what proof each interaction requires
Trust-network-aware checks on who is allowed to issue
Live session status for the service waiting on the result
Revocation checked against published status lists
Credential Registry
Revoke or suspend a credential, and let anyone check status without revealing who they checked.
The Credential Registry is where a credential's life is managed after it is issued: still valid, suspended, or revoked. It publishes status as a compressed public list (W3C Bitstring Status List), so a verifier answers the question locally instead of asking about one named person, nobody learns who was checked or when. Every change is recorded with a full history for audit.
Register, update and query credential status
Public status lists for revocation and suspension
Full status history and audit trail
Governed by the Trust Network at registration
Built for high-volume checks with caching
Trust Network
Decide who is allowed to issue and verify what, across every organization in the network.
The Trust Network is the single source of truth every other service reads before it acts: which organizations are members, what each is permitted to issue or verify, and which credential types exist. Change a policy in one place and issuance, verification and the registry all follow it, no bilateral agreements, no drift between participants. Configuration updates take effect without downtime.
Network and membership configuration in one place
Policies governing who may issue and who may verify
Updates applied live, with no service interruption
Efficient distribution to every connected service
Consumed by the Factory, the Trust Engine and the Registry
Custody Controls (Wallet)
Give people one place to hold their own identity and the identity of the agents acting for them.
A native iOS and Android app holding two kinds of credentials. Human credentials come from issuers the world already trusts and are selectively disclosed, so iDen2 never sees the attributes. Agent credentials are issued under the person's own authority, with scope, limits and time bounds, and stay valid only while that person's control is live. Every exchange is checked against the Trust Network first.
Human identity credentials from issuers the world already trusts
Selective disclosure, so attributes stay with the holder
A DID for every AI agent, issued under the holder's authority
Delegation with scope, limits and time bounds the holder approved
Agent credentials cryptographically bound to the person's live control
Both sides of every exchange checked against the Trust Network
Native iOS and Android, with government-document identity verification
Wallet SDK
Put the same wallet capability inside your own mobile app.
The SDK gives your existing mobile app everything the iDen2 wallet does, receiving credentials, holding them, presenting them, without asking your customers to install a second app. It ships for Flutter and drops into iOS and Android host apps, and it carries the same Trust Network checks, so every credential interaction inside your product is validated against network policy.
Same credential acceptance and presentation as the wallet
Flutter integration for iOS and Android host apps
Trust Network validation of issuers and verifiers built in
