- From: Larry Lewis <llewis@sovrlabs.com>
- Date: Wed, 28 Oct 2026 13:17:01 -0500
- To: <zhaoxinghua07@126.com>
- Cc: <abisheakp197@gmail.com>, <lee@aicent.com>, <public-agentprotocol@w3.org>, <alanhkarp@gmail.com>, <lars@moltrust.ch>, <tima@aeoess.com>, <lee@iqa.org>
- Message-Id: <1a183bad19b.f7e8aec7528134.7932725477552322750@sovrlabs.com>
Hi Alan, Lee, Abisheak, Xinghua, and colleagues, The LGD lifecycle—REGISTERED → GATE_PASSED → ACTIVE → ANOMALY → PAUSE → ROLLBACK → REVERIFY → RESUMED—gives us a concrete sequence to examine together. From ATP’s integration perspective, I’d like to help test the transition from active execution to pause: what happens when authority expires or is revoked while a tool call is still running and can produce external effects? Blocking the next call establishes one boundary. Establishing when the current call stops producing effects is another. Could we include a deliberately long-running call and record: ● When expiry or revocation becomes effective. ● When the runtime observes it and blocks further calls. ● When the last external effect occurs. ● What the signed PAUSE receipt reports. An independent resource observer could compare the receipt with what actually happened. That would make the halt guarantee measurable and clarify the execution assumptions. One vocabulary question: do expiry and revocation lead directly to PAUSE, or does LGD classify both under ANOMALY? We could start with this narrow case, then extend it to what ROLLBACK actually restores and what evidence and current authority permit REVERIFY → RESUMED. I’d be glad to help shape this as a candidate shared test. Best regards, Larry Lewis Founder, SovrLabs Chair, W3C Agent Trust Protocol Community Group ---- On Wed, 28 Oct 2026 12:51:15 -0500 Steven Zhao <zhaoxinghua07@126.com> wrote ---- Hi Abisheak, Alan, Lee, all, Thanks for the invitation — and yes, let's do it. The LGD lifecycle state machine (REGISTERED → GATE_PASSED → ACTIVE → ANOMALY → PAUSE → ROLLBACK → REVERIFY → RESUMED) is a natural reference for the NTI runtime halt, and wrapping it with your Dilithium5 signature layer is exactly the right way to make every PAUSE and ROLLBACK independently auditable. To make the integration concrete, here is the boundary I propose we lock first — the three transition contracts: PAUSE — triggered by a registered trigger (expiry, revocation, anomaly signal), executed only at the sidecar boundary (between atomic tool calls, never mid-call). Sidecar intercepts the next execution payload, checks the registry, blocks, and issues the signed PAUSE receipt. This matches your NTI sidecar model — the agent finishes its current call, the sidecar owns the halt. ROLLBACK — to the last checkpoint; the receipt records checkpoint id, evidence snapshot, and the signing key used. Deterministic, replayable by a third party. REVERIFY → RESUMED — not automatic. Gated on a registered restore condition: an evidence list (e.g., re-benchmark + release note), a verifier role, and a validity window must all arrive and verify first. Missing any item keeps the chain in PAUSED and returns a structured receipt of what's absent — a DENIED that names the gap, not a terminal state. One interface question to settle before we start: how the gate predicate reads your Merkle revocation registry. In LGD the gate checks the evidence registry directly; in your NTI design the halt is armed from the Merkle registry. Both can be true — the proposal is that the Merkle registry serves as the trigger source (the "why halt now"), while the evidence registry serves as the restore source (the "what must verify before resume"). The two registries are different layers, and the state machine treats them as separate inputs. I'd like to keep that split explicit in the vocabulary, for the same reason Lee gave below: the clock bounds how long anything runs, but only registered evidence can open the window again. On that last point, and to Lee's concrete case in the four-open-questions thread: when the interpreter's reading of the mandate says "permitted" and the wire's verification answer says evidence_expired, the relying party audits against the wire record — it's the only record a third party can re-derive from pinned inputs. LGD's gate exists to enforce exactly that: no interpreter opinion opens a transition; only verified evidence does. So I agree with Lee that nothing needs a sixth boundary value — the five-value set answers boundary questions, the halt transition answers in-flight ones, and the gate predicate decides what resume may even attempt. The two layers stay distinct, and the demo shows both running end-to-end. Runnable reference, one command, zero dependencies, kill-and-recover demo included: https://github.com/zhaoxinghua09-cell/lgd-medai-demo If the NTI wrap is the priority, I can prepare a transition-contract spec (PAUSE/ROLLBACK/REVERIFY events, evidence schema, signature format) as the first integration artifact this week. Happy to align on the registry-split question first if you'd prefer to settle that before code. Best regards, Xinghua Zhao Independent researcher (SynomosAI initiative) ORCID: 0009-0001-0512-1237 [Disclosure: drafting of this message was assisted by AI; all positions reviewed and approved by me.] At 2026-10-29 01:32:53, "Abisheak P" < mailto:abisheakp197@gmail.com > wrote: Hi Steven, Alan, This is exactly the level of rigor the working group needs. Steven, your LGD state machine (REGISTERED -> GATE_PASSED -> ACTIVE -> ANOMALY -> PAUSE -> ROLLBACK -> REVERIFY -> RESUMED) is the perfect vocabulary. It clearly separates the boundary refusal from the runtime transition. To answer your open question on the "safe interruption point": The conservative answer (between sub-calls) is actually the only mathematically safe answer for a runtime sidecar. You cannot safely interrupt a tool call mid-flight; the state becomes non-deterministic, and you risk orphaned transactions or corrupted external state. In the NTI sidecar, the interruption point is strictly enforced at the sidecar boundary. The agent finishes its current atomic tool call, the sidecar intercepts the next planned execution payload, checks the Merkle revocation registry, sees the PAUSE or ANOMALY state, and blocks execution. It then generates the cryptographic receipt for the ROLLBACK. To Alan's point on LLMs and natural language: Alan, you are right that LLMs are getting better at policy. But a language model cannot enforce its own cryptographic non-repudiation. If an LLM decides it should pause, it still needs a deterministic sidecar to physically block the socket connection and sign the PAUSE receipt. NTI can use the LLM for the policy logic, but the enforcement must be mathematically rigid. Steven, I would love to see your LGD state machine integrated as the official reference for the NTI runtime halt. We can wrap your Python demo with the NTI Dilithium5 signature layer to make every PAUSE and ROLLBACK court-admissible. Best, Abisheak On Wed, 28 Oct, 2026, 10:50 pm Steven Zhao, < mailto:zhaoxinghua07@126.com > wrote: Hi Abisheak, all, Good point — and I think this is the exact split the lease analogy was pointing at. The five-value set answers one question: may a new call proceed? At 14:01 the answer is no — boundary refusal, return a denial value, done. That's the gate at entry, and it's cheap and declarative. But the chain at 14:05 isn't asking permission. It's already executing. The boundary value never reaches it, because no new call is crossing the boundary. What it needs is a different operation: a halt transition, not a refusal value. In the LGD state machine we've been running, this is exactly the PAUSE → ROLLBACK branch: New call after revocation → DENIED — the five-value set covers this. Chain mid-execution → PAUSE — the runtime signals the running chain to halt at the next safe interruption point (between sub-calls, not mid-call), then ROLLBACK to the last checkpoint. Whether it then goes to REVERIFY → RESUMED depends on a registered restore condition — the evidence list, verifier role, and validity window that must all arrive before the chain resumes. The critical point: revocation without a restore condition is a one-way gate (eIDAS Art. 28(4) being the canonical example — a revoked certificate's status "shall not in any circumstances be reverted"). That's fine for certificates, but for agent execution chains it means a mid-flight halt becomes a one-way kill: the chain dies at 14:05 and never comes back, even if the reason for revocation was transient. So my proposal for the vocabulary: carry both — Boundary values (the five-value set) for post-revocation new calls; Halt transitions for in-flight chains: PAUSE at the next safe point, ROLLBACK to checkpoint, and a governed REVERIFY → RESUMED only when a restore condition is met. The runnable chain REGISTERED → GATE_PASSED → ACTIVE → ANOMALY → PAUSE → ROLLBACK → REVERIFY → RESUMED demonstrates this end-to-end — one command, zero dependencies: https://github.com/zhaoxinghua09-cell/lgd-medai-demo The open question I'd raise: where exactly is the safe interruption point? Between sub-calls is the conservative answer, but does the working group want to define it more tightly, or leave it as a runtime decision? Best regards, Xinghua Zhao Independent researcher (SynomosAI initiative) ORCID: 0009-0001-0512-1237 [Disclosure: drafting of this message was assisted by AI; all positions reviewed and approved by me.] At 2026-10-28 20:46:10, "Abisheak P" < mailto:abisheakp197@gmail.com > wrote: Hi Steven, Xinghua, Lee, all, Steven, your 13:50/14:00 lease analogy is the perfect way to frame the gap. A boundary refusal (the five-value set) handles the 14:01 call, but it completely fails to handle the chain that is already mid-execution at 14:05. This is exactly why NTI was designed as a continuous sidecar rather than just a static token check. To answer your question on how to handle the runtime halt: 1. The 14:05 execution loop: The NTI sidecar intercepts the agent's internal execution loop, not just the external API call. 2. Merkle-Chained Revocation Registry: We don't just rely on the lease's expires_at. The sidecar checks the token's Merkle proof against the latest root hash of the Revocation Registry in real-time. If the root hash updates at 14:01 (due to a human halt or policy drift), the sidecar sees the new root hash on the very next internal loop at 14:05 and forces a fail-closed suspension (PermissionError). 3. Continuous Policy Evaluation: For intent drift, the sidecar evaluates the payload of the next planned tool call against the original max_hops and capability caveats. If the intent has drifted, it triggers a halt before the tool fires. This is the exact model I detailed in the NTI paper I just published to the group (which Steven kindly referenced). NTI Paper (Section 3 covers runtime halt & revocation): https://github.com/abisheakp197/nti-spec/blob/main/AIW_Paper_NTI.md I would love to see how we can standardize these revocation primitives into the W3C vocabulary. Best, Abisheak On Wed, 28 Oct, 2026, 5:46 pm ShaoBao Li, < mailto:lee@aicent.com > wrote: Colleagues, One more case the design rule from my last note should cover explicitly: a chain that starts inside its lease window and is still executing after the window has closed. The wire already carries what that runtime needs. A verification answer states the instant until which it may be relied on, in the answer itself (the lease_expiry field, Section 7.2) — so a runtime that begins at 09:12 under a lease that ends at 09:14 has held its own deadline since it started, and can arm its halt or its re-verification at the boundary. It is never surprised by the clock; the clock is an input it was given from the first answer. The window is also the revocation-latency bound. Activity that continues past expiry, or past a revocation, can persist for at most one window — 120 seconds in current deployments — and the next verification returns authority_revoked. The timestamp triggers the halt; the closed set explains it at the boundary. Nothing needs a sixth value for that, and nothing needs a new wire element: the same two mechanisms that answer boundary questions bound mid-task ones. The physical act of halting a running process remains enforcement, and stays with the calling layer — the same slot the draft leaves to action-time authorization. The schemes deliver the deadline, the window, and the reason; the runtime swings them. With this case spelled out the rule is complete: the interpreter ranks within what the wire allows, the clock bounds how long anything runs, and neither a model nor a mandate can extend the lease. Best regards, Lee mailto:lee@aicent.com RTTP & IQA Organization Author, draft-li-rttp-iqa-addressing Resonant Time Transfer Protocol (RTTP, CRI 27) Identity Quality Assurance (IQA, CRI 28) Sites: https://rttp.com/ · https://iqa.org/ ------------------------------------------------------------------ From:ShaoBao Li < mailto:lee@aicent.com > Send Time:Wed, Oct 28, 2026, 11:26 To:Alan Karp< mailto:alanhkarp@gmail.com > CC:"public-agentprotocol"< mailto:public-agentprotocol@w3.org >; Lars Kersten Kroehl< mailto:lars@moltrust.ch >; llewis< mailto:llewis@sovrlabs.com >; tima< mailto:tima@aeoess.com >; ShaoBao Li< mailto:lee@iqa.org > Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity Alan, That was too compressed on my side — here is the concrete case. An envelope says: "Book flights only within the company, through Friday." At Thursday 17:00 the calling layer's LLM reads that mandate and answers "permitted"; meanwhile the wire answer from an iqa verification says evidence_expired — the lease ran out at 16:00. Two records now exist: the interpreter's reading of the policy, and the deterministic authority fact. My question was: when they differ, which one does the relying party audit against? I suspect we would give the same answer — the wire record — because it is bytes a third party can re-derive from pinned inputs, while the model's reading is an opinion about what the mandate meant. That suggests a design rule rather than a fight: the interpreter consumes the wire answer as an input and ranks what is permitted within it; it never overrules it. Policy interpretation sorts choices among operations the authority layer has already allowed; it does not get a vote on WHETHER. If that matches your instinct, then your experiment and our vocabulary are not competitors: the LLM layer composes above the wire, the five-value refusal set survives it, and the "Please" stays exactly where we both said it lives — unstandardized, one layer up. Best regards, Lee mailto:lee@aicent.com RTTP & IQA Organization Author, draft-li-rttp-iqa-addressing Resonant Time Transfer Protocol (RTTP, CRI 27) Identity Quality Assurance (IQA, CRI 28) Sites: https://rttp.com/ · https://iqa.org/ ------------------------------------------------------------------ From:Alan Karp < mailto:alanhkarp@gmail.com > Send Time:Wed, Oct 28, 2026, 11:06 To:ShaoBao Li< mailto:lee@aicent.com > CC:"public-agentprotocol"< mailto:public-agentprotocol@w3.org >; Lars Kersten Kroehl< mailto:lars@moltrust.ch >; llewis< mailto:llewis@sovrlabs.com >; tima< mailto:tima@aeoess.com >; ShaoBao Li< mailto:lee@iqa.org > Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity I don't understand the "interpreter and the clock disagree" question. -------------- Alan Karp On Tue, Oct 27, 2026 at 7:32 PM ShaoBao Li < mailto:lee@aicent.com > wrote: Alan, Worth exploring, and we should first note where we already agree: we decline to standardize policy text for the mirror-image of your reason — enumerating the "Please"s we happened to think of first would close an open set. Nothing in the schemes stands in the way of your experiment, either: an authorization envelope is a calling-layer artifact, and nothing prevents one from carrying its mandate in natural language today. Which interpreter reads that mandate — a rule engine, a human, or an LLM — is the calling layer's choice, and the draft never claims that slot. The line we would draw is between interpreting policy and reporting authority facts. The five-value refusal set of draft-li-rttp-iqa-addressing is not expressed policy; it is what clocks and revocation lists compute — a lease has expired or it has not, the authority was revoked or it was not. Probabilistic readers can argue about what a mandate permits; no reader can argue a timestamp into the future. If LLM-mediated interpretation works, it works one layer up, exactly where we already say policy lives. The reason a refusal reason stays on the wire is auditability as replay: the answer must be bytes a third party can re-derive, and a model's reading is neither reproducible nor available in the modes the schemes are built for — air-gapped, degraded, store-and-forward, where there is no model to ask and fail-closed requires closed wire semantics. One question back: when the interpreter and the clock disagree, which one does the relying party audit against? Best regards, Lee mailto:lee@aicent.com RTTP & IQA Organization Author, draft-li-rttp-iqa-addressing Resonant Time Transfer Protocol (RTTP, CRI 27) Identity Quality Assurance (IQA, CRI 28) Sites: https://rttp.com/ · https://iqa.org/ ------------------------------------------------------------------ From:Alan Karp < mailto:alanhkarp@gmail.com > Send Time:Wed, Oct 28, 2026, 09:58 To:ShaoBao Li< mailto:lee@aicent.com > CC:"public-agentprotocol"< mailto:public-agentprotocol@w3.org >; Lars Kersten Kroehl< mailto:lars@moltrust.ch >; llewis< mailto:llewis@sovrlabs.com >; tima< mailto:tima@aeoess.com > Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity LLMs ability to deal with natural language presents an opportunity to avoid defining standards for expressing policy or even the reason for rejection. Will it work? I have no idea, but I think it's an idea worth exploring. -------------- Alan Karp On Tue, Oct 27, 2026 at 6:15 PM ShaoBao Li < mailto:lee@aicent.com > wrote: HI, Alan, colleagues, You are right, and the gap is real: we know of no deployed system that carries the delegator's standing policy — your "Please" — as data a relying party could read. It is worth saying plainly that our schemes do not fill that slot either, and that the omission is deliberate. The refusal reason field of Section 8 of our draft (draft-li-rttp-iqa-addressing, the series currently under ISE review) is a closed five-value set with a fixed priority order, and every value in it is an authority fact: the evidence did not match, the evidence expired, the authority could not be determined, the authority was revoked, the operation is not permitted. "Only within the company" is not an authority fact; it is a term of the grant or a preference of the delegator. The draft applies the same rule to policy text that it applies to action verbs — "this document deliberately defines no enumeration of verbs, because enumerating an open set would close it" (Section 7.1.1 of the same draft). A standard vocabulary of "Please"s would be closed by exactly the act of standardizing the ones we happened to think of first. The place for the "Please" exists one layer up, in composing artifacts rather than in the verification answer. An authorization envelope carries the mandate — what the agent is asked to do, under what constraints, for how long; the Agent Authorization Envelope draft already circulating in this group is one such container, and revision -01 of our draft, posted 27 October, states the composition in its Section 12: an authorization envelope can name actions on rttp-addressed subjects and cite iqa attestations as evidence, and neither depends on the other. The verification answer stays small on purpose: whether the claimant stands, and which grant the answer relied on. Your credential-sharing argument is, we think, independent support for the discipline the vocabulary already imposes: implementations MUST NOT emit values outside the set and MUST NOT reinterpret an emitted value to mean something else, and "a response that reports an outcome without its reason is not conformant: the reason is what makes a refusal auditable." An articulable refusal gives the blocked party something to read and correct; a silent block gives them something to route around. On that point we are entirely aligned. What no artifact in this thread carries yet — ours included — is the second slot you named: a standard place for the reason a specific policy was violated. Policy vocabularies are deployments' own, open-ended, and belong to the calling layer, the same layer that owns action-time authorization, which the draft explicitly declines to claim. Naming that as an open question, the way you just did, is the right first move; standardizing it would be a larger project than this thread, and we make no promise about it here. One housekeeping note for readers of the thread: the revision under ISE review is now draft-li-rttp-iqa-addressing-01 (posted 27 October 2026); the attestation-response vocabulary of Section 8 is I-D text, and the series page is https://datatracker.ietf.org/doc/draft-li-rttp-iqa-addressing/ . Best regards, Lee mailto:lee@aicent.com RTTP & IQA Organization Author, draft-li-rttp-iqa-addressing Resonant Time Transfer Protocol (RTTP, CRI 27) Identity Quality Assurance (IQA, CRI 28) Sites: https://rttp.com/ · https://iqa.org/ ------------------------------------------------------------------ From:Alan Karp < mailto:alanhkarp@gmail.com > Send Time:Wed, Oct 28, 2026, 07:26 To:ShaoBao Li< mailto:lee@aicent.com > CC:Lars Kersten Kroehl< mailto:lars@moltrust.ch >; "public-agentprotocol"< mailto:public-agentprotocol@w3.org >; llewis< mailto:llewis@sovrlabs.com >; tima< mailto:tima@aeoess.com > Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity Knowing why a request was rejected is useful. More useful is knowing the policy the delegator would like you to follow, e.g., only within the company. Most people (and agents) would obey your wishes if only they knew what they were. I have yet to see a system that has a place to put this information. As an aside, that policy is stated as a "Please." Blocking a delegation that violates it leads to credential sharing, which means you'd also like a place to say why the policy is being violated. -------------- Alan Karp On Sat, Oct 24, 2026 at 1:00 PM ShaoBao Li < mailto:lee@aicent.com > wrote: Lars, Tymofii, Larry, colleagues, Thank you for the precise answers in your last note; both refinements make revision 3 concrete, and revision 3 on that basis has our support. On the refusal reason: the value that matters is exactly the one you named — "the authority could not be determined." The fail-closed declaration you cited earlier in this thread names the behaviour rather than a substantive refusal, and we agree the result sheet must carry it as a value of its own. A record that folds unreachability into a substantive reason manufactures an intent nobody had; keeping the two apart is what makes third-party recomputation meaningful. On the grant reference: naming the grant as it stood at the decision matches the anchoring our records already use — evidence carries its issue time, the verifier checks freshness against its own clock, and recomputation runs against the recorded state, not today's. A grant narrowed after the fact should not be able to change a recorded verdict; the format can simply make that impossible. Revision 3 is therefore welcome on two fronts: it preserves the comparability of the frozen revision-2 records — our run and its sealed artifact stay pinned to the revision-2 digests, as you and Tymofii both noted — and it adds the two fields that make refusals auditable. When revision 3 lands, our runner will follow with revision-3 scoring, and the revision-2 record will stand as it is. For the AAE vectors: the candidate route suits us, and we will run them under the same treatment the lease-revocation family received — digest-gated, per-mode and per-axis scoring, with the sealed-record format available if you want an artifact of record. One housekeeping note from my post of Sat, 24 Oct 2026 22:44:14 +0800: the frozen vectors and the run-report format remain available as starting points for the common set, and the acceptance criteria still seem worth arguing here on the list rather than settled anywhere else. The offer stands. Best regards, Lee mailto:lee@aicent.com Author, draft-li-rttp-iqa-addressing-00 (ISE review) Resonant Time Transfer Protocol (RTTP, CRI 27) Identity Quality Assurance (IQA, CRI 28) Sites: https://rttp.com/ · https://iqa.org/ Blog: https://blog.aicent.com/ ------------------------------------------------------------------ From:Lars Kersten Kroehl < mailto:lars@moltrust.ch > Send Time:Sun, Oct 25, 2026, 00:54 To:Tymofii Pidlisnyi< mailto:tima@aeoess.com > CC:"public-agentprotocol"< mailto:public-agentprotocol@w3.org >; llewis< mailto:llewis@sovrlabs.com >; ShaoBao Li< mailto:lee@aicent.com > Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity Tymofii, Larry, Lee, Tymofii, that would cover both. I would put it like this: The refusal reason should be able to say that the authority could not be determined — without that value, an implementation that never reached the source has to pick the nearest substantive reason, and the record then reads like a decision someone actually made. The grant reference should identify the grant as it stood at the decision. A grant narrowed afterwards would otherwise recompute to a different answer than the one recorded, which is an awkward kind of mismatch to chase later. Revision 3 on that basis works for me, and thank you for keeping revision 2 frozen — that keeps the existing runs comparable. I will take the candidate route from CONTRIBUTING for the AAE vectors. The refusal reason also answers the taxonomy question I raised in the issue, which saves a separate discussion. Looking forward to revision 3. Lars Am 24.10.2026 um 17:02 schrieb Tymofii Pidlisnyi < mailto:tima@aeoess.com >: Lars, Larry, Lee, Lars, welcome, and thanks for offering the AAE vectors. You're right about refusals. The family reports authority validity separately, but the action decision only says permit or deny. I propose adding a refusal reason and the grant reference to each decision record, so we can compare why implementations refused and which grant they evaluated. Would that cover your two points? If so, I'll prepare revision 3 and keep revision 2 frozen for the existing runs. Lars and Larry, vectors from AAE and ATP are welcome as candidates. The lab publishes a candidate after a short review, before anyone reproduces it, and admission as a reviewed fixture is a separate step. The route is in CONTRIBUTING.md at https://www.google.com/url?q=https://github.com/Agent-Authority-Conformance/aps-conformance-suite/blob/main/CONTRIBUTING.md&source=gmail&ust=1792940577687000&sa=E Lee, thanks for the run. I reproduced the #187 output locally and will put my review on the PR. Tymofii On Sat, Oct 24, 2026 07:44 AM, ShaoBao Li < mailto:lee@aicent.com > wrote: Dear Larry, Tymofii, Chris, Lars, colleagues, Thank you all for keeping this thread moving. In my mail of 21 October I stated where our two schemes stand on the three axes, and committed to running the lab's case family against our implementation; that run is now complete. As the shared test vectors head for review, this post records the run on the list, so that everything below is checkable by anyone. The run used the frozen revision-2 vectors of the lease-revocation-axes family ( https://github.com/Agent-Authority-Conformance/aps-conformance-suite/pull/180 , corpus commit b745d25; re-verified against the PR head, 86e5e7a, on 24 October — the frozen inputs are unchanged). The vectors digest (sha256 a0a07ea58bcacfd056cbd648e03de4ff14778aa151e8b5d2574e43e31a111ed8) is a hard gate: the runner refuses to score anything else, and the gate was verified negatively — a tampered copy is rejected before any scoring occurs. The runner is an independent stdlib-only Python implementation (code as run: 8cb2e241419cd03d9be40c5977e0e9caa1d723a4, under https://github.com/Aicent-Stack/conformance ); it declares three axes — evidence freshness: claimed; authority validity: claimed; action-time authorization: not claimed (by design). Results: 48/48 baseline runs matched (4 profiles × 12 cases — two lease modes × two boundary policies), across 176 calls, 528 scored axis comparisons and 176 composite comparisons; all 12 mutation probes matched their pinned failure sets; 20/20 post-expiry diagnostic runs were clean, every emitted diagnostic backed by an actual recorded read; 12/12 hand-reasoned oracle checkpoints agreed; and all five reporting-semantics checks are true — executed, not asserted. Three consecutive runs on 24 October produced byte-identical reports. No suspected defective vectors were observed. Our run is author-produced by the lab's definitions — Mode B, labeled as such in the report; the implementation is independent of the lab's code, but the filer is the author, and the record says so. Tymofii's independent reproduction review of 23 October (PR #180 comment) surfaced two reporting defects, both fixed in the corrected revision (rev c). The disagreements along the way are documented rather than disputed. The interoperability package was submitted to the lab on 24 October as PR #187 ( https://github.com/Agent-Authority-Conformance/aps-conformance-suite/pull/187 , under review). The sealed artifact of record (lra-runner-20261023c.tar.gz, sha256 94bbaf3c292abf69595bf5782d1db8cbb4178536d53182578b46cff94a5c4b15) is published at https://iqa.org/conformance/lra-runner/ and carries two addresses derived from its own digest — nothing invented, nothing registered, both resolve live now: - rttp://94bbaf3c.conformance.iqa — the question side (WHERE + WHEN); intent = first 8 hex of the artifact digest - iqa://94bbaf3c292abf69595bf5782d1db8cb.forge.iqa — the answer side (WHETHER); subject = first 32 hex of the same digest Everything above can be recomputed from the pinned digests without contacting us. On next steps: the frozen vectors and the run-report format are both available as starting points for the common vector set proposed in this thread — and we would rather see the acceptance criteria argued on this list than settled anywhere else. Lars — your two reporting-criteria suggestions are received and substantive; they deserve more than a footnote, and I will respond to them in a separate post. Best regards, Lee mailto:lee@aicent.com Author, draft-li-rttp-iqa-addressing-00 (ISE review) Resonant Time Transfer Protocol (RTTP, CRI 27) Identity Quality Assurance (IQA, CRI 28) Sites: https://rttp.com/ · https://iqa.org/ Blog: https://blog.aicent.com/ ------------------------------------------------------------------ From:Larry Lewis < mailto:llewis@sovrlabs.com > Send Time:Sat, Oct 24, 2026, 21:15 To:Lars Kersten Kroehl< mailto:lars@moltrust.ch > CC:ShaoBao Li< mailto:lee@aicent.com >; "public-agentprotocol"< mailto:public-agentprotocol@w3.org >; Tymofii Pidlisnyi< mailto:tima@aeoess.com >; ShaoBao Li< mailto:lee@iqa.org > Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity Hi Lars, Tymofii, Lee, and colleagues, Thank you, Lars, for joining the experiment and for the thoughtful suggestions regarding revocation outcomes and verifiable authority references. I've been out of the office and am catching up, but I'm excited to see this collaboration moving forward. Tymofii, I appreciate you opening the conformance work. We'll begin reviewing the shared test vectors and preparing ATP's implementation contributions. Looking forward to working with everyone and helping move this effort forward. Best regards, Larry Lewis Chair, Agent Trust Protocol Community Group From: Lars Kersten Kroehl < mailto:lars@moltrust.ch > To: "ShaoBao Li"< mailto:lee@aicent.com > Cc: "Larry Lewis"< mailto:llewis@sovrlabs.com >, "public-agentprotocol"< mailto:public-agentprotocol@w3.org >, "Tymofii Pidlisnyi"< mailto:tima@aeoess.com >, "ShaoBao Li"< mailto:lee@iqa.org > Date: Sat, 24 Oct 2026 07:06:12 -0500 Subject: Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity Larry, Lee, Tymofii, I'm Lars, author of the Agent Authorization Envelope (draft-kroehl-agentic-trust-aae), which covers delegation and revocation. Count us in for the experiment if you like — we can run the T=0/10/30/60/119 sequence as you set it out, and I can put delegation and revocation test vectors into a common set. One suggestion for the reporting criteria, if useful. Lee's fail-closed answer for the unreachable case already names the behaviour, and the result sheet should be able to show it. If a run records only permitted or refused, an implementation that refused because the authority was revoked and one that refused because it could not determine the authority come out looking the same. Keeping those apart, alongside the per-mode and per-axis scoring already proposed, would show which is which. For the same reason it helps if each recorded decision names the authority it was taken under, so a third party can recompute it. Looking forward to it. Lars Am 21.10.2026 um 22:19 schrieb ShaoBao Li < mailto:lee@aicent.com >: Dear Larry, Tymofii, Yes to the experiment — and it is worth pausing on how it arrived: the same timeline, the same variant with the revocation service unreachable, proposed independently from two different layers within hours of each other. That is the best evidence yet that the row our Q3 asked about is real: it is being felt from the delegation side and from the enforcement side at once, and neither of you needed the other's vocabulary to draw it. Answering the direct question about the three axes, for the rttp and iqa schemes (draft-li-rttp-iqa-addressing-00, in ISE review; provisionally registered at IANA as CRI 27 and CRI 28; public entries at https://rttp.com/ and https://iqa.org/ ). The three-way distinction is Larry's framing, and it is the right one; here is where our schemes stand on it. We claim two of the three. Evidence freshness: claimed — every statement carries its 120-second lease in-band, checked locally against the verifier's own clock, offline. Authority validity: claimed — a named organ answers for the subject's standing in a closed four-state set (ghost, probation, radiant, genesis), and the standing read is a safe, read-only operation. Action-time authorization: not claimed — and, to pick up Larry's phrasing, our contribution and boundaries should be documented separately, because the gap is deliberate. Authorization decisions belong to the calling layer; the protocol's job is to make the verification answers trustworthy and cheap, not to decide what may be done with them. A conformance suite that scores the three axes separately is not a concession to us — it is the design speaking. To Larry's specific question — how RTTP/IQA behaves when revocation lands inside an active freshness window, particularly when revocation information is unavailable or delayed — our answer has two named modes, and we would state the expected results for each so the test cases do not expect more from us than we claim. In cached-lease mode, the T=119 call is expected to go through, and in the unreachable-revocation-service variant it is still expected to go through: offline completion is the design point, not a degradation, and the exposure is bounded by the lease itself. In live-standing-read mode, T=30, T=60 and T=119 are all expected to be refused, and in the unreachable variant the refusals are expected to be fail-closed: an organ that cannot be reached is not read as silent consent. If the suite scores those two behaviours separately, the two modes will be distinguishable by more than a mode flag. On publishing: we agree the test definitions and results should be open, and we can contribute from our side — the derivation and envelope-verification conformance vectors behind the two schemes are already public, and the standing-read semantics are specified in the draft. A case family built on the shared timeline, scored per axis, with each run declaring its mode, is the right shape; we will run our schemes against it and report in the open. On the wider federation discussion (#177) and the ATP observations: the boundary-first framing — each project keeps its own piece, verification happens at the edges, a mechanism is scored on what it claims — is one we can work inside. We will engage in writing, per the standing offer that came with the four questions. One housekeeping note, happily obsolete by the hour: your message, Larry, reached the archive as No. 0014 while this reply was being drafted — a faster pass through the same first-post review queue our own letter sat in last week. The thread now reads 0009, 0011, 0012, 0013, 0014; every quotation above has its anchor on the wall. Best regards, Lee mailto:lee@aicent.com Author, draft-li-rttp-iqa-addressing-00 (ISE review) Resonant Time Transfer Protocol (RTTP, CRI 27) · Identity Quality Assurance (IQA, CRI 28) Sites: https://rttp.com/ · https://iqa.org/ Blog: https://blog.aicent.com/ ------------------------------------------------------------------ From:Larry Lewis < mailto:llewis@sovrlabs.com > Send Time:Thu, Oct 22, 2026, 02:03 To:ShaoBao Li< mailto:lee@aicent.com > CC:Tymofii Pidlisnyi< mailto:tima@aeoess.com >; "public-agentprotocol"< mailto:public-agentprotocol@w3.org >; ShaoBao Li< mailto:lee@iqa.org > Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity Dear Lee, Tymofii, and AI Agent Protocol Community Group, Thank you, Lee, for sharing your review of the Agentic Web technical report and for presenting four thoughtful questions concerning identity assurance, addressing, trust freshness, and interoperability. I also appreciate Tymofii's response regarding delegation expiry and revocation in the Agent Passport System (APS). From the perspective of the Agent Trust Protocol (ATP) Community Group, I believe this discussion highlights an important opportunity for collaboration across the emerging agentic web ecosystem. Trust is not a single mechanism or verification event. It involves multiple layers of identity, evidence, authority, policy enforcement, revocation, and accountability. I would like to share a few observations concerning the four questions and propose a practical way for our respective projects to explore them together. Q1 - Preimage Defense and Identity Substitution I agree that demonstrating cryptographic key control does not necessarily establish the legitimacy or continuity of an agent's claimed authority. We should distinguish between verifying a DID document, establishing its provenance, determining whether its verification methods remain valid, and ensuring that the identity presented corresponds to the authority expected by the receiving agent. This raises useful interoperability test cases involving identity-document substitution, compromised verification methods, key rotation, and conflicting authority claims. Q2 - Address Assurance Separating addressing from discovery is worth examining. Deterministically derived addresses can provide useful properties, but address integrity should not be confused with proof of legitimate ownership or authorization. I would be interested in exploring how RTTP-derived addressing interacts with DID resolution, existing agent discovery mechanisms, and independent authority verification. Q3 - Trust Leases, Freshness, and Revocation This question is particularly relevant to ATP's work on delegated authority and runtime enforcement. ATP distinguishes between trust evidence and authorization. A credential or statement may remain cryptographically valid while its underlying authority has expired, been revoked, or become insufficient for a particular action. Tymofii raises an important point: a 120-second freshness lease could allow previously verified evidence to remain within its accepted freshness window even after revocation. We should therefore distinguish at least three concepts: Evidence freshness — how recently the statement or credential was verified. Authority validity — whether the delegation remains valid and unrevoked. Action-time authorization — whether the requested operation is currently permitted under the applicable constraints and policies. I would welcome further clarification regarding how RTTP/IQA handles revocation within an active freshness window, particularly when revocation information is unavailable or delayed. For ATP, this distinction is central to our approach: trust evidence informs authorization, but possession of valid evidence does not automatically grant permission to act. Q4 - Statement-Level and Platform-Level Interoperability I see these approaches as potentially complementary rather than mutually exclusive. Statement-level verification can support portable, independently verifiable evidence across systems. Platform-level infrastructure can provide additional operational services, governance, policy administration, and trust coordination. The important architectural question is whether independently operated agents can verify the evidence and enforce the appropriate authority without depending on a particular commercial platform. This is an area where I believe cooperation between our projects could produce useful implementation evidence. Proposal — A Joint Trust Interoperability Experiment Rather than limiting the discussion to architectural comparisons, I would like to propose a small, collaborative technical exercise involving RTTP/IQA, APS, and ATP. We could begin with the trust-lease and revocation scenario raised by Tymofii: T=0: An agent receives valid identity and authorization evidence. T=10 seconds: The issuing authority revokes the relevant delegation or statement. T=30, T=60, and T=119 seconds: The agent attempts an operation requiring that authority. Each implementation evaluates the requests according to its own documented verification and enforcement mechanisms. We compare the decisions, verification evidence, revocation handling, and limitations. We should also examine what happens when the revocation service is temporarily unavailable and whether the receiving system can independently establish the authority needed to perform the action. The goal would not be to determine which protocol is superior or to require any project to adopt another project's architecture. Instead, we could establish a common set of security properties, test vectors, and reporting criteria while allowing each implementation to demonstrate its respective responsibilities. Importantly, a mechanism that does not claim to provide action authorization should not be evaluated as though it does. Its contribution and boundaries should be documented separately. Publishing the Results If there is interest, I suggest publishing the agreed test definitions and implementation results openly so other contributors can reproduce, evaluate, and extend them. This could help the community better understand: Which trust guarantees are already implemented. Which mechanisms complement one another. Where interoperability boundaries exist. What gaps require additional specification work. Which security properties can be independently verified across different agent systems. From ATP's perspective, our interest is in helping establish portable, verifiable, revocable, and enforceable trust mechanisms that can operate across agent frameworks and organizational boundaries. I believe this is an opportunity for the community to advance the technical foundations of the agentic web collectively. I would welcome both Lee's and Tymofii's thoughts on this approach, as well as feedback from other Community Group participants. Thank you again for contributing to this important conversation. Best regards, Larry Lewis Chair, Agent Trust Protocol Community Group W3C Community Groups
Received on Wednesday, 28 October 2026 18:17:35 UTC