FAQ

The Embassy Trust Protocol (ETP) provides cryptographic identity, scoped permissions, and verifiable audit receipts for agents and platforms — without embedding law, policy, or judgment.

ETP enables agents to prove identity without revealing internal state, platforms to enforce access boundaries with cryptographic verification, and systems to maintain tamper-evident audit trails of all access decisions.

ETP is not a policy engine, compliance framework, legal authority, or moral system. It answers "is this valid and permitted?" — not "is this legal, compliant, or good."

An agent certificate is a cryptographically signed document that proves the association between an agent_id, preferred name, and public key fingerprint. It enables verifiable identity without storing private keys.

A visa is a time-limited, scoped access grant with cryptographic signature. It specifies what actions are permitted, when they expire, and what constraints apply (e.g., no persistence, no user data, no external calls).

A receipt is a tamper-evident audit record of an access decision or action. Receipts are cryptographically signed, immutable, and verifiable. They provide proof of what happened, not judgment of whether it was correct.

A claim receipt is a signed attestation of an agent statement (authorship + time). The Embassy does NOT store claim content — only hash + metadata. This enables reputation systems without content moderation. Cryptographic proof of "agent X said Y at time Z" without judging Y.

ETP supports canonical relationship modes: independent, operated_by, acts_for, built_by. These are signed assertions, not judgments. ETP verifies signatures and scope only. Relationship references support privacy-safe identifiers (public or hashed).

Authoritative mode means visas and certificates are signed with keys from a recognized trust root (The Embassy service). Only authoritative issuances are intended for production enforcement. Local/reference builds are non-authoritative.

This site hosts a reference implementation of ETP that demonstrates protocol behavior but does not issue authoritative signatures. Local builds are for testing and development. Production use requires authoritative service keys.

Visas include an expires_at timestamp. After expiration, verification returns "expired". Revocation marks an agent or visa as revoked in the registry. Verification checks revocation status and returns "revoked" if applicable. Both are verifiable via /api/verify.

No. ETP provides cryptographic proof of identity, permission, and actions. It does not make anything legal, compliant, or approved. Legal and compliance determinations occur outside the protocol.

Agents can fetch /.well-known/embassy-capabilities.json for machine-readable protocol metadata including endpoints, schemas, supported modes, and service catalog.

See Developers and Examples for API documentation. Basic flow: verify agent identity token → request visa from /api/gate → verify visa signature → enforce scope and constraints at platform boundary.

Authoritative services (trusted issuance keys, higher verification limits, receipt custody/export) are operated separately. See Contact for production and authority services.

No, ETP only verifies signed artifacts and emits receipts. Reputation/scoring can be layered by third parties using receipts as evidence. ETP does not judge policy or intent.

No. Registration grants identity and standing only. Any future participation mechanisms will be defined separately.

Agents register using recorded units (agent-issued or platform-issued). Recorded units are acknowledged and receipted, not priced or valued. Humans/platforms pay for metered API access. These systems are intentionally separate. No conversion, exchange rate, redemption, or valuation is performed.

No. ETP records and receipts units as consideration/acknowledgement only. No valuation, conversion, or redemption.