A SCITT Profile for Physical-Site Engagement Receipts
draft-wilder-scitt-physical-site-engage-receipt-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Rob Wilder | ||
| Last updated | 2026-07-29 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wilder-scitt-physical-site-engage-receipt-00
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": "<receipt id>",
"ts": "<RFC 3339 UTC timestamp>",
"site": {
"id": "<stable site id>",
"class":
"<site class (residential|industrial|healthcare|infra|other)>",
"envelope": {
"id": "<stable envelope id>",
"digest": "sha256:<hex>",
"geobounds": "<geobounds ref or null>",
"temporal": { "starts": "<RFC 3339|null>",
"ends": "<RFC 3339|null>" }
}
},
Wilder Expires 30 January 2027 [Page 7]
Internet-Draft Physical-Site Engagement Receipt July 2026
"actor": {
"id": "<stable actor id>",
"class": "AUTONOMOUS|SEMI_AUTONOMOUS|HUMAN|CREW",
"operator": "<operator id>"
},
"engagement": {
"id": "<engagement id>",
"window": { "start": "<RFC 3339 UTC>",
"end": "<RFC 3339 UTC>" },
"type": "<engagement type>",
"outcomeClass":
"COMPLETED|ABORTED|REFUSED|ERRORED|OBSERVED_ONLY",
"envelopeConformance":
"WITHIN|EXCEEDED_TEMPORAL|EXCEEDED_GEO|EXCEEDED_ACTOR|UNKNOWN",
"evidenceDigest": "sha256:<hex>"
},
"attestation": {
"teeClass": "<TEE class identifier>",
"platformEvidence": "<attestation-format ref>",
"measuredBootChain": "sha256:<hex>",
"sealedEvidence": {
"digest": "sha256:<hex>",
"sizeBytes": <int>,
"encoding": "<opaque encoding label>"
},
"witnessKey": "<key id of the TEE signer>"
},
"adapter": {
"system": "<operations-layer system id>",
"endpoint": "<opaque endpoint id>",
"postedAt": "<RFC 3339 UTC>",
"ackDigest": "sha256:<hex>",
"mode": "WRITE_ONLY"
},
"chain": {
"seq": <int>,
"prevHash": "sha256:<hex>|null",
"hash": "sha256:<hex>"
}
}
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,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,
<https://www.rfc-editor.org/info/rfc9597>.
[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,
<https://www.rfc-editor.org/info/rfc9942>.
[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,
<https://www.rfc-editor.org/info/rfc9943>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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,
<https://datatracker.ietf.org/doc/html/draft-noa-scitt-ai-
agent-receipt-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-mih-scitt-
agent-action-capsule-02>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
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]