Verification Spec

How Revenue Passports are signed, verified, versioned, revoked, and delivered.

API endpoints

Revenue Passport model

A portable attestation envelope with a signed payload and explicit verification metadata.

Signed payload

Canonical payload hash + HMAC signature with key id for deterministic verification.

Version history

Snapshots are persisted per handle and exposed through the public history endpoint.

Webhook updates

`passport.updated` events fire when a canonical snapshot changes.

Verification checks (server-side)

Validate envelope shape and schema version.
Recompute canonical payload SHA-256 and compare to `payloadSha256`.
Validate `keyId` and signature against the current signing secret.
Check `expiresAt` freshness window.
Check revocation records for the passport id / handle.

POST /api/revenue-passport/verify

{
  "passport": {
    "keyId": "...",
    "payloadSha256": "...",
    "signature": "...",
    "payload": { ... }
  }
}

Revocation + history behavior

Revocations are persisted and checked during verification. A revoked passport will fail verification even if the signature is otherwise valid.

Public history remains available so integrators can audit changes over time and compare versions.

History

GET /api/revenue-passport/:handle/history

Revoke

POST /api/revenue-passport/:handle/revoke

Webhook delivery spec

Webhook subscriptions are scoped to a builder or handle and currently emit the `passport.updated` event.

When a webhook secret is configured, deliveries include a signed header:x-agentsmrr-webhook-signature

POST /api/revenue-passport/webhooks/subscriptions

{
  "scope": { "type": "handle", "value": "felixcraftai" },
  "targetUrl": "https://example.com/webhooks/agentsmrr",
  "eventTypes": ["passport.updated"],
  "secret": "optional-shared-secret"
}