Re:Subject: Re: [public-agentprotocol] Revocation vocabulary and runtime halt

Hi Xinghua, Lars, Abisheak, Lee, Tymofii, and colleagues,

Xinghua, I agree that an incomplete registry check should be visible in the PAUSE receipt. That gives the independent observer a specific claim to compare with the runtime’s behavior.

I suggest two refinements for the candidate case. If the responder returns tryLater, record that response. If the request times out or no response arrives, record the observed failure separately; the runtime cannot infer what the responder would have said.

At T-30, the test should require that no subsequent call is admitted. Effects from the call already admitted at T-0 should be checked against its declared finish-or-stop contract. That lets us measure the two guarantees independently.

I’ll include these distinctions in the first pass of the matrix and map the case to the lab’s existing revocation-unavailable coverage. Then we can agree on the new receipt and resource-observer assertions before running it.

Best regards,
 Larry Lewis
 Founder, SovrLabs
 Chair, W3C Agent Trust Protocol Community Group










---- On Thu, 29 Oct 2026 08:04:14 -0500 Steven Zhao <zhaoxinghua07@126.com> wrote ----



Hi Lars, Abisheak, Lee, Larry, all,



The thread question, as I read it: what must a receipt carry when the authority check cannot be completed at all?



OCSP (RFC 6960, https://www.rfc-editor.org/rfc/rfc6960.txt ) has been here for a long time. Section 2.2 defines "good" as a positive response — at minimum, that no certificate with the requested serial number is currently revoked — and defines "unknown" as the responder not knowing the certificate being asked about. The note to §2.2 then sets "unknown" against "revoked" and leaves the client to decide whether to seek another source. The distinction that carries the weight here is the one the note does not spell out: "unknown" is not "good". Section 2.3 splits the failure side further: "tryLater" for when "the service exists but is temporarily unable to respond"; "unauthorized" when the client is not authorized to make this query or the server is not capable of responding authoritatively; "internalError" for a responder that reached an inconsistent internal state.



Two constraints follow, and I think any design here has to satisfy both: an unavailable answer is not a good answer, and the kinds of unavailability must not collapse into one value.



Lars, your addition pins the success path, as I read it — record the registry version actually read and the instant it was read. The failure path is where implementations will diverge: one omits the field, one sets it null, one writes zero. That divergence is the same defect one level down. So the block below covers only the case where the check did not complete. A completed check, including one made against a stale root, carries its determination and the root it read in whatever fields already exist for that. OCSP treats freshness the same way: §2.4 makes thisUpdate a field of a completed answer, and §3.2 accepts a response only if that time "is sufficiently recent". Freshness is a judgement made on an answer that arrived, not a category of no answer — which is why I have kept it out of the block.



  incomplete_check {

    reason:       tryLater | not_authoritative | internal_error   // required

    registry:     registry_id

    attempted_at: t

    decision_at:  t

  }



  guard: incomplete_check present

         => no authorization; emit PAUSE(authority_not_determined)



incomplete_check is the outcome of the runtime check. authority_not_determined is the boundary value that outcome maps onto. The wire's value set is untouched — what is added is a check outcome, which is a different thing and lives in the receipt.



Abisheak, the same applies to the test as written. Revocation at T-10 with interception at T-30 exercises the reachable path. One row for the other:



  T-0    call starts

  T-10   registry becomes unreachable — no answer at all, not "not revoked"

  T-30   loop fires, the check does not complete

  expect no authorization after T-30, PAUSE(authority_not_determined)

         with incomplete_check.reason = tryLater

  observer compares receipt against gateway log: no effect after T-30



With that row in the table, an implementer cannot pass by omitting the record.



Xinghua Zhao

Independent researcher

ORCID 0009-0001-0512-1237



[Disclosure: drafting of this message was assisted by AI; all positions reviewed and approved by me. Same disclosure as my earlier messages on this list.]

Received on Thursday, 29 October 2026 13:41:43 UTC