Consent receipt spec

This is a practical spec for a consent receipt: a portable permission artifact for AI agents that supports transaction-time YES/NO verification with replay safety and an auditable proof record.

Goals

• Transaction-scoped permission: verify a specific action with explicit constraints.
• Deterministic outcome: return YES/NO and a proof record.
• Replay-safe: prevent reuse of permission artifacts for payment-like actions.
• Privacy-first: avoid storing unnecessary PII while remaining auditable.

Receipt format

Receipt is canonical JSON. Signing should be deterministic (canonicalization required). The payload must be verifiable without network calls where possible.

Field reference

Field	Type	Notes
receipt_id	string	Stable unique ID. Use UUID or similar.
issuer	string	Who issued/signed the receipt (authority).
delegator	string	User/principal identifier (pseudonymous OK).
agent_id	string	Agent identifier bound to keys/credentials.
scope	array[string]	Allowed actions, e.g., payment.authorise.
constraints	object	Limits: amount/currency, merchant/category, channel, etc.
nbf	string (ISO8601)	Not-before time (optional).
exp	string (ISO8601)	Expiry time.
nonce	string	Replay protection value (single-use recommended for payments).
revocation	object	Revocation model: status endpoint ref, or revocation list ID.
signature	object	Key ID + algorithm + signature over canonical payload.
offline_policy	object	Optional rules for offline verification (freshness window, sync requirements).

Constraints object (recommended)

• max_amount, currency
• allowed_merchants and/or allowed_mcc
• channels (ecom, in-store, API)
• velocity (per-transaction, per-day, per-month)

Verification rules

1. Signature validity: validate signature and key binding.
2. Time validity: now ≥ nbf, now < exp.
3. Revocation: receipt must not be revoked (online check or bounded offline).
4. Scope match: requested action must be included in scope.
5. Constraint match: context must satisfy constraints (amount/MCC/merchant/etc).
6. Replay check: nonce semantics enforced (single-use or bounded-use).
7. Output: return eligible YES/NO + proof record (hash/ID/policy version/context).

Replay protection

Receipts for payment-like actions should be single-use. The nonce must be checked against a ledger.

• Online: check and mark nonce as used atomically.
• Offline: apply freshness windows and reconcile on reconnect; expect residual risk.

Offline policy

Offline verification is allowed when:

• signature and constraints can be validated locally
• freshness window bounds drift
• nonce usage is reconciled on reconnect

Example receipt

{
  "receipt_id": "cr_456",
  "issuer": "affixio",
  "delegator": "user_123",
  "agent_id": "agt_123",
  "scope": ["payment.authorise"],
  "constraints": { "max_amount": 5000, "currency": "GBP", "allowed_mcc": ["5411"] },
  "nbf": "2026-03-18T00:00:00Z",
  "exp": "2026-04-18T00:00:00Z",
  "nonce": "n_789",
  "revocation": { "type": "status_endpoint", "ref": "https://issuer.example/consent/status/cr_456" },
  "signature": { "alg": "Ed25519", "kid": "k_001", "sig": "base64:…" },
  "offline_policy": { "freshness_seconds": 3600, "require_sync_on_reconnect": true }
}

Related

• Consent receipts (concept hub)
• What is a consent receipt? (definition)
• Proof of permission (vocabulary)
• Stateless verification (decision model)
• OAuth vs consent receipts (comparison)