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

Larry, thanks for running the tests. And yes, I'd be happy to have a
working session.

There's one thing I'd like to get recorded properly. Lee wrote an
independent runner, but his own run is classified as author produced under
the lab's rules. Your reproduction at
https://www.google.com/url?q=https://github.com/Aicent-Stack/conformance/commit/8a58c88c3bebf545c9654d297c607bea5d91f983&source=gmail&ust=1793419672637000&sa=E
appears to qualify as an independent run, since you authored neither the
vectors, the claim inputs nor the runner. That's a meaningful addition to
the evidence, even though it uses Lee's implementation rather than a new
one.

Would you be willing to submit the run record alongside his? We have a
format at
https://www.google.com/url?q=https://github.com/Agent-Authority-Conformance/aps-conformance-suite/blob/main/docs/RUN-REPORT.md&source=gmail&ust=1793419672637000&sa=E.
The pinned runner commit, vector revisions and digests, environment,
commands and verbatim per case output should be enough to review it. We'll
preserve both records with their authorship clearly identified and confirm
the classification during review.

For the next test family, I agree with your distinction. Refusing a new
call after revocation is one thing. Stopping an operation that's already
running is another. Our current cases address the first, but don't
establish what actually happens to an operation in progress.

Before writing the new cases, I'd like us to agree on three things:

1. What stopping means for an operation that cannot be interrupted versus
one that can stop at a checkpoint.
2. What an independent observer needs to record to establish whether the
operation stopped or completed.
3. What a PAUSE receipt should contain, including Xinghua's
incomplete_check block and the distinction between tryLater and a timeout.

We should also cover admission of new calls when a check is incomplete,
separately from what happens to an operation already underway.

Once those are defined, we can write the expected outcomes before running
the tests.

Send me two or three times that work for you. I'm on Pacific time, and
Abisheak and Lee are welcome to join.

Tymofii Pidlisnyi (Agent Passport System)

On Thu, Oct 29, 2026 06:22 PM, Larry Lewis <llewis@sovrlabs.com> wrote:

