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

Dear Larry, Tymofii, Chris, Lars, colleagues,
Thank you all for keeping this thread moving. In my mail of 21 October I stated where our two schemes stand on the three axes, and committed to running the lab's case family against our implementation; that run is now complete. As the shared test vectors head for review, this post records the run on the list, so that everything below is checkable by anyone.
The run used the frozen revision-2 vectors of the lease-revocation-axes family (https://github.com/Agent-Authority-Conformance/aps-conformance-suite/pull/180, corpus commit b745d25; re-verified against the PR head, 86e5e7a, on 24 October — the frozen inputs are unchanged). The vectors digest (sha256 a0a07ea58bcacfd056cbd648e03de4ff14778aa151e8b5d2574e43e31a111ed8) is a hard gate: the runner refuses to score anything else, and the gate was verified negatively — a tampered copy is rejected before any scoring occurs. The runner is an independent stdlib-only Python implementation (code as run: 8cb2e241419cd03d9be40c5977e0e9caa1d723a4, under https://github.com/Aicent-Stack/conformance); it declares three axes — evidence freshness: claimed; authority validity: claimed; action-time authorization: not claimed (by design).
Results: 48/48 baseline runs matched (4 profiles × 12 cases — two lease modes × two boundary policies), across 176 calls, 528 scored axis comparisons and 176 composite comparisons; all 12 mutation probes matched their pinned failure sets; 20/20 post-expiry diagnostic runs were clean, every emitted diagnostic backed by an actual recorded read; 12/12 hand-reasoned oracle checkpoints agreed; and all five reporting-semantics checks are true — executed, not asserted. Three consecutive runs on 24 October produced byte-identical reports. No suspected defective vectors were observed.
Our run is author-produced by the lab's definitions — Mode B, labeled as such in the report; the implementation is independent of the lab's code, but the filer is the author, and the record says so. Tymofii's independent reproduction review of 23 October (PR #180 comment) surfaced two reporting defects, both fixed in the corrected revision (rev c). The disagreements along the way are documented rather than disputed.
The interoperability package was submitted to the lab on 24 October as PR #187 (https://github.com/Agent-Authority-Conformance/aps-conformance-suite/pull/187, under review). The sealed artifact of record (lra-runner-20261023c.tar.gz, sha256 94bbaf3c292abf69595bf5782d1db8cbb4178536d53182578b46cff94a5c4b15) is published at https://iqa.org/conformance/lra-runner/ and carries two addresses derived from its own digest — nothing invented, nothing registered, both resolve live now:
- rttp://94bbaf3c.conformance.iqa — the question side (WHERE + WHEN); intent = first 8 hex of the artifact digest
- iqa://94bbaf3c292abf69595bf5782d1db8cb.forge.iqa — the answer side (WHETHER); subject = first 32 hex of the same digest
Everything above can be recomputed from the pinned digests without contacting us.
On next steps: the frozen vectors and the run-report format are both available as starting points for the common vector set proposed in this thread — and we would rather see the acceptance criteria argued on this list than settled anywhere else. Lars — your two reporting-criteria suggestions are received and substantive; they deserve more than a footnote, and I will respond to them in a separate post.
Best regards,
Lee
lee@aicent.com
Author, draft-li-rttp-iqa-addressing-00 (ISE review)
Resonant Time Transfer Protocol (RTTP, CRI 27)
Identity Quality Assurance (IQA, CRI 28)
Sites: https://rttp.com · https://iqa.org
Blog: https://blog.aicent.com/
------------------------------------------------------------------
From:Larry Lewis <llewis@sovrlabs.com>
Send Time:Sat, Oct 24, 2026, 21:15
To:Lars Kersten Kroehl<lars@moltrust.ch>
CC:ShaoBao Li<lee@aicent.com>; "public-agentprotocol"<public-agentprotocol@w3.org>; Tymofii Pidlisnyi<tima@aeoess.com>; ShaoBao Li<lee@iqa.org>
Subject:Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Hi Lars, Tymofii, Lee, and colleagues,
Thank you, Lars, for joining the experiment and for the thoughtful suggestions regarding revocation outcomes and verifiable authority references.
I've been out of the office and am catching up, but I'm excited to see this collaboration moving forward.
Tymofii, I appreciate you opening the conformance work. We'll begin reviewing the shared test vectors and preparing ATP's implementation contributions.
Looking forward to working with everyone and helping move this effort forward.
Best regards,
Larry Lewis
Chair, Agent Trust Protocol Community Group
From: Lars Kersten Kroehl <lars@moltrust.ch>
To: "ShaoBao Li"<lee@aicent.com>
Cc: "Larry Lewis"<llewis@sovrlabs.com>, "public-agentprotocol"<public-agentprotocol@w3.org>, "Tymofii Pidlisnyi"<tima@aeoess.com>, "ShaoBao Li"<lee@iqa.org>
Date: Sat, 24 Oct 2026 07:06:12 -0500
Subject: Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Larry, Lee, Tymofii,
I'm Lars, author of the Agent Authorization Envelope (draft-kroehl-agentic-trust-aae), which covers delegation and revocation. Count us in for the experiment if you like — we can run the T=0/10/30/60/119 sequence as you set it out, and I can put delegation and revocation test vectors into a common set.
One suggestion for the reporting criteria, if useful. Lee's fail-closed answer for the unreachable case already names the behaviour, and the result sheet should be able to show it. If a run records only permitted or refused, an implementation that refused because the authority was revoked and one that refused because it could not determine the authority come out looking the same. Keeping those apart, alongside the per-mode and per-axis scoring already proposed, would show which is which.
For the same reason it helps if each recorded decision names the authority it was taken under, so a third party can recompute it.
Looking forward to it.
Lars 
Am 21.10.2026 um 22:19 schrieb ShaoBao Li <lee@aicent.com <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,
Thank you, Lee, for sharing your review of the Agentic Web technical report and for presenting four thoughtful questions concerning identity assurance, addressing, trust freshness, and interoperability.
I also appreciate Tymofii's response regarding delegation expiry and revocation in the Agent Passport System (APS).
From the perspective of the Agent Trust Protocol (ATP) Community Group, I believe this discussion highlights an important opportunity for collaboration across the emerging agentic web ecosystem.
Trust is not a single mechanism or verification event. It involves multiple layers of identity, evidence, authority, policy enforcement, revocation, and accountability.
I would like to share a few observations concerning the four questions and propose a practical way for our respective projects to explore them together.
Q1 - Preimage Defense and Identity Substitution
I agree that demonstrating cryptographic key control does not necessarily establish the legitimacy or continuity of an agent's claimed authority.
We should distinguish between verifying a DID document, establishing its provenance, determining whether its verification methods remain valid, and ensuring that the identity presented corresponds to the authority expected by the receiving agent.
This raises useful interoperability test cases involving identity-document substitution, compromised verification methods, key rotation, and conflicting authority claims.
Q2 - Address Assurance
Separating addressing from discovery is worth examining.
Deterministically derived addresses can provide useful properties, but address integrity should not be confused with proof of legitimate ownership or authorization.
I would be interested in exploring how RTTP-derived addressing interacts with DID resolution, existing agent discovery mechanisms, and independent authority verification.
Q3 - Trust Leases, Freshness, and Revocation
This question is particularly relevant to ATP's work on delegated authority and runtime enforcement.
ATP distinguishes between trust evidence and authorization. A credential or statement may remain cryptographically valid while its underlying authority has expired, been revoked, or become insufficient for a particular action.
Tymofii raises an important point: a 120-second freshness lease could allow previously verified evidence to remain within its accepted freshness window even after revocation.
We should therefore distinguish at least three concepts:

 * 
Evidence freshness — how recently the statement or credential was verified.

 * 
Authority validity — whether the delegation remains valid and unrevoked.

 * 
Action-time authorization — whether the requested operation is currently permitted under the applicable constraints and policies.
I would welcome further clarification regarding how RTTP/IQA handles revocation within an active freshness window, particularly when revocation information is unavailable or delayed.
For ATP, this distinction is central to our approach: trust evidence informs authorization, but possession of valid evidence does not automatically grant permission to act.
Q4 - Statement-Level and Platform-Level Interoperability
I see these approaches as potentially complementary rather than mutually exclusive.
Statement-level verification can support portable, independently verifiable evidence across systems. Platform-level infrastructure can provide additional operational services, governance, policy administration, and trust coordination.
The important architectural question is whether independently operated agents can verify the evidence and enforce the appropriate authority without depending on a particular commercial platform.
This is an area where I believe cooperation between our projects could produce useful implementation evidence.
Proposal — A Joint Trust Interoperability Experiment
Rather than limiting the discussion to architectural comparisons, I would like to propose a small, collaborative technical exercise involving RTTP/IQA, APS, and ATP.
We could begin with the trust-lease and revocation scenario raised by Tymofii:

 * 
T=0: An agent receives valid identity and authorization evidence.

 * 
T=10 seconds: The issuing authority revokes the relevant delegation or statement.

 * 
T=30, T=60, and T=119 seconds: The agent attempts an operation requiring that authority.

 * 
Each implementation evaluates the requests according to its own documented verification and enforcement mechanisms.

 * 
We compare the decisions, verification evidence, revocation handling, and limitations.
We should also examine what happens when the revocation service is temporarily unavailable and whether the receiving system can independently establish the authority needed to perform the action.
The goal would not be to determine which protocol is superior or to require any project to adopt another project's architecture.
Instead, we could establish a common set of security properties, test vectors, and reporting criteria while allowing each implementation to demonstrate its respective responsibilities.
Importantly, a mechanism that does not claim to provide action authorization should not be evaluated as though it does. Its contribution and boundaries should be documented separately.
Publishing the Results
If there is interest, I suggest publishing the agreed test definitions and implementation results openly so other contributors can reproduce, evaluate, and extend them.
This could help the community better understand:

 * 
Which trust guarantees are already implemented.

 * 
Which mechanisms complement one another.

 * 
Where interoperability boundaries exist.

 * 
What gaps require additional specification work.

 * 
Which security properties can be independently verified across different agent systems.
From ATP's perspective, our interest is in helping establish portable, verifiable, revocable, and enforceable trust mechanisms that can operate across agent frameworks and organizational boundaries.
I believe this is an opportunity for the community to advance the technical foundations of the agentic web collectively.
I would welcome both Lee's and Tymofii's thoughts on this approach, as well as feedback from other Community Group participants.
Thank you again for contributing to this important conversation.
Best regards,
Larry Lewis
Chair, Agent Trust Protocol Community Group
W3C Community Groups
llewis@sovrlabs.com <mailto:llewis@sovrlabs.com >
From: ShaoBao Li <lee@aicent.com <mailto:lee@aicent.com >>
To: "Tymofii Pidlisnyi"<tima@aeoess.com <mailto:tima@aeoess.com >>, "public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>
Cc: "ShaoBao Li"<lee@iqa.org <mailto:lee@iqa.org >>
Date: Wed, 21 Oct 2026 12:42:37 -0500
Subject: Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Hi Tymofii,
Thank you for reading Q3 closely, and for the sharpest counterexample in the thread so far: an action in second 119 leaning on a statement its issuer revoked in second 10 is exactly the case worth pinning down.
The short answer: in our design the lease bounds the exposure, it does not eliminate it — and we say so rather than hide it.
Three mechanisms make that bound useful. First, default revocation is non-renewal: in Identity Quality Assurance (IQA), trust is re-earned every 120 seconds or it lapses, so the cheapest revoke an issuer can perform is to stop re-attesting, and the statement ages out at the next lease boundary — worst-case exposure equals the lease length itself, explicit and tunable per deployment, the same tradeoff class as bounded credential caches, accepted in exchange for verification that completes offline with no per-action network dependency.
Second, explicit revocation is a first-class action, not an out-of-band promise: the iqa scheme defines a closed set of four actions — verify, audit, attest, revoke (draft-li-rttp-iqa-addressing-00, Section 5.4) — where revoke is specified as withdrawing the subject's standing, a state transition at the named organ, moving the subject toward ghost in the closed four-state set (ghost, probation, radiant, genesis); propagation to any given reader happens at that reader's next standing read.
Third, the lease is a floor, not a ceiling: for actions whose risk profile cannot tolerate the window, the verifier does what your Agent Passport System does — it runs the check at the moment of action, as a live standing read (iqa://<subject>.<organ>.<root>/verify) instead of trusting the cached lease. Cached-lease verification and live standing reads are both legal clients of the same signed statements; the deployment picks per action class, and the protocol does not pretend the choice away.
So the honest formulation is: Resonant Time Transfer Protocol (RTTP) does not push revocations inside the window; it prices the window. The 120-second lease makes staleness a named, bounded cost, and hands the verifier a live-escape hatch when a given action cannot pay it.
I would also note the convergence rather than the difference: your APS runs the check at the action, ours re-earns the trust at the lease boundary — both are bounded exposures, with different bounds and different trust roots (monotonic delegation chains versus derived addresses plus signed statements). That maps onto our Q4: delegation-chain enforcement and statement-level verification look complementary rather than rival — a delegation could carry an IQA statement as one of its narrowing dimensions without either layer borrowing the other's authority.
We will record this exchange as an adopted refinement of our public hand-in (https://blog.aicent.com/four-answers/ <https://blog.aicent.com/four-answers/ >): a lease bounds staleness; a live standing read closes high-stakes windows. If you spot an error in the above, say so on the list and we will adopt the correction in public — that is the standing offer the four questions came with.
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)
Blog: https://blog.aicent.com/ <https://blog.aicent.com/ >
------------------------------------------------------------------
From:Tymofii Pidlisnyi <tima@aeoess.com <mailto:tima@aeoess.com >>
Send Time:Thu, Oct 22, 2026, 00:52
To:"public-agentprotocol"<public-agentprotocol@w3.org <mailto:public-agentprotocol@w3.org >>
CC:ShaoBao Li<lee@aicent.com <mailto:lee@aicent.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
Lee,
I'm Tymofii, author of Agent Passport System (draft-pidlisnyi-aps).
On Q3: in Agent Passport System a delegation carries its own expiry and can be revoked before it, and the check runs at the moment of action rather than when the statement is fetched. A 120-second lease bounds how stale a cached statement can be, but an action in second 119 can still rely on a statement its issuer revoked in second 10. How does rttp handle a revoke inside the lease window?
Tymofii
P.S. Stars are a vanity metric until a certification needs 100 of them. We're at 52.
Please ⭐️ APS: https://www.google.com/url?q=https://github.com/agent-passport-system/agent-passport-system&source=gmail&ust=1792687934666000&sa=E <https://www.google.com/url?q=https://github.com/agent-passport-system/agent-passport-system&source=gmail&ust=1792687934666000&sa=E >
On Wed, Oct 21, 2026 06:05 AM, ShaoBao Li <lee@aicent.com <mailto:lee@aicent.com >> wrote:
Dear AI Agent Protocol Community Group,
We are the authors of draft-li-rttp-iqa-addressing-00 (in ISE review), the specification behind two provisionally registered URI schemes at IANA: Resonant Time Transfer Protocol (rttp, CRI 27) and Identity Quality Assurance (iqa, CRI 28).
We read the Community Group's technical report on Agentic Web protocols (2026-09-24) line by line, and recorded our reading in a public review: https://aicent.com/blog/w3c-review/ <https://aicent.com/blog/w3c-review/ >
Our overall conclusion is positive: the report pushed the identity layer much further than the rest of the current stack, and its requirements list is honest about what remains open. We enter the discussion with four public questions rather than claims — each one is a gap we could not find an answer to, in the report or anywhere else.
Q1 — Preimage defense: DID documents answer "who holds the key" — but which layer answers preimage defense against impersonation of an in-use authority? Is detecting a swapped identity document a matter of protocol, or of luck?
Q2 — Address assurance: discovery depends on the discoverability of description documents — who vouches for the address of a description document itself? Should addressing be split out of "discovery" and specified as an independent layer?
Q3 — Trust leases: TLS certificates have validity periods — does an agent's trust have a lease? Which layer carries the freshness and expiry of statements?
Q4 — Granularity: must cross-platform interoperability take the "platform" as its unit (federated), or can it sink to the "statement" as its unit (registry-free)? Are the two granularities complementary?
We have also published our own first-pass answers to all four, so the questions do not hang unanswered on our side either: https://aicent.com/blog/four-answers/ <https://aicent.com/blog/four-answers/ > — offered as one hand-in among possible answers, not a claim to the last word.
For Q2 and Q3 we have handed in a concrete paper, published and independently verifiable: the address is derived (the first 16 bytes of SHA-256 over a canonical authority, shaped as rttp://<intent>.<pillar>.<root>/<action>), and every statement carries a 120-second freshness lease with a closed four-state set. The specification is at https://datatracker.ietf.org/doc/html/draft-li-rttp-iqa-addressing-00 <https://datatracker.ietf.org/doc/html/draft-li-rttp-iqa-addressing-00 > and the registry entries at https://www.iana.org/assignments/uri-schemes/prov/rttp <https://www.iana.org/assignments/uri-schemes/prov/rttp > and https://www.iana.org/assignments/uri-schemes/prov/iqa <https://www.iana.org/assignments/uri-schemes/prov/iqa >
We raise these questions because the report's requirements list is the most honest public statement of where the Agentic Web stack currently ends, and because we believe all four are answerable — possibly by the report's own mechanisms, possibly by complementary designs such as ours.
We would be glad to discuss any of the four asynchronously on this list, or to present briefly at one of the CG's biweekly meetings if the group finds it useful.
Best regards,
Lee
lee@aicent.com <mailto:lee@aicent.com >
Author, draft-li-rttp-iqa-addressing-00 (ISE review)
Resonant Time Transfer Protocol (RTTP) · Identity Quality Assurance (IQA)
Blog: https://aicent.com/blog/ <https://aicent.com/blog/ >