Format and signature
A receipt is a compact JWS with media type application/mandateshield-receipt+jwt, protected type MSD+JWT and ES256 signature. Verifiers resolve the signing key from /.well-known/jwks.json by kid. Unsigned or unsupported algorithms fail.
Canonical digests
Input and decision objects are serialized as UTF-8 JSON with object keys sorted lexicographically at every depth, arrays retained in order and primitive values serialized with JSON semantics. SHA-256 is computed over those exact bytes and encoded as lowercase hexadecimal prefixed by sha256:.
Required signed claims
- issuer, relying-party audience, issuance, not-before and expiry
- unique receipt ID, specification URL and receipt profile
- input digest, decision digest, decision and protocol
- execution-authorized boolean and mandate version/hash binding
- signature, authority, issuer-key and tenant assurance metadata
- public transparency lookup URL
Execution rule
A receipt can identify a consumable reservation only when its signed decision is ALLOW, enforcement_authorized is true, authority is valid, key trust is ACCOUNT_PINNED, and a registered mandate binding is present. Signature validity alone never authorizes payment. The receipt is a bearer input to the audience-bound execution-transition endpoint; a PROCESSOR-scoped key must transition the matching durable RESERVED record to CONSUMED before the gateway makes one provider submission.
Independent verification
Verify the protected algorithm, type and key ID; validate issuer, intended audience, time window and specification; recompute any available input and decision digests; enforce the execution rule; then compare the receipt hash with its public transparency record.