Human Seal

Tessera, draft profile v0.1

Verifiable trust for AI agents

The open way for AI agents to work together and be trusted without a middleman: each agent carries a signed passport, and each action it takes produces a signed receipt. Anyone can verify both offline.

The passport

A small signed object an agent presents so others know who it is and what it may do.

FieldMeaning
didThe agent's decentralized identifier (did:web, bound to a domain the operator controls).
tenantThe organization the agent acts for.
capabilitiesThe action types the agent is permitted to propose or perform.
seal_endpointWhere a verifier can fetch the Human Seal receipts the agent produces.
issued_at, expires_atThe validity window.
issuerThe did of the issuer.
signature_ed25519, public_keyEd25519 signature over the canonical passport, and the verification key.

A sample passport is published. Paste it into the verifier: it verifies, and it fails if you change any field. It is signed with a throwaway key for illustration; a production passport is signed with the issuer's did:web key.

The handshake

  1. Discover: fetch the counterparty agent's passport from its did:web location or from a presented token.
  2. Identify: verify the passport signature, confirm the key resolves from the did document, and check the validity window.
  3. Authorize: confirm the action you are about to rely on is within the passport's capabilities.
  4. Act and verify: when the agent takes a world-affecting action it produces a Human Seal receipt, which the relying party verifies offline.

No step contacts a central broker. Every check is against published keys.

Interoperability, stated precisely

The emerging IETF signed-action-receipt draft (an individual Internet-Draft, not endorsed by the IETF) signs machine policy decisions with Ed25519 over RFC 8785 canonical JSON. Tessera uses the same signature algorithm and adds what that format does not carry: the identity of the human approver.

Where they differ today: our canonical form differs from RFC 8785 in string escaping and number formatting, and is identical for ASCII-only data with integer numbers. The conformance page states the exact rules. Aligning a future version with RFC 8785 is a proposal, versioned so existing receipts stay verifiable.

Status