SCITT R. Wilder Internet-Draft Wilder Robotics Intended status: Standards Track 29 July 2026 Expires: 30 January 2027 A SCITT Profile for Physical-Site Engagement Receipts draft-wilder-scitt-physical-site-engage-receipt-00 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. Wilder Expires 30 January 2027 [Page 1] Internet-Draft Physical-Site Engagement Receipt July 2026 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Wilder Expires 30 January 2027 [Page 2] Internet-Draft Physical-Site Engagement Receipt July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.2. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Profile identifier and media types . . . . . . . . . . . . . 7 4. Receipt structure . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Field semantics . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. spec (REQUIRED, string) . . . . . . . . . . . . . . . 9 4.1.2. id (REQUIRED, string) . . . . . . . . . . . . . . . . 9 4.1.3. ts (REQUIRED, string) . . . . . . . . . . . . . . . . 9 4.1.4. site (REQUIRED, object) . . . . . . . . . . . . . . . 9 4.1.5. actor (REQUIRED, object) . . . . . . . . . . . . . . 10 4.1.6. engagement (REQUIRED, object) . . . . . . . . . . . . 10 4.1.7. attestation (REQUIRED, object) . . . . . . . . . . . 10 4.1.8. adapter (REQUIRED, object) . . . . . . . . . . . . . 11 4.1.9. chain (REQUIRED, object) . . . . . . . . . . . . . . 12 4.2. COSE header requirements . . . . . . . . . . . . . . . . 12 4.3. Attestation binding . . . . . . . . . . . . . . . . . . . 13 4.4. Clock basis . . . . . . . . . . . . . . . . . . . . . . . 13 5. SCITT registration and Receipt attachment . . . . . . . . . . 13 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. Media type registration . . . . . . . . . . . . . . . . . 14 6.2. COSE Header Parameters . . . . . . . . . . . . . . . . . 14 6.3. New IANA registries . . . . . . . . . . . . . . . . . . . 14 7. Security considerations . . . . . . . . . . . . . . . . . . . 14 7.1. What this profile does NOT attest . . . . . . . . . . . . 14 7.2. Equivocation and tail-truncation . . . . . . . . . . . . 15 7.3. Adapter Write-In is write-only in this revision . . . . . 15 7.4. TEE compromise . . . . . . . . . . . . . . . . . . . . . 15 7.5. Three-party trust model . . . . . . . . . . . . . . . . . 16 7.6. Identity attribution . . . . . . . . . . . . . . . . . . 17 7.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Complementary positioning . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Wilder Expires 30 January 2027 [Page 3] Internet-Draft Physical-Site Engagement Receipt July 2026 1. Introduction Autonomous mobile robots, semi-autonomous physical equipment, and human-directed physical work crews increasingly operate at regulated real-world sites -- warehouses, common-interest communities, industrial facilities, healthcare campuses, and public infrastructure. Relying parties -- site owners, insurers, regulators, dispatchers, and downstream operations platforms -- need portable, verifiable evidence of _what physically happened at a site_, distinct from the digital-artifact supply-chain evidence addressed by [RFC9943] and distinct from the per-action AI-agent evidence addressed by [I-D.noa-scitt-ai-agent-receipt] and [I-D.mih-scitt-agent-action-capsule]. This profile fills that gap by defining the SCITT Statement content for one _physical-site engagement_: a bounded interval during which a specific actor operates at a specific site under a stated envelope, with the evidence sealed inside a TEE and the receipt subsequently written into whatever operations layer the site already uses (property-management system, maintenance ticketing, insurance underwriting API, regulatory portal). The profile's defensibility, and its value to relying parties, comes from combining four elements that no single vendor category currently ships together: * _Site-hosted TEE trust anchor._ The signing key is bound to hardware physically located at the site under the site owner's control. Cloud-hosted transparency services can issue strong receipts, but the signing authority lives inside the cloud provider's environment; this profile REQUIRES that the authority live on the site owner's premises, attested by the TEE silicon vendor, and neither extractable by the site owner nor by the Issuer. * _Physical-work evidence vocabulary._ The five-artifact schema (Site, Actor, Engagement, Attestation, Adapter Write-In) binds the receipt to what physically happened, not merely to a software event. This vocabulary is defined in Section 4 and is stricter than a general-purpose SCITT Statement. * _WRITE_ONLY adapter into existing operations layers._ Verified evidence is posted into the systems the buyer already uses -- property-management, maintenance, warehouse-management, claims, and asset-management platforms -- as recorded by the adapter field in Section 4. This profile explicitly does NOT define a new operations dashboard; it defines how receipts enter the operations layers a site already runs. Wilder Expires 30 January 2027 [Page 4] Internet-Draft Physical-Site Engagement Receipt July 2026 * _Transparency-service registration._ Non-equivocation and cross- chain tail-truncation are detected by the SCITT Transparency Service, not by the TEE alone. A TEE on customer premises without external witnessing is insufficient; SCITT registration is REQUIRED to complete the trust model. Physical-Site Engagement Receipts are complementary to, and compose with, existing SCITT-AI drafts. An AI agent that dispatches a physical robot MAY emit an Agent Action Capsule per [I-D.mih-scitt-agent-action-capsule] describing the dispatch decision, and the physical engagement that follows MAY be recorded as one or more Physical-Site Engagement Receipts under this profile, correlated via the SCITT sub claim. 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Non-goals This revision does not: * Attest that the engagement was safe, correct, effective, or compliant with any specific regulation. * Attest that the site conditions were as recorded. * Attest that no unrecorded engagement occurred outside the instrumented boundary. * Specify a deterministic offline REPLAY of any engagement decision. * Define the operations-layer schemas the Adapter Write-In targets. * Define billing, SLA-credit, or insurance-pricing rules that a relying party may derive from a stream of receipts. These non-goals are NORMATIVE: implementations and relying parties MUST NOT imply the stronger claims from a receipt. Wilder Expires 30 January 2027 [Page 5] Internet-Draft Physical-Site Engagement Receipt July 2026 2. Terminology This document uses the terms defined in [RFC9943] (Signed Statement, Statement, Issuer, Subject, Transparency Service, Registration Policy, Receipt) and [RFC9942] (Verifiable Data Structure, Verifiable Data Structure Proof). In addition: Site: The bounded real-world location at which the engagement occurred, identified by a stable Site Identifier under the Issuer's registration authority. The Site is the physical analog of a SCITT Subject. Site Envelope: The operating constraints in force at the Site during the engagement -- permitted actor classes, permitted engagement types, geospatial bounds, temporal bounds, and referenced site- rule documents. The Site Envelope is identified by a stable envelope identifier and a content digest. Actor: The physical entity that performed the engagement -- an autonomous robot, a semi-autonomous asset, a human operator, or a human-led crew -- identified by a stable actor identifier under the Issuer's registration authority. Operator: The organization or individual responsible for the Actor during the engagement, distinct from the Issuer of the receipt when a third-party witness signs. Engagement: A bounded interval, delimited by an Engagement Window, during which the Actor performed physical work at the Site under the Site Envelope. Engagement Window: The time interval [start, end] of the Engagement, expressed in RFC 3339 UTC, with the same clock basis as the TEE- sealed evidence. Attestation Evidence: The output of a TEE that observed the Actor and the Engagement, including a platform attestation, a measured- boot chain, and a digest over the sealed evidence bundle. The bundle itself is opaque to the Transparency Service. Adapter Write-In: The record that the Signed Statement (or a reference to it) was posted into an out-of-band operations layer, together with the operation-layer system identifier, endpoint identifier, and a post-time digest of the operations-layer acknowledgement. The Adapter Write-In is what makes the receipt _useful_ to the site's existing workflow without requiring the operations layer to be modified. Wilder Expires 30 January 2027 [Page 6] Internet-Draft Physical-Site Engagement Receipt July 2026 Physical-Site Engagement Receipt (PSER): A SCITT Signed Statement under this profile, carrying a canonical JSON payload conforming to Section 4, with the profile identifier wilder.pser/0.2 and a SCITT Receipt attached as defined in [RFC9942]. 3. Profile identifier and media types The profile identifier for this document is wilder.pser/0.2 and MUST appear as the value of the top-level spec member of the payload defined in Section 4. The COSE content_type (protected header label 3, [RFC9052]) for a Physical-Site Engagement Receipt Statement is application/pser+json; profile=wilder.pser/0.2. IANA registration of this media type is requested in Section 6. The application/scitt-statement+cose and application/scitt- receipt+cose media types from [RFC9943] apply unchanged to Statements and Receipts under this profile. 4. Receipt structure A Physical-Site Engagement Receipt is a SCITT Signed Statement per [RFC9943] Section 6, encoded as a COSE_Sign1 per [RFC9052]. The payload is a JSON object serialized with JCS [RFC8785] and carried as the COSE_Sign1 payload. The payload conforms to the following schema. All members are REQUIRED unless marked OPTIONAL. { "spec": "wilder.pser/0.2", "id": "", "ts": "", "site": { "id": "", "class": "", "envelope": { "id": "", "digest": "sha256:", "geobounds": "", "temporal": { "starts": "", "ends": "" } } }, Wilder Expires 30 January 2027 [Page 7] Internet-Draft Physical-Site Engagement Receipt July 2026 "actor": { "id": "", "class": "AUTONOMOUS|SEMI_AUTONOMOUS|HUMAN|CREW", "operator": "" }, "engagement": { "id": "", "window": { "start": "", "end": "" }, "type": "", "outcomeClass": "COMPLETED|ABORTED|REFUSED|ERRORED|OBSERVED_ONLY", "envelopeConformance": "WITHIN|EXCEEDED_TEMPORAL|EXCEEDED_GEO|EXCEEDED_ACTOR|UNKNOWN", "evidenceDigest": "sha256:" }, "attestation": { "teeClass": "", "platformEvidence": "", "measuredBootChain": "sha256:", "sealedEvidence": { "digest": "sha256:", "sizeBytes": , "encoding": "" }, "witnessKey": "" }, "adapter": { "system": "", "endpoint": "", "postedAt": "", "ackDigest": "sha256:", "mode": "WRITE_ONLY" }, "chain": { "seq": , "prevHash": "sha256:|null", "hash": "sha256:" } } Figure 1: Physical-Site Engagement Receipt payload Wilder Expires 30 January 2027 [Page 8] Internet-Draft Physical-Site Engagement Receipt July 2026 4.1. Field semantics 4.1.1. spec (REQUIRED, string) MUST be wilder.pser/0.2 for receipts conforming to this document. A verifier MUST reject any Statement with a different spec value as out of scope of this profile. 4.1.2. id (REQUIRED, string) A globally unique identifier for the receipt, assigned by the Issuer. RECOMMENDED form is a URN or a uuid: prefix. id MUST NOT be reused within an Issuer. 4.1.3. ts (REQUIRED, string) RFC 3339 UTC timestamp at which the Issuer sealed the receipt. This is the receipt-issuance time; it MAY differ from engagement.window.end. 4.1.4. site (REQUIRED, object) Identifies the physical location. * site.id (REQUIRED, string): stable site identifier under the Issuer's registration authority. This is the physical analog of a Subject and SHOULD be used as the value of the CWT sub claim in the protected header (see Section 4.2). * site.class (REQUIRED, string): coarse site classification. Registry- governed; see Section 6. * site.envelope.id (REQUIRED, string): stable identifier of the operating envelope in force during the engagement. * site.envelope.digest (REQUIRED, string): JSON-DIGEST (SHA-256 of the JCS serialization) of the full envelope document. The full document MUST NOT appear in the public receipt; it is bound by digest only. * site.envelope.geobounds (OPTIONAL, string): opaque reference to geospatial bounds. Any geospatial detail beyond the reference is bound by the envelope digest, not published. * site.envelope.temporal (OPTIONAL, object): temporal window during which this envelope was in force. null values indicate "open-ended in that direction." Wilder Expires 30 January 2027 [Page 9] Internet-Draft Physical-Site Engagement Receipt July 2026 4.1.5. actor (REQUIRED, object) * actor.id (REQUIRED, string): stable identifier of the physical actor. * actor.class (REQUIRED, string): one of AUTONOMOUS, SEMI_AUTONOMOUS, HUMAN, CREW. * actor.operator (REQUIRED, string): stable identifier of the responsible operator organization or individual. 4.1.6. engagement (REQUIRED, object) * engagement.id (REQUIRED, string): stable identifier of the engagement. * engagement.window.start and engagement.window.end (REQUIRED, string): RFC 3339 UTC bounds of the engagement. end MUST be >= start. Both MUST share a clock basis with attestation.sealedEvidence (see Section 4.4). * engagement.type (REQUIRED, string): coarse engagement classification (e.g. patrol, service, inspection, delivery, installation, maintenance, presence). Registry-governed; see Section 6. * engagement.outcomeClass (REQUIRED, string): one of COMPLETED, ABORTED, REFUSED, ERRORED, OBSERVED_ONLY. OBSERVED_ONLY records that the Issuer witnessed the actor at the site but did not participate in dispatch. * engagement.envelopeConformance (REQUIRED, string): one of WITHIN, EXCEEDED_TEMPORAL, EXCEEDED_GEO, EXCEEDED_ACTOR, UNKNOWN. The Issuer MUST NOT claim WITHIN unless it evaluated conformance against the envelope digest. * engagement.evidenceDigest (REQUIRED, string): JSON-DIGEST of the engagement's internal evidence structure. The internal structure is opaque to this profile and MUST NOT appear in the receipt. 4.1.7. attestation (REQUIRED, object) Binds the receipt to the TEE that observed the engagement. This is the mechanism that distinguishes a Physical-Site Engagement Receipt from a bare signed timestamp: the sealed evidence attests that the Issuer observed the engagement from inside a hardware-rooted, remotely attestable environment. Wilder Expires 30 January 2027 [Page 10] Internet-Draft Physical-Site Engagement Receipt July 2026 * attestation.teeClass (REQUIRED, string): TEE class identifier. Registry-governed; see Section 6. Examples the registry MAY seed: intel.tdx, amd.sev-snp, arm.cca, nvidia.h100-cc, nvidia.jetson- thor-cc, aws.nitro-enclave. * attestation.platformEvidence (REQUIRED, string): reference to the platform-native attestation document, in a format defined by the TEE class. The document itself MAY be conveyed by reference (URI + digest) or inline; when conveyed inline it SHOULD be in the unprotected header of the enclosing Signed Statement, not in the payload. * attestation.measuredBootChain (REQUIRED, string): JSON-DIGEST of the measured-boot chain. * attestation.sealedEvidence.digest (REQUIRED, string): digest of the sealed evidence bundle. * attestation.sealedEvidence.sizeBytes (REQUIRED, int): size of the sealed bundle in bytes. Included to enable bounded-storage verifiers to reject bundles they cannot process. * attestation.sealedEvidence.encoding (REQUIRED, string): opaque encoding label. Registry-governed; see Section 6. * attestation.witnessKey (REQUIRED, string): key identifier of the TEE signing key. This MAY differ from the Issuer's iss when the TEE operates as a delegated witness. 4.1.8. adapter (REQUIRED, object) Records that the receipt (or a reference to it) was written into an out-of-band operations layer. This is the profile's core insight: a receipt that no operations system can see is not useful, and modifying the operations system to consume receipts natively is out of scope for most regulated sites. The Adapter Write-In makes the receipt observably present in the site's existing workflow. * adapter.system (REQUIRED, string): operations-layer system identifier (e.g. a property-management system, maintenance ticketing platform, regulatory portal, insurance underwriting API). Registry-governed; see Section 6. * adapter.endpoint (REQUIRED, string): opaque endpoint identifier within the system. Its interpretation is defined by the target system, not by this profile. Wilder Expires 30 January 2027 [Page 11] Internet-Draft Physical-Site Engagement Receipt July 2026 * adapter.postedAt (REQUIRED, string): RFC 3339 UTC timestamp at which the write-in was posted. * adapter.ackDigest (REQUIRED, string): JSON-DIGEST of the operations- layer's acknowledgement response. If the operations layer returns no structured acknowledgement, the digest is taken over an Issuer-defined minimal ack object; the object schema is specified in the Issuer's manifest and is bound by the receipt's Merkle inclusion, not published. * adapter.mode (REQUIRED, string): MUST be WRITE_ONLY in this revision. Read-in modes are explicitly out of scope; see Section 7. 4.1.9. chain (REQUIRED, object) Hash-chains successive receipts by the same Issuer to detect in-band tampering and tail truncation _within_ a presented chain, following the convention established in [I-D.noa-scitt-ai-agent-receipt] Section 5. Equivocation across chains is detected only by SCITT Transparency Service registration; see Section 7. * chain.seq (REQUIRED, int): monotonic sequence number within the Issuer's chain for the identified Subject. * chain.prevHash (REQUIRED, string or null): JSON-DIGEST of the immediately preceding receipt in the chain, or null for the first receipt. * chain.hash (REQUIRED, string): JSON-DIGEST of the receipt's canonical form, excluding the chain.hash field itself. 4.2. COSE header requirements The protected header of a Signed Statement under this profile MUST include the CWT Claims header parameter (label 15, [RFC9597]), carrying at least: * iss (CWT claim label 1): a URI identifying the Issuer. * sub (CWT claim label 2): the value of site.id from the payload, so that SCITT registration policies can be expressed over the standard sub claim. The protected header content_type (label 3) MUST be application/ pser+json; profile=wilder.pser/0.2. Wilder Expires 30 January 2027 [Page 12] Internet-Draft Physical-Site Engagement Receipt July 2026 The Signed Statement's payload MUST be the JCS serialization of the JSON object defined in Section 4. Detached payloads are NOT PERMITTED under this revision. 4.3. Attestation binding The attestation.witnessKey field carries the identity of the TEE signer. This profile permits two attestation-binding modes, which MUST be conveyed in the Issuer's manifest and MAY be recorded in the CWT Claims Set: * _Direct-witness mode:_ the Issuer's iss key is itself the TEE signer. attestation.witnessKey matches iss. * _Delegated-witness mode:_ the Issuer's iss key is distinct from the TEE signer, and the TEE has issued a delegation credential authorizing the Issuer to sign this receipt on the TEE's behalf. The delegation credential is bound by the attestation.sealedEvidence.digest and MUST be resolvable from the Issuer's manifest. 4.4. Clock basis All timestamps in a Physical-Site Engagement Receipt MUST share a single clock basis: the clock the TEE observed at the time it sealed the evidence bundle. Implementations MUST NOT mix wall-clock timestamps with TEE-observed timestamps within a single receipt. Verifiers MUST derive elapsed-time computations from the receipt's own bytes, not from the verifier's local wall clock. 5. SCITT registration and Receipt attachment A Physical-Site Engagement Receipt Signed Statement is registered with a SCITT Transparency Service per [RFC9943] Section 6.3. The TS applies its Registration Policy against the protected header (in particular iss, sub, and content_type) before registering. Upon successful registration, the TS returns a Receipt as defined in [RFC9942]. The Receipt is attached to the Signed Statement's unprotected header as an element of the receipts array (CBOR label 394), producing a SCITT Transparent Statement per [RFC9943] Section 7. The same Signed Statement MAY be registered in multiple Transparency Services and MAY carry multiple attached Receipts, one per Transparency Service, per [RFC9943] Section 6.3. Wilder Expires 30 January 2027 [Page 13] Internet-Draft Physical-Site Engagement Receipt July 2026 6. IANA considerations This document requests the following IANA actions. 6.1. Media type registration Register application/pser+json per [RFC6838], with the required profile parameter and profile value wilder.pser/0.2. 6.2. COSE Header Parameters This document does not register new COSE header parameter labels. It uses only labels defined in [RFC9052], [RFC9597], and [RFC9943]. 6.3. New IANA registries This document requests the establishment of the following registries under a new "SCITT Physical-Site Engagement Receipt Profile" registry group, with policy "Specification Required": 1. _Site Class_ -- values of site.class. Initial values: residential, industrial, healthcare, infra, other. 2. _Engagement Type_ -- values of engagement.type. Initial values: patrol, service, inspection, delivery, installation, maintenance, presence. 3. _TEE Class_ -- values of attestation.teeClass. Initial values: intel.tdx, amd.sev-snp, arm.cca, nvidia.h100-cc, nvidia.jetson- thor-cc, aws.nitro-enclave. 4. _Sealed Evidence Encoding_ -- values of attestation.sealedEvidence.encoding. Initial values: opaque/1. 5. _Operations-Layer System_ -- values of adapter.system. New values follow a vendor.product lowercase snake_case naming convention. 7. Security considerations 7.1. What this profile does NOT attest Per Section 1 and the NORMATIVE non-goals stated there, a Physical- Site Engagement Receipt does NOT attest that: * The engagement was safe, correct, effective, or compliant with any specific regulation. Wilder Expires 30 January 2027 [Page 14] Internet-Draft Physical-Site Engagement Receipt July 2026 * The site conditions were as recorded. * No unrecorded engagement occurred outside the instrumented boundary. * The operations layer targeted by the Adapter Write-In will use, act on, or preserve the receipt correctly. Relying parties MUST NOT infer these claims from a receipt. 7.2. Equivocation and tail-truncation The chain field defined in Section 4 detects _in-band_ tampering and _tail truncation within a presented chain_. It does NOT detect _equivocation_ -- an Issuer signing two divergent chains for the same Subject -- nor _cross-chain tail truncation_. Detection of equivocation and cross-chain tail truncation REQUIRES registration in a SCITT Transparency Service or equivalent external witness. This is unchanged from [I-D.noa-scitt-ai-agent-receipt] Section 5. 7.3. Adapter Write-In is write-only in this revision The Adapter Write-In records that the receipt was posted into an operations layer. It does NOT permit the operations layer to write back into the receipt or the TEE. The adapter.mode field is fixed to WRITE_ONLY in this revision; a future revision MAY define a WRITE_READ mode with additional security machinery. Implementations that reverse this direction in a way that permits the operations layer to modify Issuer or TEE state are NOT conforming to this profile. 7.4. TEE compromise A compromised TEE can produce receipts that are cryptographically valid under this profile but describe engagements that did not occur or did not occur as described. Detection of TEE compromise is out of scope of this profile and depends on the platform-native attestation supply chain identified by attestation.teeClass. Relying parties SHOULD consult [RFC9943] Section 9 for guidance on Issuer participation and key management, and the TEE vendor's own security guidance for the specific teeClass. Wilder Expires 30 January 2027 [Page 15] Internet-Draft Physical-Site Engagement Receipt July 2026 7.5. Three-party trust model The trust model described in this section applies to deployments where the TEE that produces receipts is physically hosted at the Site. In such deployments, the _site owner_ both controls physical access to the TEE hardware and is the party responsible for its continued operation. This profile revision does not address deployments in which the TEE travels with a mobile Actor (for example, a TEE integrated into a mobile robot's compute platform), where the party controlling the attester's physical platform is distinct from the party controlling the Site. Such on-device attester topologies are expected to be addressed in a subsequent revision. The security posture of this profile REQUIRES that three distinct parties participate in every receipt, and that no single party can produce a valid receipt alone: * The _site owner_ physically controls the TEE hardware. They can power it off, unplug it, or refuse to host it, but they CANNOT extract the signing key material or forge signatures with it. The site owner therefore controls whether receipts are produced at all, but not their content. * The _TEE silicon vendor_ provides the hardware root of trust that binds the signing key to a specific attested platform. Detection of a compromised or counterfeit TEE relies on this supply chain and is out of scope of this profile. * The _Issuer_ (typically the operator of a witness service) writes the Statement payload, causes the TEE to sign, registers the resulting Signed Statement with a Transparency Service, and performs the Adapter Write-In. The Issuer CANNOT sign without a live TEE and CANNOT prevent an equivocated chain from being detected once registered. An implementation that collapses two or more of these roles into a single principal (for example, a cloud service that owns the TEE hardware AND signs AND registers with its own Transparency Service) is NOT conforming to this profile, and relying parties MUST NOT treat receipts from such an implementation as offering the trust properties defined here. Wilder Expires 30 January 2027 [Page 16] Internet-Draft Physical-Site Engagement Receipt July 2026 Customer-controlled signing keys held outside a TEE are explicitly WEAKER than the model in this profile and MUST NOT be represented as equivalent. A site owner with direct access to the signing key can backdate, forge, or suppress receipts unilaterally, and no relying party -- insurer, regulator, or counterparty -- can distinguish an authentic receipt from a fabricated one in that setting. 7.6. Identity attribution Identity attribution above the key level -- linking iss, actor.id, and site.id to real-world legal or natural persons -- requires an out-of-band identity manifest. This profile does not specify the identity manifest format. 7.7. Privacy Site identifiers, actor identifiers, and engagement types MAY be sensitive. Issuers SHOULD publish only the digests of envelope documents and internal evidence structures, as this profile requires. Issuers MAY additionally choose to encrypt the Statement payload under a per-relying-party key and publish only the Signed Statement's Receipt to a public Transparency Service, following the guidance in [RFC9943] Section 6.2 for sensitive Statements. 8. Complementary positioning This profile is orthogonal to: * [RFC9943] (SCITT architecture) -- addresses digital supply chains; this profile addresses physical-site engagements. * [I-D.noa-scitt-ai-agent-receipt] -- addresses per-action AI-agent receipts; this profile addresses per-engagement physical receipts. An AI agent that dispatches a physical engagement MAY emit both, correlated via sub. * [I-D.mih-scitt-agent-action-capsule] -- addresses agent-action disposition (executed, blocked, denied, errored); this profile addresses what physically occurred after dispatch and does not carry disposition semantics. This profile does NOT invent a new wire format. A Physical-Site Engagement Receipt is a SCITT Signed Statement (COSE_Sign1) and verifies in any conforming COSE implementation and composes with any SCITT Transparency Service. 9. References Wilder Expires 30 January 2027 [Page 17] Internet-Draft Physical-Site Engagement Receipt July 2026 9.1. Normative References [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024, . [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [I-D.noa-scitt-ai-agent-receipt] Toraman, T., "A SCITT Profile for AI-Agent Action Receipts", Work in Progress, Internet-Draft, draft-noa- scitt-ai-agent-receipt-00, 23 June 2026, . [I-D.mih-scitt-agent-action-capsule] Mih, S., "An Agent Action Capsule Profile for SCITT", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action- Wilder Expires 30 January 2027 [Page 18] Internet-Draft Physical-Site Engagement Receipt July 2026 capsule-02, 6 July 2026, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . Acknowledgments The author thanks the SCITT WG for RFCs 9942 and 9943, and the authors of [I-D.noa-scitt-ai-agent-receipt] and [I-D.mih-scitt-agent-action-capsule] for establishing the SCITT-AI receipt idiom on which this profile builds. Author's Address Rob Wilder Wilder Robotics Email: rob@wilder-robotics.com Wilder Expires 30 January 2027 [Page 19]