%% You should probably cite draft-wilder-scitt-physical-site-engage-receipt-04 instead of this revision.
@techreport{wilder-scitt-physical-site-engage-receipt-00,
    number =    {draft-wilder-scitt-physical-site-engage-receipt-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-wilder-scitt-physical-site-engage-receipt/00/},
    author =    {Rob Wilder},
    title =     {{A SCITT Profile for Physical-Site Engagement Receipts}},
    pagetotal = 19,
    year =      2026,
    month =     jul,
    day =       29,
    abstract =  {This document defines a SCITT profile for \_Physical-Site Engagement Receipts\_ (PSER): tamper-evident, signed, offline-verifiable records that describe an autonomous or human-directed physical engagement at a specific real-world site governed by a defined operating envelope. Each receipt is a SCITT Signed Statement as defined by the SCITT architecture, encoded as a COSE Single Signer message, carrying a JCS-canonicalized JSON payload with a five-artifact vocabulary describing (1) the \_Site\_, (2) the \_Operator\_ and \_Actor\_, (3) the \_Engagement Window\_ and \_Envelope\_, (4) the \_Attestation Evidence\_ from a Trusted Execution Environment (TEE), and (5) the \_Adapter Write-In\_ recording that the receipt was posted into an out-of-band operations layer. A Physical-Site Engagement Receipt is registerable in any conforming SCITT Transparency Service to obtain non- equivocation and tail-truncation properties an issuer's own chain cannot provide alone. This profile deliberately makes a NARROW, checkable claim -- "this is a tamper-evident, signature-verifiable record that a specific engagement occurred at a specific site under a specific envelope, and its evidence was sealed by a specific TEE" -- and explicitly does NOT claim that the engagement was safe, correct, or wise, that the site conditions were as described, or that any downstream operational outcome followed. Compliance verdicts derived from the receipt (SLA credit, insurance underwriting, regulatory audit) are the responsibility of the relying party and its policies, not of this profile. The profile is designed around a three-party trust model in which no single party can unilaterally forge or repudiate a receipt: the \_site owner\_ physically hosts and controls the TEE hardware (they own the box); the \_TEE silicon vendor\_ attests the key material inside the TEE through its hardware root of trust (silicon vouches for the key); and the \_Issuer\_ writes the vocabulary, registers Signed Statements with a Transparency Service, and posts the resulting receipt into the site's operations layer via a WRITE\_ONLY adapter. This separation is normative in this profile: implementations MUST NOT collapse these three roles into a single custodian, and relying parties MUST NOT trust a receipt that lacks any one of them.},
}