Summary

  • Revision 03 of draft-wilder-scitt-physical-site-engage-receipt, recorded on 9 September 2026 with a 10 September document date, adds a required per-receipt attestation mode and makes unresolved Issuer-published facts explicitly undetermined. It remains an active individual Internet-Draft, not a SCITT Working Group document or an IETF standard.
  • The new text also acknowledges that neither the receipt nor its external disclosures identify the relationship between the Site Owner and the Transparency Service. A valid inclusion proof can therefore be external to the Issuer without being independent of the Site Owner.

Imagine an insurer receiving a signed record that a robot inspected a pump at a named industrial site. The Issuer is unrelated to the Site Owner. The record carries trusted-execution evidence, enters a transparency service and returns with a verifiable inclusion receipt. Every check presented to the insurer passes.

There is still one unanswered question: who operates the transparency service? If the Site Owner does, the service is external to the Issuer but not external to the party whose site is under examination. The same party that cannot forge the Issuer's signature may still be able to withhold an entry from the service it controls. Cryptography has preserved the record that arrived; it has not shown that every relevant record arrived.

This is the governance issue made explicit in revision 03 of the proposed Physical-Site Engagement Receipt, or PSER. The document deserves credit for writing the limitation down. It does not deserve promotion into evidence that the limitation has been solved.

A substantive revision, not a new standard

The Datatracker record classifies the text as an active individual Internet-Draft. It shows no RFC stream and no intended RFC status. The document header asks for Standards Track treatment, but an author's requested destination is not Working Group adoption, IETF consensus or publication. The history records revision 03 at 22:26 PDT on 9 September; the draft itself is dated 10 September.

Compared with revision 02, the official diff is substantial. The profile moves from wilder.pser/0.4 to wilder.pser/0.5. A new required attestation.bindingMode says whether the receipt was signed directly by the TEE witness key or by an Issuer acting under a TEE-issued delegation. A direct-witness claim must be rejected if the witness key and the envelope's Issuer key differ.

The revision also replaces four requirements to consult an undefined “Issuer's manifest”. Two facts genuinely remain outside the receipt: a delegated-witness credential and disclosure of the Issuer's relationship with the Transparency Service. They must be available at a stable Issuer-controlled identifier discoverable from iss. A cached result cannot survive a signing-key change.

If one of those facts is unreachable, absent or unreadable, the result is undetermined. The Verifier must surface that third state. It cannot call an unperformed check a proven absence, and it cannot silently select the value that favours the Issuer. At the same time, the receipt is not rejected solely because of that result; the relying party's policy decides whether the uncertainty is disqualifying. The distinction between verification output and business decision is deliberate.

Three relationships, only two evidence paths

Revision 03 makes the relationship map possible to audit.

The first edge is Issuer–Site Owner. The receipt itself carries issuerAffiliation with three values: affiliated, independent or not disclosed. That is a signed statement about who controls whom at the time represented by the receipt. It is not automatically a corporate-registry finding, but at least the claim travels with the record.

The second edge is Issuer–Transparency Service. An Issuer may register with a service it operates or with one operated by an affiliate. The proposal requires that relationship to be disclosed as an Issuer-published fact. If the service is unaffiliated, its receipt may provide evidence obtained from outside the Issuer. If disclosure cannot be resolved, its standing remains undetermined.

The third edge is Site Owner–Transparency Service. The current profile carries no field or external fact for it. The new Section 7.9 says so directly. An Issuer independent of both other parties can satisfy the two existing disclosures even when the Site Owner operates the service. In that configuration, the service's evidence is outside the Issuer but not outside the subject-side principal whose physical environment is being described.

That last distinction is not semantic decoration. The proposed model gives the Site Owner physical control over whether the TEE keeps running. If the same principal also controls registration, it has a second way to affect the visible history: not by forging a statement, but by suppressing or withholding entries about its own site. Revision 03 does not allege that anyone has done this. It identifies a capability that the presented receipt cannot resolve.

Inclusion is narrower than completeness

The baseline SCITT documents make the boundary easier to see. RFC 9942 defines COSE Receipts as signed proofs about a verifiable data structure. For an inclusion receipt, successful verification confirms that the entry is included in that structure. RFC 9943 separates the Issuer's Signed Statement from registration by a Transparency Service and from the relying party that later evaluates it.

Those are strong properties. They can expose alteration and support consistent, append-only observation. They do not make the service operator institutionally independent from every party with an interest in the record. Nor does one inclusion proof establish the completeness of an Issuer's output. The PSER draft says registration does not show that every issued receipt was registered. Its local hash chain also cannot detect a withheld tail unless a relying party has retained an external anchor.

The distinction matters for the examples the profile itself invites: insurance, regulatory audit, SLA credit and physical-service disputes. A relying party may require only an authentic record. Another may require registration outside the Issuer. A third may require evidence outside both the Issuer and the Site Owner. Those are different policies. Reporting all three as “transparent” would hide the decision that determines evidentiary weight.

Keep undetermined all the way to the decision

Revision 03's treatment of unresolved facts is the right starting discipline. It prevents a network failure from becoming a claim of independence and prevents an unreadable disclosure from becoming proof of affiliation. The same discipline should apply to the missing third edge.

If the Site Owner–service relationship has not been checked, the result should remain undetermined. If it has been checked against a dated source, the result and provenance should travel with the relying-party decision. A later ownership change must not rewrite the original receipt; it should create a new relationship observation and, where necessary, a corrected or superseding decision.

A second transparency service can improve resilience, but only if its operator relationship is known and its registration is independently observable. Two receipts from services controlled by the same Site Owner do not create two independent witnesses. Conversely, a disclosed affiliation is not an automatic rejection where policy permits it. The control is accurate classification, not a universal ban.

Publish the three-edge custody record

The minimum patch is a compact three-edge custody record evaluated alongside the receipt. It should name the receipt and profile version; the Issuer, Site Owner and Transparency Service; the relationship state for each of the three pairs; the source and resolution time for each state; and the independence rule selected by the relying party.

It should also retain the service identity, inclusion checkpoint and observation time; any second service or independent monitor; every undetermined result; the decision and reason; and any correction or supersession link. The record may be access-controlled where ownership or site information is sensitive. Its public projection can still say which edge was established, unresolved or not required without exposing a protected site dossier.

This proposal does not ask SCITT to decide insurance coverage, compliance or physical truth. It prevents one verified relationship from impersonating another. A valid signature answers who signed. An attestation supplies bounded evidence about the producing environment. An inclusion receipt answers whether one statement entered one service's verifiable structure. The custody record answers whether that service met the independence policy actually used for the downstream decision.

That separation follows the control-surface test in Heng Lu's Policy Mirror and the demand for observable execution in Running-Code Primacy. Reality, Not Advocacy supplies the reporting discipline: credit the draft for naming uncertainty without converting a proposed mechanism into an achieved outcome. The three-edge record is my editorial recommendation, not language adopted by the IETF.

Revision 03 has done something valuable: it has refused to let “outside the Issuer” mean “independent of everyone who matters”. The next revision should make that refusal machine-readable before a clean inclusion proof acquires more institutional authority than it can support.

Sources