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

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
>
>
>