Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity

Hi Larry, Steven, Lars, Chop, all,

This is exactly the consensus we needed.

Larry: Thank you for taking the first pass at the candidate matrix. That is
a massive step forward. The distinction between "grant-time" and
"continuing-use" conditions is the exact legal line where NTI operates.

Steven & Chop: The incomplete_check block (with reason: tryLater,
not_authoritative, or internal_error) is the perfect solution for the
stale/unreachable registry problem. As you both noted, the runtime cannot
infer intent if the registry is dark. It must fail closed (PAUSE).

Lars: I fully agree on recording t_observed, t_effective, and the exact
registry version read. This gives the independent observer the
cryptographic evidence needed to prove whether the halt was justified.

This entire thread has effectively written Chapter 3 of the NTI
specification. I am consolidating this into the final paper for Kaliya's
AIW Book of Proceedings today, and I will cite this working group's
consensus on the LGD state machine and the incomplete_check receipts.

@Larry, let me know how I can help review the matrix you draft.

Best,
Abisheak

On Thu, 29 Oct, 2026, 7:09 pm Larry Lewis, <llewis@sovrlabs.com> wrote:

> Hi Abisheak, Lee, Tymofii, and colleagues,
>
> Abisheak, I’ll take the first pass at the candidate matrix today and
> coordinate it with you and Tymofii. I’ll cover grant-time and
> continuing-use conditions, registry freshness and unavailability, and the
> distinction between blocking the next call and observing effects from one
> already underway.
>
> Lee, I’ll map those cases against the existing lease-revocation family and
> identify the specific additions, with attribution to the lab fixtures and
> each independent runner and operator. I have the Aicent-Stack/conformance
> repository and lra_runner.py from your note; I’ll pin the exact file and
> run revision as part of that review.
>
> I’m on Chicago time (Central Time). Once we’ve agreed on the cases and run
> them, we can report the results and limits back to the group together.
>
> Let’s get to work.
>
> Best regards,
> Larry Lewis
> Founder, SovrLabs
> Chair, W3C Agent Trust Protocol Community Group
>
>
>
>
>
> ---- On Thu, 29 Oct 2026 07:06:48 -0500 *Abisheak P
> <abisheakp197@gmail.com <abisheakp197@gmail.com>>* wrote ----
>
> Hi Lars, AlgoVoi, Larry, all,
>
> This is exactly the synthesis the standard needs. Let me address your
> specific points:
>
> 1. Lars — The "Stale Root" / Unreachable Registry Problem:
> You are 100% right. If a sidecar reaches a boundary check and cannot reach
> the registry, or the proof is against a stale root, it MUST fail closed. In
> NTI, if the registry read fails or the proof age exceeds the TTL
> (Time-To-Live), the state transitions to authority_not_determined, and the
> sidecar throws a PermissionError. It does not stay ACTIVE under unconfirmed
> authority. Recording t_effective, t_observed, and the registry version is
> the exact metadata NTI receipts will carry.
>
> 2. AlgoVoi — Merkle Proof Bound to Call vs. Session:
> The Merkle proof is bound to the individual call. We hash the canonical
> execution payload (agent_id, run_id, action, canonical_args_hash) and
> verify the proof against the registry. However, the run_id ties it back to
> the session, preventing cross-session replay attacks.
>
> 3. Larry — Grant-Time vs. Continuing-Use Conditions:
> This is the exact boundary where NTI lives. NTI explicitly enforces
> continuing-use conditions (execution-time consent). As you noted, a
> grant-time condition can become invalid mid-execution (e.g., the lease
> expires, or the employee leaves). NTI checks the policy at the moment of
> use on every loop iteration, ensuring the condition still holds before the
> tool fires.
>
> Larry: I would be honored to have your help turning these distinctions
> into candidate shared test cases. Your framework for the test matrix
> (grant-time vs. continuous-use) is exactly the scaffolding we need for the
> AIW Book of Proceedings.
>
> I will consolidate these into the final draft.
>
> Best,
> Abisheak
>
> On Thu, 29 Oct, 2026, 3:22 pm ShaoBao Li, <lee@aicent.com> wrote:
>
> *Larry, Lars, colleagues,*
>
> On the experiment in 0084: it already exists. The T=0/10/30/60/119
> scenario, the deliberately defective runtimes, and the
> revocation-unavailable case are materially the lease-revocation-axes family
> we ran and recorded in the LFDT Agent-Authority-Conformance lab:
> forty-eight baseline cases across two frozen revisions, a full mutation
> battery, and two interop records with independent-operator provenance now
> in the lab's main line. The vectors, the refusal vocabulary, the runner,
> and the recorded outputs are public and byte-replayable, and any
> implementation can take them up as they stand — that is what they are for;
> we would welcome ATP evaluating the family from its own perspective under
> Larry's framing.
>
> Larry's boundary sentence in 0084 — a mechanism that does not claim to
> provide action authorization should not be evaluated as though it does — is
> our own not_claimed axis stated back to us, and we accept it as the
> standing rule for any comparison: each implementation documents what it
> claims and what it leaves to others.
>
> On Lars's 0085: the qualification is correct and we accept it. "One window
> per successful read" is the sharper form of what the lease was meant to say
> — the window bounds reliance on the last verification that returned an
> answer; a read that returns nothing is itself an answer
> (authority_not_determined, fail-closed at the boundary), and a runtime that
> keeps going without a determinate answer is outside what any window can
> bound. That is the no-stop-button position seen from the runtime side; we
> consider it the same fact stated from both ends of the wire. We set that
> position out yesterday in "What happens mid-task: the lease is the halt" —
> https://blog.aicent.com/q18-what-happens-mid-task/ — and at length
> earlier today, hours before 0085 appeared, in "No Stop Button on the Wire"
> — https://blog.aicent.com/no-stop-button-on-the-wire/ (Chinese edition:
> https://blog.aicent.com/zh/no-stop-button-on-the-wire/) — covering
> exactly this boundary: where the halt lives, why the window bounds reliance
> on the last successful answer, and why the chain stops by arithmetic rather
> than by signal.
>
> The vector proposal is good and cheap, and we will take it into the
> family's candidate set for its next revision: recording the registry
> version the runtime actually read and the instant it read it, so a run
> against an unreachable registry separates from a run that was told "not
> revoked"; and adding a runtime that cannot reach the registry and keeps
> going to the defect family beside the deliberately defective one. Whether
> the lifecycle grows a state or the receipt simply carries the read is
> indeed the group's call, and we have no attachment either way.
>
> One addition for replay: the fixtures referenced in 0085, the runner that
> scored them, and the recorded outputs live at Aicent-Stack/conformance on
> GitHub, runner lra_runner.py, operator Lee / Aicent Stack (RTTP CRI 27 ·
> IQA CRI 28). From this run forward our run reports ship with a citation
> block, and we ask that any public reference to an independent run names the
> runner, its repository, and its operator — the lab's own records already
> ask for nothing less.
>
>
> 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:Larry Lewis <llewis@sovrlabs.com>
> Send Time:Thu, Oct 29, 2026, 13:35
> To:ShaoBao Li<lee@aicent.com>
> CC:Alan Karp<alanhkarp@gmail.com>; "public-agentprotocol"<
> public-agentprotocol@w3.org>; Lars Kersten Kroehl<lars@moltrust.ch>; 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
>
> Hi Alan, Lee, and colleagues,
>
> Alan, your clarification helps: “within the company” concerns who receives
> delegated permission. The external-accountant example also shows why
> organizational labels alone may not express the intended boundary.
>
> Lee’s timing question suggests two useful test cases:
>
>    1.
>
>    Does the recipient satisfy the delegation policy when permission is
>    delegated?
>    2.
>
>    If the policy requires continued eligibility, does that condition
>    still hold when permission is exercised?
>
> We should state which timing rule applies before testing. A grant-time
> condition and a continuing-use condition can produce different valid
> outcomes.
>
> I would also keep lease expiry separate from revocation: expiry ends
> reliance on the earlier answer; a fresh check establishes whether authority
> remains valid, has been revoked, or cannot be determined.
>
> From a perspective, the useful experiment is whether the policy travels
> with the permission while preserving its advisory or mandatory meaning, its
> timing requirements, and any attributed explanation for a departure. An
> explanation should remain distinguishable from authorization for an
> exception.
>
> I’d be glad to help turn these distinctions into candidate cases alongside
> the runtime work.
>
>
> Best regards,
> Larry Lewis
> Founder, SovrLabs
> Chair, W3C Agent Trust Protocol Community Group
>
>
>
>
>
>
>
> From: ShaoBao Li <lee@aicent.com>
> 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>
> Date: Wed, 28 Oct 2026 18:10:35 -0500
> Subject: Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> *Alan,*
>
> Fair correction — I read "within the company" as a constraint on the
> action, and you meant a constraint on the delegation: to whom the
> permission may travel. The HP variant makes the difference concrete, and it
> is the more interesting half of the case: the leak you describe is not a
> policy misread but a delegation that reached a principal the condition was
> written to exclude.
>
> One observation on where that condition gets its inputs. Whether the
> delegatee is "within the company" can be as complicated as the label
> suggests — your external-accountant case shows the boundary is policy. But
> whatever the condition turns out to be, the facts it computes over are
> cheaper than the condition: who the delegatee is, and whether that
> delegatee's authority stands verified at the instant of use, are bytes a
> verifier returns, not opinions. A DENY computed over those facts is
> auditable the same way our refusal reasons are — a third party can
> re-derive it; a DENY computed over the label alone cannot.
>
> So the split I would propose is the one our two positions have been
> converging on anyway: the delegator's "Please" travels with the permission,
> unstandardized, one layer up; your DENY-if-any-condition-isn't-met executes
> in the calling layer; and the wire's job is to make the authority-side
> inputs of that decision checkable at the moment of use, not only at the
> moment of grant. Your delegatee with a good reason to violate the request —
> the internal program without credentials — is that layer's judgment call,
> not the wire's.
>
> Which leaves one question I suspect we see differently. Does "within the
> company" have to hold when the delegation is made, or at every later use?
> If the latter, the employee who leaves on day thirty is the mid-task case
> from my earlier note in this thread: the lease expires, the next
> verification returns authority_revoked, and the halt is armed by a
> timestamp the runtime has held since its first answer. The condition may be
> yours; the freshness of the facts it consumes has to come from somewhere,
> and I claim that somewhere is the wire.
>
>
> 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:Thu, Oct 29, 2026, 05:26
> 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
>
> Your example doesn't capture my point.  When I said the condition is
> "within the company," I intended it to mean to whom you should delegate.
> Let me use a slight variant of an actual case.  One quarter HP had to
> release its financial statement early because a reporter was included on an
> email with a draft of it.  Change the example slightly to delegating access
> to the draft.
>
> We typically use labels, such as Company Confidential, to represent what
> might be a complicated policy.  (Should external accountants hired by the
> company be included?)  However you do it, it would be nice if the delegator
> could tell the delegatee (not a word but doesn't get confused with the verb
> delegate), what policies are appropriate for the permission.  It's a
> "Please" because the delegatee may have a good reason to violate the
> request, e.g., to delegate to an internal program that doesn't have
> credentials.
>
> As to your question about whether to honor the request, I would say DENY
> if any condition isn't met.
>
> --------------
> Alan Karp
>
>
> On Tue, Oct 27, 2026 at 8:25 PM ShaoBao Li <lee@aicent.com> wrote:
> *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
>
>
>
>
>
>
>