What is a trust receipt protocol?

A trust receipt protocol records limited receipt state around a sensitive digital request: who requested, why, what scope was requested, what consent exists, what source confirmed, what expires, what was revoked, and who made the final decision.

Passpod is the trust receipt protocol. PassPal is the trust decision interface. DIDX is the limited receipt-state registry.

Plain-language definition

A trust receipt protocol is infrastructure for making sensitive digital decisions reviewable. It does not merely prove identity. It records what happened around a request so a user, company, relying party, or auditor can later understand the decision context.

Why identity alone is not enough

Modern trust workflows often stop at identity, credential possession, or access control. That is useful, but incomplete. A sensitive action also needs context: who requested it, why it was requested, what the user approved, what source confirmed it, when it expires, and who remains responsible.

This matters for AI agents, account recovery, call centers, remote work verification, identity wallets, and enterprise access-control workflows. The risk is not only whether someone is real. The risk is whether the request itself is legitimate, scoped, reviewable, and accountable.

How a Passpod trust receipt works

1. The requester requests. A person, service, company, AI agent, or relying party initiates a sensitive request.
2. The user consents. The user approves, rejects, defers, or asks for review with visible scope and purpose.
3. The source confirms. A source-labeled confirmation may support the request without exposing unnecessary documents.
4. The responsible party decides. The relying party or responsible actor makes the final decision. Passpod does not replace that responsibility.
5. Passpod records. Passpod records limited receipt state: status, scope, source labels, expiry, revocation, and decision context.
6. DIDX verifies limited receipt state only. DIDX helps verify selected receipt-state outputs without turning Passpod into a personal ranking system.

What Passpod records

• Requester context: who asked and under what role or authority.
• Purpose and scope: why the request exists and what exact action or claim is requested.
• Consent state: whether the user approved, rejected, deferred, or requested review.
• Source confirmation: what source confirmed the relevant fact, signal, or request context.
• Expiry and revocation: how long the receipt state lasts and whether it was revoked.
• Decision boundary: who made the final decision and what Passpod did not decide.

What DIDX verifies

DIDX verifies limited receipt state only. It should not be framed as a system that exposes private documents, ranks people, or guarantees trust. Its role is to make selected receipt-state outputs easier to read, verify, and reference.

What Passpod does not claim

Passpod does not claim to prevent breaches, replace wallets, replace public authorities, guarantee safety, guarantee compliance, or make the final decision. It adds a receipt-state workflow around sensitive requests.

Where trust receipts are useful

Trust receipts are useful when the question is not only “Who is this?” but “What exactly is being requested, under what scope, with what consent, supported by which source, and with which responsibility boundary?” That distinction matters because many digital failures happen after identity has already been established. A user may be real, an employee may be real, and an AI agent may be authorized, while the specific request still needs review.

In an account recovery flow, a trust receipt can record that a recovery request was made, what evidence was requested, what source confirmed the signal, when the receipt expires, and who approved the final recovery step. In a call center flow, it can record the requester context and confirmation state without exposing unnecessary private documents to the agent. In an AI-agent workflow, it can record whether an agent had approval for a sensitive action before the action continued.

Why a receipt is different from a score

A score usually compresses complex context into a number. That can be misleading. A receipt preserves the key parts of the decision context. Passpod should not be described as a personal ranking system. The value is not to declare that a person, company, or agent is universally trustworthy. The value is to make one sensitive request more reviewable.

This is why Passpod uses receipt-state language. A receipt can say that a request was approved for a specific purpose, under a specific scope, with a specific source label, until a specific expiry. It can also show revocation or review state. That is more precise than a vague trust claim.

How this supports identity wallets and EUDI-era workflows

Identity wallets can help prove credentials. That is important. But relying parties often need more than credential possession. They need request context, consent evidence, expiry, revocation, and a record of who made the final decision. Passpod is designed to be wallet-complementary: wallets can prove, while Passpod records the receipt-state workflow around the request.

For EUDI-era and identity-wallet ecosystems, this distinction is important. Passpod should not claim to be an official wallet, a public authority, or a certification body. It can instead provide a receipt layer that helps relying parties and users understand what happened around a sensitive request.

When not to use a trust receipt

A trust receipt should not be used to create fake certainty. It should not be used to hide decision responsibility, bypass consent, collect unnecessary data, or imply legal compliance that has not been verified. It should not turn private identity details into public reputation. If a workflow does not need a receipt, the better design may be to avoid creating one.

The best trust receipt is narrow, useful, time-bounded, source-labeled, revocable when needed, and easy to explain to the person affected by the decision.

Example trust receipt payload

{
  "receipt_type": "sensitive_request_review",
  "requester": "example.company",
  "purpose": "account_recovery_review",
  "scope": ["requester_context", "consent_state", "source_confirmation", "expiry", "revocation"],
  "consent_state": "approved",
  "source_confirmation": {
    "source": "company_helpdesk",
    "strength": "source_labeled"
  },
  "expiry": "2026-06-17T00:00:00Z",
  "revocation_state": "active",
  "responsible_party": "example.company",
  "passpod_records": "limited_receipt_state",
  "didx_verifies": "limited_receipt_state_only"
}

Try this workflow in the Passpod API Console

FAQ

Is Passpod an identity provider?

No. Passpod is not an identity provider. It is a trust receipt protocol around sensitive digital requests.

Does Passpod replace wallets?

No. Passpod is wallet-complementary. Wallets can prove credentials. Passpod records what happened around a request.

Does Passpod prevent breaches?

No. Passpod should not be described as a breach-prevention tool. It adds reviewable receipt-state workflow around sensitive requests.

Who decides?

The responsible party decides. Passpod records limited receipt state. DIDX verifies limited receipt state only.