An authenticated receipt requires a trusted binding between provider identity and public key. The verifier MUST obtain keys from that registry or another approved trust source; a public key embedded in an untrusted receipt is not sufficient.
Key lifecycle#
KEY-01 A key record includes provider_id, key_id, algorithm, public key, permitted scope, activation time, expiry and revocation state. Rotation creates a new record. Historical verification retains the applicable key version and revocation decision. A claimed signing time cannot independently establish that a compromised key was safe at that time.
Candidate signature profile#
Ed25519 and the JSON Canonicalization Scheme are candidates for protocol review. Reference 0.2 implements neither. Its helper named canonical normalizes parsed numeric values for comparison and is not an RFC 8785 implementation. [S2][S4]
unsigned_envelope = {
"profile": "ocean6-receipt-draft-1",
"key_id": registered_key_id,
"algorithm": "Ed25519",
"payload": receipt_payload
}
signing_bytes = ASCII("OCEAN6_RECEIPT_DRAFT_1")
+ byte(0x00)
+ JCS_UTF8(unsigned_envelope)The notation above is pseudocode. The proposed signature covers the profile, key identifier, algorithm and full payload. The final envelope adds a signature field. The protocol review must freeze encoding, Base64url rules, field limits, library choices and positive and negative test vectors before implementation claims are made.
Binding and replay resistance#
SIG-01 The payload MUST bind network_domain, task_id, attempt_id, lease_id, fencing_token, request digest, output digest and validity conditions. Verification checks authority at recorded delivery admission and deduplicates receipt identity even when the signature is valid.
SIG-02 If key lookup or revocation evaluation is unavailable, defer identity-dependent acceptance. Do not silently downgrade to a digest-only check. A signature establishes an attributable statement within its trust assumptions; hardware provenance and computation correctness require additional evidence.