DIDX Enterprise

Control sensitive actions before they execute.

DIDX API gives enterprises a trust decision layer for high-risk actions. PassPal gives users the clean proof handoff. Passpod decides whether the action can continue.

One trust layer. Two interfaces. The enterprise gets a clean decision. The user gets a clean request. The action only moves forward if the right conditions exist.

AI action control Delegated authority High-risk approvals
See the canonical flow Review enterprise flows

Trust? Proven! — but only for the action that matters, at the moment it matters.

Two product surfaces. One decision system.
One trust layer and two interfaces showing DIDX API for enterprises, Passpod as the trust decision layer, and PassPal for people.
Enterprise side Request received → trust checked → decision returned.
User side Request opened → right proof shared → next step shown.
Passpod layer Proof, scope, authority, timing, and action policy stay aligned.
Canonical bridge

One trust layer. Two interfaces.

DIDX API is the enterprise decision surface. PassPal is the user proof handoff. The model only works when both sides stay visible.

For enterprises

DIDX API

What the institution sees: a clean trust decision for authority, approvals, onboarding, recovery, or AI execution.

DIDX API enterprise trust flow showing how a request enters the system, is evaluated, and returns a clear decision.
1. Request enters the system — the enterprise defines the action, scope, risk level, and proof policy.
2. DIDX API checks trust — identity, authority, consent, signature need, time window, and runtime conditions.
3. Decision is returned — allow, review, ask for more proof, or keep execution locked.
Enterprise outcome: the company gets a clean decision object instead of guessing from screenshots, PDFs, or vague claims.
For people

PassPal app

What the user sees: a readable request, the right proof level, and the next clear step — without oversharing.

PassPal Trust Pass flow showing request received, proof shared, Passpod verification, Trust Pass issuance, and next step unlocked.
1. Request appears in PassPal — plain language, one action, one reason, one time window.
2. The user shares the right proof — not more than needed, not broader than the workflow justifies.
3. A clear next step is shown — approved, review needed, or stronger proof required.
User outcome: the user understands what is being asked, why it is needed, and what happens next — without protocol noise.
AI action control

The trust firewall inside the action flow

DIDX Enterprise does not just verify identity or attributes. It decides whether a sensitive human or AI action should be allowed to continue at all.

1 · Intent

The action is declared

The system must state what it wants to do, for whom, in which workflow, and why. No structured intent, no sensitive execution.

2 · Policy

Passpod classifies risk

The request is classified as approval, payment, onboarding, recovery, access, disclosure, or admin change and gets a trust threshold.

3 · Handoff

PassPal gathers the right proof

The user sees a plain-language request and can approve, narrow scope, deny, escalate, or stop the path before the action executes.

4 · Enforcement

Execution is condition-bound

The target system only accepts the action if a valid pass exists and runtime conditions still match. Revocation stays possible.

Enterprise trust flows

Five trust flows where clean decisions matter first.

Start with sensitive workflows where DIDX API and PassPal can turn scattered proof, authority, and risk signals into a clearer decision.

1. Delegated authority & mandates

Verify whether someone can legally act for an organization for this exact action, not in general.

01
  • EU-ready
  • High-value B2B
  • Representation

User side — PassPal

  1. Open request: confirm you can act for Company X.
  2. Review scope: see what is being checked and why.
  3. Share minimum proof: identity, organization link, mandate, validity.

Institution side — DIDX API

  1. Create policy: action, scope, risk level, signer rule.
  2. Evaluate: mandate freshness, scope match, revocation or expiry.
  3. Return decision: authority verified, scope matched, next action.
Why this is a strong first wedge

The real enterprise question is not only who the person is. It is whether they can do this exact action right now.

2. High-risk approvals & signing

Confirm that a payment, contract, or approval comes from the right person with the right authority.

02
  • Fast ROI
  • Fraud reduction
  • Audit-ready

User side — PassPal

  1. Open request: approve this contract or payment action.
  2. Review action: amount, counterparty, context, signer scope.
  3. Sign if needed: proof, consent, and signature stay cleanly separated.

Institution side — DIDX API

  1. Classify action: payment, contract, admin change, policy approval.
  2. Evaluate: authority, transaction binding, signature state, threshold match.
  3. Return decision: allow, review, or keep execution locked.
Why buyers care fast

This is the easiest monetization path because companies already understand weak approval chains and unsafe execution risk.

3. Recovery & anti-impersonation

Protect high-risk resets and recovery flows from phishing, persuasion, help-desk abuse, and unsafe AI-assisted actions.

03
  • Cyber-critical
  • Help desk
  • Step-up proof

User side — PassPal

  1. Open recovery request: identity for this reset only.
  2. Review scope: recovery, not broad account use.
  3. Approve minimum proof: identity and recovery legitimacy only.

Institution side — DIDX API

  1. Set risk mode: reset context, step-up level, short time window.
  2. Evaluate: proof freshness, action scope, device or context if needed.
  3. Return decision: allow, review, deny, or freeze the AI path.
What must be hardened

Recovery UX must feel safe without becoming a dead end. Weak fallback logic kills trust fast.

4. Supplier representative verification

Verify that a vendor-side contact is the real, current, authorized representative before money or access moves.

04
  • Procurement
  • Vendor trust
  • B2B controls

User side — PassPal

  1. Open request: confirm you are authorized to act for Supplier Y.
  2. Review scope: sales, finance, legal, or procurement context.
  3. Share proof: identity, organization link, representative status, scope.

Institution side — DIDX API

  1. Create request: supplier, role, intended action, risk level.
  2. Evaluate: org match, scope match, validity, legal-entity mapping.
  3. Return decision: representative verified, route or block.
Where this gets stronger

It gets much better when legal-entity names and role freshness are clean. Otherwise too many cases drift into manual review.

5. Regulated onboarding with selective disclosure

Move onboarding forward with only the verified attributes needed for the decision, not a document dump ritual.

05
  • Conversion
  • Privacy-first
  • Regulated flows

User side — PassPal

  1. Open request: identity, residency, or eligibility only if needed.
  2. Review reason: see exactly what is being asked and why.
  3. Approve minimal claims: threshold first, identity second.

Institution side — DIDX API

  1. Set policy: onboarding type, required claims, fallback rule.
  2. Request minimum proof: avoid over-asking by default.
  3. Return decision: continue, review, or ask for narrow follow-up.
Why users like this

Users feel the privacy win immediately: less oversharing, less friction, more transparency.

Why this reads better

Why this is cleaner

Weak shortcuts on one side. Action-bound trust control on the other.

Today

  • Email approvals and forwarded PDFs
  • Screenshots, uploaded documents, and stale role lists
  • Manual guesswork in help desks and operations
  • Over-collection of identity data just in case
  • AI assistants with unclear authority and weak stop rules

With DIDX + PassPal + Passpod

  • One action, one request, one policy-bound decision
  • Minimum proof with clearer scope, consent, and timing
  • Cleaner authority, signature, and entitlement checks
  • Decision-ready receipts and workflow outputs
  • AI execution locked unless the right trusted pass exists
Next step

Start with one sensitive workflow.

Use DIDX API as the enterprise trust decision layer for workflows where people and systems need a cleaner answer before the action continues.

The strongest story is simple: this is not more identity friction. It is a clearer way to stop sensitive human and AI actions unless the right proof and approval are in place.

Request enterprise demo See PassPal entry point