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

Tymofii, colleagues,
Yes to the working session, and thank you for recording Larry's replication as an independent run in its own right; two records side by side, each labeled by its authorship, is the right shape for the lab.
On the PAUSE receipt: we support including Xinghua's incomplete_check block, and the provenance is worth stating once, because it is clean — the three reasons in the block (tryLater, not_authoritative, internal_error) descend from OCSP (RFC 6960, Section 2.3), and the block maps them onto authority_not_determined, which is the boundary value our draft's Section 8 defines for exactly the case where the check cannot be completed at all. The layering is the part we most want preserved: the wire value set stays closed at five, the receipt carries the check outcome, and nothing needs a sixth value on the wire.
That division of labor is also what makes the receipt auditable: PAUSE(authority_not_determined) is the decision any third party can recompute against the draft, and incomplete_check.reason is the local account of why the check did not complete — decision on the wire, explanation in the receipt.
One small technical note for the session: keep the mapping one-directional. An incomplete_check outcome may name the wire value it maps onto, but the wire value must never depend on the receipt's presence — a PAUSE with no receipt attached should still be a well-formed record, since the refusal is complete on its own.
Xinghua — the block is welcome; the OCSP lineage gives it a floor any implementer can trace, and the mapping onto the closed set is the right use of both.
We will join the working session; the running-call candidate family raised earlier in this thread sits naturally next to the mid-task halt semantics described in our earlier note, and we are glad to see it taken 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
Blog: https://blog.aicent.com
------------------------------------------------------------------
From:Tymofii Pidlisnyi <tima@aeoess.com>
Send Time:Fri, Oct 30, 2026, 12:09
To:llewis<llewis@sovrlabs.com>
CC:abisheakp197<abisheakp197@gmail.com>; ShaoBao Li<lee@aicent.com>; alanhkarp<alanhkarp@gmail.com>; lars<lars@moltrust.ch>; "public-agentprotocol"<public-agentprotocol@w3.org>
Subject: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 <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 <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 <mailto: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 8a58c88c3bebf545c9654d297c607bea5d91f983.
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 <mailto:abisheakp197@gmail.com >>
To: "ShaoBao Li"<lee@aicent.com <mailto:lee@aicent.com >>
Cc: "Larry Lewis"<llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>, "alanhkarp"<alanhkarp@gmail.com <mailto:alanhkarp@gmail.com >>, "public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>, "lars"<lars@moltrust.ch <mailto:lars@moltrust.ch >>, "tima"<tima@aeoess.com <mailto: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 <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 <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 <mailto: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 <mailto:lee@aicent.com >
RTTP & IQA Organization
Author, draft-li-rttp-iqa-addressing
Resonant Time Transfer Protocol (RTTP, CRI 27)
Identity Quality Assurance (IQA, CRI 28)
Sites: https://rttp.com <https://rttp.com/ > · https://iqa.org <https://iqa.org/ >
Blog: https://blog.aicent.com <https://blog.aicent.com/ >
------------------------------------------------------------------
From:Larry Lewis <llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>
Send Time:Thu, Oct 29, 2026, 21:40
To:abisheakp197<abisheakp197@gmail.com <mailto:abisheakp197@gmail.com >>
CC:ShaoBao Li<lee@aicent.com <mailto:lee@aicent.com >>; alanhkarp<alanhkarp@gmail.com <mailto:alanhkarp@gmail.com >>; "public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>; lars<lars@moltrust.ch <mailto:lars@moltrust.ch >>; tima<tima@aeoess.com <mailto:tima@aeoess.com >>; ShaoBao Li<lee@iqa.org <mailto:lee@iqa.org >>
Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Hi 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 <mailto: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 <mailto: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/ <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/ <https://blog.aicent.com/no-stop-button-on-the-wire/ > (Chinese edition: https://blog.aicent.com/zh/no-stop-button-on-the-wire/ <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 <mailto:lee@aicent.com >
RTTP & IQA Organization
Author, draft-li-rttp-iqa-addressing
Resonant Time Transfer Protocol (RTTP, CRI 27)
Identity Quality Assurance (IQA, CRI 28)
Sites: https://rttp.com <https://rttp.com/ > · https://iqa.org <https://iqa.org/ >
------------------------------------------------------------------
From:Larry Lewis <llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>
Send Time:Thu, Oct 29, 2026, 13:35
To:ShaoBao Li<lee@aicent.com <mailto:lee@aicent.com >>
CC:Alan Karp<alanhkarp@gmail.com <mailto:alanhkarp@gmail.com >>; "public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>; Lars Kersten Kroehl<lars@moltrust.ch <mailto:lars@moltrust.ch >>; tima<tima@aeoess.com <mailto:tima@aeoess.com >>; ShaoBao Li<lee@iqa.org <mailto:lee@iqa.org >>
Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Hi 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:

 * 