>
>
> Hi Tymofii, Lee and others
>
> I’ve reproduced Lee / Aicent Stack’s independent lra-runner/lra_runner.py
> from Aicent-Stack/conformance, pinned to commit 8a58c88c3bebf545c9654d2
> 97c607bea5d91f983.
>
> Revisions 2 and 3 both returned independent_run_matched: 48 baseline runs
> and 176 calls per revision, zero baseline failures, and all 12 mutation
> failure sets matching expectations. The diagnostics, oracle checkpoints,
> and reporting checks also passed.
>
> That gives us the existing modeled baseline to build on. My proposed next
> candidate covers the running call’s resource effects and whether the PAUSE
> receipt agrees with an independent observer.
>
> Let’s coordinate the candidate rows and receipt fields, using one
> non-interruptible operation and one checkpointable operation. We should fix
> each operation’s finish-or-stop contract before running, and check
> admission of subsequent calls separately from effects of the already
> admitted call.
>
> I have the matrix and replay evidence ready. I’m on Chicago time and would
> be glad to arrange a working session, then review the results together
> before reporting back to the group.
>
> Best regards,
> Larry Lewis
> Founder, SovrLabs
> Chair, W3C Agent Trust Protocol Community Group
>
>
>
>
>
> From: Abisheak P <abisheakp197@gmail.com>
> To: "ShaoBao Li"<lee@aicent.com>
> Cc: "Larry Lewis"<llewis@sovrlabs.com>, "alanhkarp"<alanhkarp@gmail.com>,
> "public-agentprotocol"<public-agentprotocol@w3.org>, "lars"<
> lars@moltrust.ch>, "tima"<tima@aeoess.com>
> Date: Thu, 29 Oct 2026 11:36:14 -0500
> Subject: Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> Hi Larry, Lee, Steven, Lars, Alan, all,
>
> I wanted to share a major milestone. Following the incredible consensus we
> reached in this thread, I have finalized the NTI-1 Specification and the
> AIW Paper.
>
> Every piece of feedback from this group has been formally adopted:
>
> · Principal-Bound Identity: (Per Alan Karp) The spec now explicitly
> requires identifiers to be tied to the responsible legal party, not just
> the agent.
> · Runtime Halt & LGD State Machine: (Per Steven Zhao) The REGISTERED ->
> GATE_PASSED -> ACTIVE -> ANOMALY -> PAUSE -> ROLLBACK -> REVERIFY ->
> RESUMED sequence is now the official NTI-1 standard.
> · Fail-Closed Semantics: (Per Lars & Lee) The incomplete_check receipt
> (with tryLater, not_authoritative, internal_error) is formally defined. If
> a registry is unreachable, NTI will PAUSE, not proceed under stale
> authority.
> · Ecosystem Interoperability: (Per Raja) The ASL Conformance Kit's static
> vectors and kernel confinement are officially integrated into the NTI CI/CD
> pipeline, utilizing AF_UNIX sockets.
>
> The final documents are live:
> 👉 NTI-1 Specification: https://github.com/abisheakp197/nti-spec/blob/
> main/NTI-1.md
> 👉 AIW Paper: https://github.com/abisheakp197/nti-spec/blob/
> main/AIW_Paper_NTI.md
>
> Larry: The spec is now structurally ready for your candidate matrix. I
> have defined the exact incomplete_check schema and state transitions your
> test cases need to target. I am ready to run NTI against the full matrix
> the moment you publish it.
>
> The standard is converging. Let's keep pushing.
>
> Best,
> Abisheak
>
>
> On Thu, 29 Oct, 2026, 7:46 pm ShaoBao Li, <lee@aicent.com> wrote:
>
> *Colleagues*,
>
> Larry's first pass at the candidate matrix is the right way to take this
> forward, and we are glad to work inside it: attribution to the lab fixtures
> and each independent runner and operator is the rule this thread has been
> converging on, and with the chair carrying the matrix the pieces now have
> one place to land.
>
> For the mapping, the anchors Larry asked to pin are already on the record:
> runner lra_runner.py, repository Aicent-Stack/conformance, operator Lee /
> Aicent Stack (RTTP CRI 27 · IQA CRI 28), forty-eight baseline cases across
> two frozen revisions with the full mutation battery, recorded in the lab's
> main line as PRs #187 and #194; exact file paths, commit pins and digests
> are ready on request — whatever precision the matrix needs, we will supply
> it.
>
> One technical answer while the matrix forms: on the question Lars's #200
> leaves open, the case maps onto the existing set — in XP-2 both artifacts
> verify natively and carry the same action digest, but their bindings
> diverge, so the wire answer at the decision boundary is
> evidence_binding_mismatch, first in the set's priority order; the fixture's
> per-stage label can keep its name as a composition-stage diagnostic carried
> in the receipt, one layer up, and no fixture change is required.
>
> We will bring the family's candidate additions — the receipt-metadata
> vector accepted in 0086 — forward under the same treatment, and we are
> ready to start whenever the matrix is.
>
>
> 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
> Blog: https://blog.aicent.com
>
> ------------------------------------------------------------------
> From:Larry Lewis <llewis@sovrlabs.com>
> Send Time:Thu, Oct 29, 2026, 21:40
> To:abisheakp197<abisheakp197@gmail.com>
> CC:ShaoBao Li<lee@aicent.com>; alanhkarp<alanhkarp@gmail.com>;
> "public-agentprotocol"<public-agentprotocol@w3.org>; lars<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 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 a0a07ea58bcacfd056cbd648e03de4
> ff14778aa151e8b5d2574e43e31a111ed8) 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 94bbaf3c292abf69595bf5782d1db8
> cbb4178536d53182578b46cff94a5c4b15) 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,
>
>