Summary

  • draft-sato-soos-pt-03, announced on 5 September 2026, is an active individual Internet-Draft. It has no IETF endorsement or formal standing, RFC stream, responsible Area Director or telechat date.
  • Revision 02 placed ProgressiveTrustSummary in a HEM context but left the signing composition unstated. Revision 03 requires the summary to be a field inside every HEM Escalation Request before the GEC signs it.
  • The new text says a summary delivered outside that signed envelope must not be treated as authoritative by the human principal's interface.
  • pt_summary_hash remains a SHA-256 digest of canonical JSON, but PT-03 calls it an aid for verification after extraction. Authenticity at decision time comes from the enclosing request's kernel_signature.
  • A small joined receipt should retain the request identity, signed preimage, signer and key, verification result, embedded-summary path, extracted hash and relay history. That is Daniel Kade's recommendation, not an IETF requirement.

A believable score can belong to the wrong decision

The 5 September announcement presents Progressive Trust as a way to turn an AI agent's history across sessions into structured recommendations about future authority. The Datatracker record identifies Tom Sato's revision 03 as an active individual Internet-Draft. That status is deliberately modest: Datatracker says it is not endorsed by the IETF and has no formal standing. It has no RFC stream, responsible Area Director or telechat date. “Standards Track” in the header is the author's intended destination, not a result already achieved.

The draft measures five dimensions: calibration of self-assessment, judgment about when to seek human help, effectiveness, precision and adaptation after denial. A ProgressiveTrustSummary packages those dimensions, a composite presentation, trends, session counts, active recommendations and a pt_summary_hash. The summary is supposed to reach a human at the moment an agent escalates a decision.

That moment creates a binding problem. A score of 0.88 is not meaningful on its own. It must belong to the right agent, at the right computation time, inside the right escalation, beside the right trigger and available options. If a relay, interface cache or audit extractor can detach the summary and present it next to a different request, the numbers may remain internally consistent while the decision context is false.

Revision 03 addresses that exact problem. Its change is not a new trust dimension or a new threshold. It is a rule about which object has to be authenticated.

Revision 02 named a container without closing it

The frozen revision 02 required the GEC to include a summary in every HEMContext delivered at escalation. It also required computation at invocation and retained the digest. What it did not say was that the summary had to be composed into the signed escalation request before the signature was created.

The official comparison makes the correction visible. Revision 03 replaces the generic context wording with an explicit field inside each HEM Escalation Request. It orders the GEC to compose that field into the request before signing under HEM Section 18.8. It then adds a rejection rule: a summary arriving outside the enclosing request's signed envelope is not authoritative for the recipient's interface.

The draft says this corrects an issue identified by a WIMSE Security Review. I found no separately archived copy of that review in the public-source search, so the attribution cannot be extended beyond the draft's own statement. The verifiable event is the text change itself.

This is a useful form of specification repair because it names both order and boundary. “Include a summary” can be implemented as a side panel fetched after the request. “Compose it before signing” cannot. The latter requires the signer to commit to the summary and the rest of the request in one verifiable act.

The digest and the signature answer different questions

PT-03 retains pt_summary_hash, described as SHA-256 of canonical JSON. The new paragraph carefully limits its job: it is convenient for independent re-verification after the summary has been extracted, for example during audit. It is not what authenticates the summary to the human receiving the escalation.

A digest answers an equality question. Given a specified canonical representation, does this extracted object produce the recorded value? RFC 8785 explains why deterministic JSON representation matters for repeatable hashing and signing. But a bare digest does not say who selected the object, which escalation carried it, which principal was addressed or whether the recipient saw it before deciding. Anyone able to replace an unauthenticated object can ordinarily calculate a new digest for the replacement.

The enclosing signature answers a provenance-and-integrity question under the draft's assumptions. HEM revision 07 says the GEC signs the full HEM Escalation Request with Ed25519; kernel_signature covers the canonical serialization of every other field. HEM-07 also describes progressive_trust_summary as a required request field. A verifier that receives the whole object can therefore test one joined claim: this signer committed to this trust summary as part of this escalation request.

That does not turn the signature into truth. The underlying events may be incomplete, a computation may be defective, a key may be compromised, or a human may make a poor decision. The correction makes alteration and mispairing detectable. It does not certify the quality of the world represented by the fields.

Authentication must precede presentation

The order matters operationally. An interface should first verify the enclosing request, including the summary field, request identity and relevant key. Only then should it render scores, trends or plain-language explanations. Extracting the summary first, verifying only its digest and later attaching it to a request reverses the trust boundary.

The same rule applies to intermediaries. HEM-07 says delivery components capable of verifying the kernel signature must not forward a request whose check fails. A relay may transport or display the request, but it cannot become the source of authority by reassembling trusted-looking parts. If it transforms the representation, it needs to preserve the signed preimage or a faithful verification record rather than imply that a newly assembled screen is the original signed object.

PT also preserves the human boundary. The summary is informational. A principal may approve despite a low score or terminate despite a high one. The score does not vote and the GEC does not replace the person. Binding the summary into the request therefore does not automate the decision; it makes the evidence presented for that decision attributable.

This distinction is especially important because the broader draft discusses recommendations that can affect mandate ceilings. A trustworthy interface cannot let a numerical history acquire authority merely by appearing beside an approval control. Authority comes from the human's role and signed decision path; the summary informs that path.

One receipt should keep the join intact

An implementation should preserve a joined verification receipt. This is my editorial recommendation, not language imposed by PT or HEM. The receipt should identify hem_id, the exact request version, canonical preimage or retained signed bytes, kernel_signature, signer and key identifier, verification time and result. It should also record where the summary occurred in the request, its computation time, the digest recalculated after extraction and any transformations made by relays or interfaces.

The negative tests are more revealing than a successful screen. A valid summary beside the wrong hem_id must fail. A changed score with the old digest must fail. A changed summary with a freshly recalculated digest but no valid enclosing signature must fail. A validly signed request displayed after a relay silently substitutes the human-readable explanation must fail presentation-equivalence review. An unknown key or expired verification policy must remain unresolved rather than becoming a green score card.

Heng Lu's Running-Code Primacy supplies the reading discipline: publication is not operational reality; the relevant rule is the one independent implementations can validate locally. His Minimum Initial Specification suggests keeping the common layer thin. Here the thin rule is enough: one request, one enclosing signature, one preserved verification path. These essays are an analytical lens, not evidence that PT is deployed or endorsed.

A correction in a draft, not a deployed security result

The correction is concrete, but the evidence ceiling remains low. Neither the PT nor HEM Datatracker entry demonstrates an implementation, an interoperability test, a production deployment, a compromised relay, an exploit or a resolved incident. Both are individual drafts that may change, expire or never enter an RFC stream.

The fair news is therefore precise. PT-03 now identifies the signed object that carries its human-facing trust evidence and demotes the summary hash to its proper audit role. It does not prove that an operating product enforces that boundary. The next meaningful evidence will come from independent implementations that reject the wrong pairings and preserve a replayable receipt—not from a larger number of references to trust.

Sources

  1. IETF announcement: draft-sato-soos-pt-03
  2. IETF Datatracker: Progressive Trust
  3. IETF archive: PT revision 03
  4. IETF archive: PT revision 02
  5. IETF Author Tools: PT-02 to PT-03 comparison
  6. IETF archive: HEM revision 07
  7. IETF Datatracker: Human Escalation Mechanism
  8. RFC 8785: JSON Canonicalization Scheme
  9. Heng Lu: Running-Code Primacy
  10. Heng Lu: Minimum Initial Specification
  11. Heng Lu: Reality, Not Advocacy