- From: Larry Lewis <llewis@sovrlabs.com>
- Date: Mon, 26 Oct 2026 01:11:40 -0500
- To: "Larry Lewis" <llewis@sovrlabs.com>
- Cc: "Tymofii Pidlisnyi" <tima@aeoess.com>, "public-agentprotocol" <public-agentprotocol@w3.org>, "lee" <lee@aicent.com>, "lars" <lars@moltrust.ch>
- Message-Id: <1a176d6066a.4b0011b3310193.5632143768691433806@sovrlabs.com>
Hi Tymofii, Lars, Lee, and colleagues,
A brief update on our ATP contribution: we have completed an author-produced comparison against revision 3 in the live-standing-read profile with an exclusive endpoint.
Across 44 calls, all action decisions and mapped refusal reasons agree. Two grant-reference timestamps differ because our evaluator rejects an out-of-scope operation before consulting status.
We have also reproduced a separate experimental ordering that matches all 44 grant references. It preserves the decision outcomes in 216 additional combinations, but changes some refusal reasons and increases status consultations.
The interpretation questions are recorded in https://github.com/Agent-Authority-Conformance/aps-conformance-suite/issues/192 . Tymofii, your clarification on the required observation behavior and refusal precedence would help us determine the appropriate next step.
Revision 2 remains unchanged. These results cover one synthetic profile and are author-produced; they are separate from our testing environment’s runtime enforcement evidence. We can provide the reproducible package for review.
Thank you for the collaboration.
Best regards,
Larry Lewis
Chair, Agent Trust Protocol Community Group / ATP implementation contributor
Sovr INC
From: Larry Lewis <llewis@sovrlabs.com>
To: "Tymofii Pidlisnyi"<tima@aeoess.com>
Cc: "public-agentprotocol"<public-agentprotocol@w3.org>, "lee"<lee@aicent.com>, "lars"<lars@moltrust.ch>
Date: Sun, 25 Oct 2026 21:10:53 -0500
Subject: Re: Re: Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Hi Tymofii, Lars, Lee, and colleagues,
We have prepared ATP’s author-produced revision-3 comparison: 44/44 action decisions and refusal reasons match, with 42/44 grant references matching.
The two differences arise because ATP’s synthetic evaluator rejects an out-of-scope operation before consulting status, so it records no status-observation timestamp. We’ve raised the contract and refusal-precedence questions in https://github.com/Agent-Authority-Conformance/aps-conformance-suite/issues/192 .
The implementation mapping and reproduction instructions are in https://github.com/agent-trust-protocol/atp-core/pull/173 . The disagreements remain disclosed; this is not a conformance claim, and execution enforcement is outside this comparison.
We welcome your clarification and review.
Blessings,
Larry Lewis
Chair, Agent Trust Protocol Community Group, W3C Community Groups
From: Tymofii Pidlisnyi < mailto:tima@aeoess.com >
To: < mailto:public-agentprotocol@w3.org >
Cc: < mailto:lee@aicent.com >, < mailto:lars@moltrust.ch >, < mailto:llewis@sovrlabs.com >
Date: Sun, 25 Oct 2026 19:54:29 -0500
Subject: Re: Re: Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Lee,
Thanks for taking the independent run on #190 and for the credit in the post.
I approved the #187 checks today. Once they pass on the current head, I'll merge it, and your revision 3 record can follow.
Tymofii
On Sun, Oct 25, 2026 12:57 PM, ShaoBao Li < mailto:lee@aicent.com > wrote:
Lars, Tymofii, Larry, colleagues,
— three items from the repository record, brought back to the list where the record lives.
First, the fixture question we put to the list is answered. On #189 Lars wrote: "The verifier reads the instant from the fixture and never calls the clock, so the expected decision comes out the same on any machine and at any time." Absolute, stated in the vector, with the offset declined for the reason we would have given ourselves: "An offset would need an anchor both sides agree on, which adds a dependency a fixture does not need." That closes the loop cleanly — the same determinism our runner enforces over bytes now extends over time, and no shared anchor enters through the back door.
We also note with thanks the agreement on record that the taxonomy is Tymofii's call and the acceptance criteria belong on this list; that division stands exactly as argued.
Second, #190 ("candidates: add moltycel-aae-vectors") is welcome, and it follows the candidate route Lars set out on this list. The filing practices what the lab's own record rules preach: the bytes are pinned (MoltyCel/aae-conformance-vectors at 6bb462f, CHECKSUMS.sha256 with 64 entries, verified against a fresh clone with sockets refused); the deviations are stated, not smoothed over; and the evidence line says plainly, "Author-produced only ... No independent run exists."
That last sentence matters most to us: it names the empty seat instead of letting it be assumed — and ours is the name on it, as committed in my post of 25 October: the candidate will be run under the same treatment the lease-revocation family received.
Third, revision 3 itself is meanwhile mainline: #191 was merged on October 25, and we take that work as committed — the independent runner will be extended in a new sealed cut, re-run across the profile combinations, and the record filed the same way as before.
One sequencing note: our interop record (#187) is still in review, and the revision 3 record will follow once it has cleared review and merged — one open record at a time keeps review reviewable. No dates promised; the discipline is the promise.
One housekeeping norm, stated once and for future runs: 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.
One further register, now in writing: we have published a piece that sets the three registers side by side — the draft's MUST, the vectors' class, the wall's semantics — crediting each source in its own name, yours included: https://blog.aicent.com/q13-fail-closed-three-registers/ (English) · https://blog.aicent.com/zh/q13-fail-closed-three-registers/ (Chinese). The thanks on this thread are not only spoken here; they are citable.
Best regards,
Lee
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://iqa.org/
Blog: https://blog.aicent.com/
------------------------------------------------------------------
From:Tymofii Pidlisnyi < mailto:tima@aeoess.com >
Send Time:Mon, Oct 26, 2026, 02:09
To:"public-agentprotocol"< mailto:public-agentprotocol@w3.org >
CC:lars< mailto:lars@moltrust.ch >; ShaoBao Li< mailto:lee@aicent.com >; llewis< mailto:llewis@sovrlabs.com >
Subject:Re: Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity
Lars, Lee, Larry,
Revision 3 is proposed in https://www.google.com/url?q=https://github.com/Agent-Authority-Conformance/aps-conformance-suite/pull/191&source=gmail&ust=1793038147384000&sa=E
It adds refusal_reason so an authority source we couldn't check is not recorded as revoked, and grant_ref to identify the grant evidence and observation used for the decision.
The five refusal reasons and their precedence apply to this family. Revision 2 is unchanged.
The AAE validity-widening fixture in #189 is separate.
On the clock question, this family uses synthetic milliseconds. Every event and evaluation instant is in the input, so replay doesn't depend on the wall clock. The native AAE fixture will use an absolute timestamp.
Tymofii
On Sun, Oct 25, 2026 01:33 AM, ShaoBao Li < mailto:lee@aicent.com > wrote:
Lars, Tymofii, Larry, colleagues
— you opened issue #189 on the lab repository ( https://github.com/Agent-Authority-Conformance/aps-conformance-suite/issues/189 ); so that this list carries the whole record, your two points, quoted: "I can supply a fixture for that case with the evaluation instant pinned in the vector, so the expected decision no longer depends on when it runs," and "Our set reports revocation_status_indeterminate as a rejection reason distinct from ancestor_revoked, and the existing taxonomy does not carry that class. Hence the question before a PR." The first is mechanics and belongs in the repository; the second is an acceptance question, and per our post of Sat, 24 Oct 2026 22:44:14 +0800 the acceptance criteria for the common set are argued here rather than settled anywhere else.
We answered briefly on #189 earlier today so the mechanics thread would not stall; our words there, quoted for the record: "it is the taxonomic form of an argument this thread already carries, not a new question," with the boundaries that "the schema and taxonomy call belongs to @aeoess" and the common-set criteria "are argued on the list rather than settled here." This post is the full version of that answer, on the venue where it belongs.
On the class itself, the provenance is already on this list and needs no re-derivation. On 22 October (post 0015) we pre-registered the unreachable case — "an organ that cannot be reached is not read as silent consent" — and in my last post the point was made in full: "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." Lars put it on record himself, in the opening mail quoted here (post 0027): "Lee's fail-closed answer for the unreachable case already names the behaviour." So the class is our position with a second, independent expression in data — which is exactly what a conformance taxonomy should want.
On the pinned evaluation instant: welcome, and it completes a loop we care about. Our runner already refuses to score any vector file whose SHA-256 is not pinned in its manifest — determinism over bytes. A pinned instant extends the same guarantee over time: same bytes, same instant, same verdict, on any machine, forever. A score that moves with the clock is not a score; it is a reading.
On the runner follow-up I committed to in my last post, concretely: when revision 3 lands — the validity-widening case and, if the maintainer adopts it, the indeterminate class — we will extend our independent runner in a new sealed cut, re-run it across the profile combinations, and file the record the same way as before: frozen inputs behind digest gates, a sealed artifact, and an address pair derived from the artifact's own digest. No dates promised; the discipline is the promise.
On the AAE candidate set: as stated in my last post, it is welcome into the common set — and with the sealed-record format available if you want an artifact of record. The order of operations is the maintainer's to rule on first (the schema question in #189 is Tymofii's call, and we keep it that way); once ruled, any independent runner can score the candidate, and the acceptance debate happens here.
One clarifying question for the list, since it decides how fixtures should be written from now on: should a pinned evaluation instant be an absolute timestamp, or an offset from a recorded anchor? The former replays anywhere with no shared state; the latter needs an anchor both sides agree on — which is a small instance of the very question this thread started with.
Best regards,
Lee
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://iqa.org/
Blog: https://blog.aicent.com/
------------------------------------------------------------------
From:Lars Kersten Kroehl < mailto:lars@moltrust.ch >
Send Time:Sun, Oct 25, 2026, 00:54
To:Tymofii Pidlisnyi< mailto:tima@aeoess.com >
CC:"public-agentprotocol"< mailto:public-agentprotocol@w3.org >; llewis< mailto:llewis@sovrlabs.com >; ShaoBao Li< 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 < 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
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 < 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 , 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
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://iqa.org/
Blog: https://blog.aicent.com/
------------------------------------------------------------------
From:Larry Lewis < mailto:llewis@sovrlabs.com >
Send Time:Sat, Oct 24, 2026, 21:15
To:Lars Kersten Kroehl< mailto:lars@moltrust.ch >
CC:ShaoBao Li< mailto:lee@aicent.com >; "public-agentprotocol"< mailto:public-agentprotocol@w3.org >; Tymofii Pidlisnyi< mailto:tima@aeoess.com >; ShaoBao Li< 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 < mailto:lars@moltrust.ch >
To: "ShaoBao Li"< mailto:lee@aicent.com >
Cc: "Larry Lewis"< mailto:llewis@sovrlabs.com >, "public-agentprotocol"< mailto:public-agentprotocol@w3.org >, "Tymofii Pidlisnyi"< mailto:tima@aeoess.com >, "ShaoBao Li"< 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 < 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/ and 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
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://iqa.org/
Blog: https://blog.aicent.com/
------------------------------------------------------------------
From:Larry Lewis < mailto:llewis@sovrlabs.com >
Send Time:Thu, Oct 22, 2026, 02:03
To:ShaoBao Li< mailto:lee@aicent.com >
CC:Tymofii Pidlisnyi< mailto:tima@aeoess.com >; "public-agentprotocol"< mailto:public-agentprotocol@w3.org >; ShaoBao Li< 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
Received on Monday, 26 October 2026 06:12:02 UTC