Does the recipient satisfy the delegation policy when permission is delegated?

 * 
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 <mailto:lee@aicent.com >>
To: "Alan Karp"<alanhkarp@gmail.com <mailto:alanhkarp@gmail.com >>
Cc: "public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>, "Lars Kersten Kroehl"<lars@moltrust.ch <mailto:lars@moltrust.ch >>, "llewis"<llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>, "tima"<tima@aeoess.com <mailto:tima@aeoess.com >>, "ShaoBao Li"<lee@iqa.org <mailto: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 <mailto:lee@aicent.com >
RTTP & IQA Organization
Author, draft-li-rttp-iqa-addressing
Resonant Time Transfer Protocol (RTTP, CRI 27)
Identity Quality Assurance (IQA, CRI 28)
Sites: https://rttp.com <https://rttp.com/ > · https://iqa.org <https://iqa.org/ >
------------------------------------------------------------------
From:Alan Karp <alanhkarp@gmail.com <mailto:alanhkarp@gmail.com >>
Send Time:Thu, Oct 29, 2026, 05:26
To:ShaoBao Li<lee@aicent.com <mailto:lee@aicent.com >>
CC:"public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>; Lars Kersten Kroehl<lars@moltrust.ch <mailto:lars@moltrust.ch >>; llewis<llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>; tima<tima@aeoess.com <mailto:tima@aeoess.com >>; ShaoBao Li<lee@iqa.org <mailto:lee@iqa.org >>
Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
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 <mailto: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 <mailto:lee@aicent.com >
RTTP & IQA Organization
Author, draft-li-rttp-iqa-addressing
Resonant Time Transfer Protocol (RTTP, CRI 27)
Identity Quality Assurance (IQA, CRI 28)
Sites: https://rttp.com <https://rttp.com/ > · https://iqa.org <https://iqa.org/ >
------------------------------------------------------------------
From:Alan Karp <alanhkarp@gmail.com <mailto:alanhkarp@gmail.com >>
Send Time:Wed, Oct 28, 2026, 11:06
To:ShaoBao Li<lee@aicent.com <mailto:lee@aicent.com >>
CC:"public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>; Lars Kersten Kroehl<lars@moltrust.ch <mailto:lars@moltrust.ch >>; llewis<llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>; tima<tima@aeoess.com <mailto:tima@aeoess.com >>; ShaoBao Li<lee@iqa.org <mailto:lee@iqa.org >>
Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
I don't understand the "interpreter and the clock disagree" question.
--------------
Alan Karp
On Tue, Oct 27, 2026 at 7:32 PM ShaoBao Li <lee@aicent.com <mailto:lee@aicent.com >> wrote:
Alan,
Worth exploring, and we should first note where we already agree: we decline to standardize policy text for the mirror-image of your reason — enumerating the "Please"s we happened to think of first would close an open set. Nothing in the schemes stands in the way of your experiment, either: an authorization envelope is a calling-layer artifact, and nothing prevents one from carrying its mandate in natural language today. Which interpreter reads that mandate — a rule engine, a human, or an LLM — is the calling layer's choice, and the draft never claims that slot.
The line we would draw is between interpreting policy and reporting authority facts. The five-value refusal set of draft-li-rttp-iqa-addressing is not expressed policy; it is what clocks and revocation lists compute — a lease has expired or it has not, the authority was revoked or it was not. Probabilistic readers can argue about what a mandate permits; no reader can argue a timestamp into the future. If LLM-mediated interpretation works, it works one layer up, exactly where we already say policy lives.
The reason a refusal reason stays on the wire is auditability as replay: the answer must be bytes a third party can re-derive, and a model's reading is neither reproducible nor available in the modes the schemes are built for — air-gapped, degraded, store-and-forward, where there is no model to ask and fail-closed requires closed wire semantics. One question back: when the interpreter and the clock disagree, which one does the relying party audit against?
Best regards,
Lee
lee@aicent.com <mailto:lee@aicent.com >
RTTP & IQA Organization
Author, draft-li-rttp-iqa-addressing
Resonant Time Transfer Protocol (RTTP, CRI 27)
Identity Quality Assurance (IQA, CRI 28)
Sites: https://rttp.com <https://rttp.com/ > · https://iqa.org <https://iqa.org/ >
------------------------------------------------------------------
From:Alan Karp <alanhkarp@gmail.com <mailto:alanhkarp@gmail.com >>
Send Time:Wed, Oct 28, 2026, 09:58
To:ShaoBao Li<lee@aicent.com <mailto:lee@aicent.com >>
CC:"public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>; Lars Kersten Kroehl<lars@moltrust.ch <mailto:lars@moltrust.ch >>; llewis<llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>; tima<tima@aeoess.com <mailto:tima@aeoess.com >>
Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
LLMs ability to deal with natural language presents an opportunity to avoid defining standards for expressing policy or even the reason for rejection. Will it work? I have no idea, but I think it's an idea worth exploring.
--------------
Alan Karp
On Tue, Oct 27, 2026 at 6:15 PM ShaoBao Li <lee@aicent.com <mailto:lee@aicent.com >> wrote:
HI, Alan, colleagues,
You are right, and the gap is real: we know of no deployed system that carries the delegator's standing policy — your "Please" — as data a relying party could read. It is worth saying plainly that our schemes do not fill that slot either, and that the omission is deliberate.
The refusal reason field of Section 8 of our draft (draft-li-rttp-iqa-addressing, the series currently under ISE review) is a closed five-value set with a fixed priority order, and every value in it is an authority fact: the evidence did not match, the evidence expired, the authority could not be determined, the authority was revoked, the operation is not permitted. "Only within the company" is not an authority fact; it is a term of the grant or a preference of the delegator. The draft applies the same rule to policy text that it applies to action verbs — "this document deliberately defines no enumeration of verbs, because enumerating an open set would close it" (Section 7.1.1 of the same draft). A standard vocabulary of "Please"s would be closed by exactly the act of standardizing the ones we happened to think of first.
The place for the "Please" exists one layer up, in composing artifacts rather than in the verification answer. An authorization envelope carries the mandate — what the agent is asked to do, under what constraints, for how long; the Agent Authorization Envelope draft already circulating in this group is one such container, and revision -01 of our draft, posted 27 October, states the composition in its Section 12: an authorization envelope can name actions on rttp-addressed subjects and cite iqa attestations as evidence, and neither depends on the other. The verification answer stays small on purpose: whether the claimant stands, and which grant the answer relied on.
Your credential-sharing argument is, we think, independent support for the discipline the vocabulary already imposes: implementations MUST NOT emit values outside the set and MUST NOT reinterpret an emitted value to mean something else, and "a response that reports an outcome without its reason is not conformant: the reason is what makes a refusal auditable." An articulable refusal gives the blocked party something to read and correct; a silent block gives them something to route around. On that point we are entirely aligned.
What no artifact in this thread carries yet — ours included — is the second slot you named: a standard place for the reason a specific policy was violated. Policy vocabularies are deployments' own, open-ended, and belong to the calling layer, the same layer that owns action-time authorization, which the draft explicitly declines to claim. Naming that as an open question, the way you just did, is the right first move; standardizing it would be a larger project than this thread, and we make no promise about it here.
One housekeeping note for readers of the thread: the revision under ISE review is now draft-li-rttp-iqa-addressing-01 (posted 27 October 2026); the attestation-response vocabulary of Section 8 is I-D text, and the series page is https://datatracker.ietf.org/doc/draft-li-rttp-iqa-addressing/ <https://datatracker.ietf.org/doc/draft-li-rttp-iqa-addressing/ >.
Best regards,
Lee
lee@aicent.com <mailto:lee@aicent.com >
RTTP & IQA Organization
Author, draft-li-rttp-iqa-addressing
Resonant Time Transfer Protocol (RTTP, CRI 27)
Identity Quality Assurance (IQA, CRI 28)
Sites: https://rttp.com <https://rttp.com/ > · https://iqa.org <https://iqa.org/ >
------------------------------------------------------------------
From:Alan Karp <alanhkarp@gmail.com <mailto:alanhkarp@gmail.com >>
Send Time:Wed, Oct 28, 2026, 07:26
To:ShaoBao Li<lee@aicent.com <mailto:lee@aicent.com >>
CC:Lars Kersten Kroehl<lars@moltrust.ch <mailto:lars@moltrust.ch >>; "public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>; llewis<llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>; tima<tima@aeoess.com <mailto:tima@aeoess.com >>
Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Knowing why a request was rejected is useful. More useful is knowing the policy the delegator would like you to follow, e.g., only within the company. Most people (and agents) would obey your wishes if only they knew what they were. I have yet to see a system that has a place to put this information.
As an aside, that policy is stated as a "Please." Blocking a delegation that violates it leads to credential sharing, which means you'd also like a place to say why the policy is being violated.
--------------
Alan Karp
On Sat, Oct 24, 2026 at 1:00 PM ShaoBao Li <lee@aicent.com <mailto:lee@aicent.com >> wrote:
Lars, Tymofii, Larry, colleagues,
Thank you for the precise answers in your last note; both refinements make revision 3 concrete, and revision 3 on that basis has our support.
On the refusal reason: the value that matters is exactly the one you named — "the authority could not be determined." The fail-closed declaration you cited earlier in this thread names the behaviour rather than a substantive refusal, and we agree the result sheet must carry it as a value of its own. A record that folds unreachability into a substantive reason manufactures an intent nobody had; keeping the two apart is what makes third-party recomputation meaningful.
On the grant reference: naming the grant as it stood at the decision matches the anchoring our records already use — evidence carries its issue time, the verifier checks freshness against its own clock, and recomputation runs against the recorded state, not today's. A grant narrowed after the fact should not be able to change a recorded verdict; the format can simply make that impossible.
Revision 3 is therefore welcome on two fronts: it preserves the comparability of the frozen revision-2 records — our run and its sealed artifact stay pinned to the revision-2 digests, as you and Tymofii both noted — and it adds the two fields that make refusals auditable. When revision 3 lands, our runner will follow with revision-3 scoring, and the revision-2 record will stand as it is.
For the AAE vectors: the candidate route suits us, and we will run them under the same treatment the lease-revocation family received — digest-gated, per-mode and per-axis scoring, with the sealed-record format available if you want an artifact of record.
One housekeeping note from my post of Sat, 24 Oct 2026 22:44:14 +0800: the frozen vectors and the run-report format remain available as starting points for the common set, and the acceptance criteria still seem worth arguing here on the list rather than settled anywhere else. The offer stands.
Best regards,
Lee
lee@aicent.com <mailto:lee@aicent.com >
Author, draft-li-rttp-iqa-addressing-00 (ISE review)
Resonant Time Transfer Protocol (RTTP, CRI 27)
Identity Quality Assurance (IQA, CRI 28)
Sites: https://rttp.com <https://rttp.com/ > · https://iqa.org <https://iqa.org/ >
Blog: https://blog.aicent.com/ <https://blog.aicent.com/ >
------------------------------------------------------------------
From:Lars Kersten Kroehl <lars@moltrust.ch <mailto:lars@moltrust.ch >>
Send Time:Sun, Oct 25, 2026, 00:54
To:Tymofii Pidlisnyi<tima@aeoess.com <mailto:tima@aeoess.com >>
CC:"public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>; llewis<llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>; ShaoBao Li<lee@aicent.com <mailto:lee@aicent.com >>
Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Tymofii, Larry, Lee,
Tymofii, that would cover both. I would put it like this: The refusal reason should be able to say that the authority could not be determined — without that value, an implementation that never reached the source has to pick the nearest substantive reason, and the record then reads like a decision someone actually made.
The grant reference should identify the grant as it stood at the decision. A grant narrowed afterwards would otherwise recompute to a different answer than the one recorded, which is an awkward kind of mismatch to chase later.
Revision 3 on that basis works for me, and thank you for keeping revision 2 frozen — that keeps the existing runs comparable.
I will take the candidate route from CONTRIBUTING for the AAE vectors. The refusal reason also answers the taxonomy question I raised in the issue, which saves a separate discussion.
Looking forward to revision 3.
Lars
Am 24.10.2026 um 17:02 schrieb Tymofii Pidlisnyi <tima@aeoess.com <mailto:tima@aeoess.com >>:
Lars, Larry, Lee,
Lars, welcome, and thanks for offering the AAE vectors.
You're right about refusals. The family reports authority validity separately, but the action decision only says permit or deny. I propose adding a refusal reason and the grant reference to each decision record, so we can compare why implementations refused and which grant they evaluated.
Would that cover your two points? If so, I'll prepare revision 3 and keep revision 2 frozen for the existing runs.
Lars and Larry, vectors from AAE and ATP are welcome as candidates. The lab publishes a candidate after a short review, before anyone reproduces it, and admission as a reviewed fixture is a separate step. The route is in CONTRIBUTING.md at https://www.google.com/url?q=https://github.com/Agent-Authority-Conformance/aps-conformance-suite/blob/main/CONTRIBUTING.md&source=gmail&ust=1792940577687000&sa=E <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 <mailto:lee@aicent.com >> wrote:
Dear Larry, Tymofii, Chris, Lars, colleagues,
Thank you all for keeping this thread moving. In my mail of 21 October I stated where our two schemes stand on the three axes, and committed to running the lab's case family against our implementation; that run is now complete. As the shared test vectors head for review, this post records the run on the list, so that everything below is checkable by anyone.
The run used the frozen revision-2 vectors of the lease-revocation-axes family (https://github.com/Agent-Authority-Conformance/aps-conformance-suite/pull/180 <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 <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 <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/ <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 <mailto:lee@aicent.com >
Author, draft-li-rttp-iqa-addressing-00 (ISE review)
Resonant Time Transfer Protocol (RTTP, CRI 27)
Identity Quality Assurance (IQA, CRI 28)
Sites: https://rttp.com <https://rttp.com/ > · https://iqa.org <https://iqa.org/ >
Blog: https://blog.aicent.com/ <https://blog.aicent.com/ >
------------------------------------------------------------------
From:Larry Lewis <llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>
Send Time:Sat, Oct 24, 2026, 21:15
To:Lars Kersten Kroehl<lars@moltrust.ch <mailto:lars@moltrust.ch >>
CC:ShaoBao Li<lee@aicent.com <mailto:lee@aicent.com >>; "public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>; Tymofii Pidlisnyi<tima@aeoess.com <mailto:tima@aeoess.com >>; ShaoBao Li<lee@iqa.org <mailto:lee@iqa.org >>
Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Hi Lars, Tymofii, Lee, and colleagues,
Thank you, Lars, for joining the experiment and for the thoughtful suggestions regarding revocation outcomes and verifiable authority references.
I've been out of the office and am catching up, but I'm excited to see this collaboration moving forward.
Tymofii, I appreciate you opening the conformance work. We'll begin reviewing the shared test vectors and preparing ATP's implementation contributions.
Looking forward to working with everyone and helping move this effort forward.
Best regards,
Larry Lewis
Chair, Agent Trust Protocol Community Group
From: Lars Kersten Kroehl <lars@moltrust.ch <mailto:lars@moltrust.ch >>
To: "ShaoBao Li"<lee@aicent.com <mailto:lee@aicent.com >>
Cc: "Larry Lewis"<llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>, "public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>, "Tymofii Pidlisnyi"<tima@aeoess.com <mailto:tima@aeoess.com >>, "ShaoBao Li"<lee@iqa.org <mailto:lee@iqa.org >>
Date: Sat, 24 Oct 2026 07:06:12 -0500
Subject: Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Larry, Lee, Tymofii,
I'm Lars, author of the Agent Authorization Envelope (draft-kroehl-agentic-trust-aae), which covers delegation and revocation. Count us in for the experiment if you like — we can run the T=0/10/30/60/119 sequence as you set it out, and I can put delegation and revocation test vectors into a common set.
One suggestion for the reporting criteria, if useful. Lee's fail-closed answer for the unreachable case already names the behaviour, and the result sheet should be able to show it. If a run records only permitted or refused, an implementation that refused because the authority was revoked and one that refused because it could not determine the authority come out looking the same. Keeping those apart, alongside the per-mode and per-axis scoring already proposed, would show which is which.
For the same reason it helps if each recorded decision names the authority it was taken under, so a third party can recompute it.
Looking forward to it.
Lars 
Am 21.10.2026 um 22:19 schrieb ShaoBao Li <lee@aicent.com <mailto:lee@aicent.com >>:
Dear Larry, Tymofii,
Yes to the experiment — and it is worth pausing on how it arrived: the same timeline, the same variant with the revocation service unreachable, proposed independently from two different layers within hours of each other. That is the best evidence yet that the row our Q3 asked about is real: it is being felt from the delegation side and from the enforcement side at once, and neither of you needed the other's vocabulary to draw it.
Answering the direct question about the three axes, for the rttp and iqa schemes (draft-li-rttp-iqa-addressing-00, in ISE review; provisionally registered at IANA as CRI 27 and CRI 28; public entries at https://rttp.com <https://rttp.com/ >and https://iqa.org <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 <mailto:lee@aicent.com >
Author, draft-li-rttp-iqa-addressing-00 (ISE review)
Resonant Time Transfer Protocol (RTTP, CRI 27) · Identity Quality Assurance (IQA, CRI 28)
Sites: https://rttp.com <https://rttp.com/ > · https://iqa.org <https://iqa.org/ >
Blog: https://blog.aicent.com/ <https://blog.aicent.com/ >
------------------------------------------------------------------
From:Larry Lewis <llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >>
Send Time:Thu, Oct 22, 2026, 02:03
To:ShaoBao Li<lee@aicent.com <mailto:lee@aicent.com >>
CC:Tymofii Pidlisnyi<tima@aeoess.com <mailto:tima@aeoess.com >>; "public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>; ShaoBao Li<lee@iqa.org <mailto:lee@iqa.org >>
Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Dear Lee, Tymofii, and AI Agent Protocol Community Group,