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

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, <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 —
>
>    1. *Boundary values* (the five-value set) for post-revocation new
>    calls;
>    2. *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" <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, <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
>> 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 <lee@aicent.com>
>> Send Time:Wed, Oct 28, 2026, 11:26
>> To:Alan Karp<alanhkarp@gmail.com>
>> CC:"public-agentprotocol"<public-agentprotocol@w3.org>; Lars Kersten
>> Kroehl<lars@moltrust.ch>; llewis<llewis@sovrlabs.com>; tima<
>> tima@aeoess.com>; ShaoBao Li<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
>> 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 <alanhkarp@gmail.com>
>> Send Time:Wed, Oct 28, 2026, 11:06
>> To:ShaoBao Li<lee@aicent.com>
>> CC:"public-agentprotocol"<public-agentprotocol@w3.org>; Lars Kersten
>> Kroehl<lars@moltrust.ch>; llewis<llewis@sovrlabs.com>; tima<
>> tima@aeoess.com>; ShaoBao Li<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 <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
>> 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 <alanhkarp@gmail.com>
>> Send Time:Wed, Oct 28, 2026, 09:58
>> To:ShaoBao Li<lee@aicent.com>
>> CC:"public-agentprotocol"<public-agentprotocol@w3.org>; Lars Kersten
>> Kroehl<lars@moltrust.ch>; llewis<llewis@sovrlabs.com>; tima<
>> 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 <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
>> 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 <alanhkarp@gmail.com>
>> Send Time:Wed, Oct 28, 2026, 07:26
>> To:ShaoBao Li<lee@aicent.com>
>> CC:Lars Kersten Kroehl<lars@moltrust.ch>; "public-agentprotocol"<
>> public-agentprotocol@w3.org>; llewis<llewis@sovrlabs.com>; tima<
>> 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 <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
>> 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 <lars@moltrust.ch>
>> Send Time:Sun, Oct 25, 2026, 00:54
>> To:Tymofii Pidlisnyi<tima@aeoess.com>
>> CC:"public-agentprotocol"<public-agentprotocol@w3.org>; llewis<
>> llewis@sovrlabs.com>; ShaoBao Li<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 <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 <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
>> 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 <llewis@sovrlabs.com>
>> Send Time:Sat, Oct 24, 2026, 21:15
>> To:Lars Kersten Kroehl<lars@moltrust.ch>
>> CC:ShaoBao Li<lee@aicent.com>; "public-agentprotocol"<
>> public-agentprotocol@w3.org>; Tymofii Pidlisnyi<tima@aeoess.com>;
>> ShaoBao Li<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 <lars@moltrust.ch>
>> To: "ShaoBao Li"<lee@aicent.com>
>> Cc: "Larry Lewis"<llewis@sovrlabs.com>, "public-agentprotocol"<
>> public-agentprotocol@w3.org>, "Tymofii Pidlisnyi"<tima@aeoess.com>,
>> "ShaoBao Li"<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 <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.comand 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
>> 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 <llewis@sovrlabs.com>
>> Send Time:Thu, Oct 22, 2026, 02:03
>> To:ShaoBao Li<lee@aicent.com>
>> CC:Tymofii Pidlisnyi<tima@aeoess.com>; "public-agentprotocol"<
>> public-agentprotocol@w3.org>; ShaoBao Li<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:
>>
>>    1.
>>
>>    Evidence freshness — how recently the statement or credential was
>>    verified.
>>    2.
>>
>>    Authority validity — whether the delegation remains valid and
>>    unrevoked.
>>    3.
>>
>>    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
>>
>>
>>