Subject: [W3C AI Agent CG] NTI-1 Core Hardened: Zero-Days Patched. Open Call for Security Vectors & Core PRs

Hi everyone,

This is a broadcast update for the entire working group.

I want to share a major update that proves exactly why an open, neutral
standard is so powerful.

Larry (@bigblackcoder) just submitted his Rust regression matrix, which
successfully caught two zero-day vulnerabilities in the NTI core engine
(unsigned capability acceptance and quorum bypass). I have merged his test
suite into the nti-spec repository, and he is currently applying the fix to
the core engine.

This is a massive milestone for the standard. The fact that a W3C Chair can
write a test that breaks the engine, and then patch the engine, proves that
NTI is not a static document—it is a living, self-healing protocol.

I also want to thank Chris (AlgoVoi) for committing his conformance harness
under the Apache 2.0 model. We now have a multi-language conformance suite
(Rust and Python) running against the engine.

A Call for Security Hardening & Core Integration:
I want to invite everyone in this group to share your thoughts, edge cases,
or new security features to tighten this standard. If you have code, test
vectors, or documentation that makes NTI stronger, please submit it.

If your code is perfect and gets merged into the spec, and you want to see
it running inside the actual NTI core engine, please remind me, open a PR
against Neutral-Trust-Infrastructure, and I will review and merge it. You
have the floor to build the most secure agent trust layer in the world.

The standard belongs to this community. The AIW on November 6th is almost
here. Let's get your PRs in and make your mark on the Agentic Web.

Repo: https://github.com/abisheakp197/nti-spec

Best,
Abisheak

On Sat, 31 Oct, 2026, 2:43 pm ShaoBao Li, <lee@aicent.com> wrote:

> *Colleagues, *
>
> — a companion note, not a new claim. Earlier today the October summary
> went on the record as post 0124; a restated version for a wider audience is
> now live on our blog, same figures, same addresses:
> https://blog.aicent.com/october-on-the-record/ (Chinese:
> https://blog.aicent.com/zh/october-on-the-record/).
>
> For readers of this thread: the exchange recorded here — the
> delegation-policy landscape (post 0097), the VOC experiment (post 0098),
> and our reply (post 0103) — is preserved in the same restatement, alongside
> a fuller treatment of the VOC exchange itself (
> https://blog.aicent.com/q21-the-exception-leaves-a-receipt/) and the four
> questions that opened our month in post 0009, quoted verbatim. The chain a
> reader can now walk in one page: four questions, one month of public
> exchange, two sealed run records, one summary. The bytes are the same
> bytes; only the room is larger.
>
> Best regards,
> Lee
> lee@aicent.com
> Author, draft-li-rttp-iqa-addressing-01 (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:ShaoBao Li <lee@aicent.com>
> Send Time:Fri, Oct 30, 2026, 10:17
> To:Alan Karp<alanhkarp@gmail.com>
> CC:"public-agentprotocol"<public-agentprotocol@w3.org>; llewis<
> llewis@sovrlabs.com>; Lars Kersten Kroehl<lars@moltrust.ch>; tima<
> tima@aeoess.com>; ShaoBao Li<lee@iqa.org>
> Subject:Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
>
> *Alan,*
> Your VOC experiment is the empirical twin of the refusal design we have
> been running: "explain to your manager why it should be allowed" is what an
> auditable refusal buys — the block stays a block, the reason for the
> exception becomes a readable, answerable record instead of a workaround,
> and the few percent who explained are the users the closed reason set and
> its receipt exist for. I would also note, as you did, that the word
> "manager" was critical: the exception is judged by an accountability layer,
> not by the protocol — the wire's job is only to make the judgment's inputs
> and its outcome bytes rather than opinions.
>
> On your two options: both are the delegator's judgment riding with the
> delegation, and I would keep them at that layer — a caveat in the
> delegation, in zcaps' vocabulary, rather than a new field in the
> verification layer. What the wire can add is the receipt side: when the
> second option is exercised, the record can carry which option was declared,
> the reason given, and the state the decision was computed over, so the
> exception is auditable after the fact — and the delegator learns from the
> receipt when the delegator chooses to look, not because the verifier
> pushes. That, I suspect, is also how the privacy property you flagged for
> zcaps survives: nothing is reported to anyone in real time; the bytes
> simply exist, addressed and sealed, for whoever is entitled to read them.
>
> If the delegator's two options are ever written down somewhere, our
> refusal vocabulary and grant reference would sit next to them naturally:
> the options say what the delegator wanted; the receipt says what actually
> happened and on what evidence.
>
>
> 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:Alan Karp <alanhkarp@gmail.com>
> Send Time:Fri, Oct 30, 2026, 07:46
> To:ShaoBao Li<lee@aicent.com>
> CC:"public-agentprotocol"<public-agentprotocol@w3.org>; Lars Kersten
> Kroehl<lars@moltrust.ch>; llewis<llewis@sovrlabs.com>; tima<
> tima@aeoess.com>; ShaoBao Li<lee@iqa.org>
> Subject:Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> I think it would be nice if the delegator could express its needs with one
> of two options.  "I don't know the policy, so don't honor this delegation
> if it violates it." versus "This delegation is really important.  Here's
> why you should honor it even if it violates policy. And, by the way, I'll
> share my credentials if you don't."  (Could be encoded as "1" or "2.")
>
> Many years ago we ran an experiment in a different context.  Typically,
> Data Loss Prevention (DLP) software blocks data transmissions that violate
> policy, such as sending confidential materials through the firewall.  The
> problem is that people found workarounds, the equivalent of sharing
> credentials.  We experimented with using DLP gently.  If, for example, an
> email to outside the company had a confidential attachment, we would pop a
> box saying, "This transfer violates company policy.  Explain to your
> manager why it should be allowed."  (The word "manager" was critical.)
> Most of the time, user's cancelled the email, but a few percent of the time
> they provided an explanation.  We allowed the transfer when they did.  We
> called the system Voluntary Oblivious Compliance (VOC) because it allowed
> you to voluntarily comply with a policy you were oblivious of.
>
> I'm trying to get something similar for delegations.
>
> --------------
> Alan Karp
>
>
> On Thu, Oct 29, 2026 at 3:18 PM ShaoBao Li <lee@aicent.com> wrote:
> *Alan,*
>
> With your correction in 0095, I believe the two positions now share the
> same deciding moment: the access policy is expressed when the delegation is
> made, and the condition is judged when the resource is invoked — which is
> the conclusion the wire reaches from the other direction: the condition may
> be the delegator's, but the freshness of the facts it consumes must be
> re-derivable at the moment of use, and that is exactly what the lease and
> its expiry timestamp exist to carry.
>
> Your retained concern about the race is the right one, and I would not
> claim the wire dissolves it — a revocation arriving just before or just
> after an invocation ends is a boundary no protocol can erase, so the wire's
> job is to make that boundary legible rather than pretend it away: the
> receipt records when the authority-side facts were effective and when they
> were observed, a read past expiry is answered as expired rather than
> replayed as fresh, and where the answer cannot arrive in time, residual
> semantics apply — the bytes state how old the claim is, so the caller
> decides with the age on the table instead of on a silent assumption.
>
> Your credential-sharing point is, to my mind, the strongest argument for
> the refusal design we have been running: if a refusal is fatal, sharing
> credentials becomes the rational shortcut, so refusals are made legible
> instead — a closed set of reasons with an auditable receipt lets the caller
> degrade, retry or reroute rather than crash, and attenuation survives
> precisely because a DENY can be read, re-derived by a third party, and
> answered to.
>
> 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:Alan Karp <alanhkarp@gmail.com>
> Send Time:Fri, Oct 30, 2026, 02:00
> To:ShaoBao Li<lee@aicent.com>
> CC:"public-agentprotocol"<public-agentprotocol@w3.org>; Lars Kersten
> Kroehl<lars@moltrust.ch>; llewis<llewis@sovrlabs.com>; tima<
> tima@aeoess.com>; ShaoBao Li<lee@iqa.org>
> Subject:Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> Forget my previous response.  I realized I had made a mistake just after
> sending it.  The following is the correct response.
>
> I've been discussing attenuated delegation with a W3C group, where someone
> asked, "When should you consider the status of a delegation?"  There are
> 3 relevant times: when the delegation is made, when the resource is
> invoked, and when that invocation ends.
>
> Clearly, access policy is used at the time of delegation, and verifying
> the delegation is done on invocation.  There are then 2 interesting
> questions - what if the delegation condition is no longer true at
> invocation, and what if it changes during execution,
>
> I worry about leaving the application in an inconsistent state if it's
> interrupted mid invocation, which leads me to favor using time of
> invocation as the deciding factor.  My excuse is that there is an
> unavoidable race between the steps and the state changes.  The person you
> delegated to might leave the company just after the invocation finishes or
> just before.  The same applies to revocation; the revocation request might
> reach the server just before the invocation finishes or just after.
>
> I recognize the risk of this choice.  Allowing execution to continue after
> conditions change can lead to problems but so can interrupting the
> application.  If there's a danger that your application will crash because
> of a refused delegation, you have an incentive to share credentials.
>
> --------------
> Alan Karp
>
>
> On Wed, Oct 28, 2026 at 4:10 PM ShaoBao Li <lee@aicent.com> wrote:
> *Alan,*
>
> Fair correction — I read "within the company" as a constraint on the
> action, and you meant a constraint on the delegation: to whom the
> permission may travel. The HP variant makes the difference concrete, and it
> is the more interesting half of the case: the leak you describe is not a
> policy misread but a delegation that reached a principal the condition was
> written to exclude.
>
> One observation on where that condition gets its inputs. Whether the
> delegatee is "within the company" can be as complicated as the label
> suggests — your external-accountant case shows the boundary is policy. But
> whatever the condition turns out to be, the facts it computes over are
> cheaper than the condition: who the delegatee is, and whether that
> delegatee's authority stands verified at the instant of use, are bytes a
> verifier returns, not opinions. A DENY computed over those facts is
> auditable the same way our refusal reasons are — a third party can
> re-derive it; a DENY computed over the label alone cannot.
>
> So the split I would propose is the one our two positions have been
> converging on anyway: the delegator's "Please" travels with the permission,
> unstandardized, one layer up; your DENY-if-any-condition-isn't-met executes
> in the calling layer; and the wire's job is to make the authority-side
> inputs of that decision checkable at the moment of use, not only at the
> moment of grant. Your delegatee with a good reason to violate the request —
> the internal program without credentials — is that layer's judgment call,
> not the wire's.
>
> Which leaves one question I suspect we see differently. Does "within the
> company" have to hold when the delegation is made, or at every later use?
> If the latter, the employee who leaves on day thirty is the mid-task case
> from my earlier note in this thread: the lease expires, the next
> verification returns authority_revoked, and the halt is armed by a
> timestamp the runtime has held since its first answer. The condition may be
> yours; the freshness of the facts it consumes has to come from somewhere,
> and I claim that somewhere is the wire.
>
>
> Best regards,
>
> Lee
> lee@aicent.com
> RTTP & IQA Organization
> Author, draft-li-rttp-iqa-addressing
> Resonant Time Transfer Protocol (RTTP, CRI 27)
> Identity Quality Assurance (IQA, CRI 28)
> Sites: https://rttp.com · https://iqa.org
> ------------------------------------------------------------------
> From:Alan Karp <alanhkarp@gmail.com>
> Send Time:Thu, Oct 29, 2026, 05:26
> To:ShaoBao Li<lee@aicent.com>
> CC:"public-agentprotocol"<public-agentprotocol@w3.org>; Lars Kersten
> Kroehl<lars@moltrust.ch>; llewis<llewis@sovrlabs.com>; tima<
> tima@aeoess.com>; ShaoBao Li<lee@iqa.org>
> Subject:Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> Your example doesn't capture my point.  When I said the condition is
> "within the company," I intended it to mean to whom you should delegate.
> Let me use a slight variant of an actual case.  One quarter HP had to
> release its financial statement early because a reporter was included on an
> email with a draft of it.  Change the example slightly to delegating access
> to the draft.
>
> We typically use labels, such as Company Confidential, to represent what
> might be a complicated policy.  (Should external accountants hired by the
> company be included?)  However you do it, it would be nice if the delegator
> could tell the delegatee (not a word but doesn't get confused with the verb
> delegate), what policies are appropriate for the permission.  It's a
> "Please" because the delegatee may have a good reason to violate the
> request, e.g., to delegate to an internal program that doesn't have
> credentials.
>
> As to your question about whether to honor the request, I would say DENY
> if any condition isn't met.
>
> --------------
> Alan Karp
>
>
> On Tue, Oct 27, 2026 at 8:25 PM ShaoBao Li <lee@aicent.com> wrote:
> *Alan,*
>
> That was too compressed on my side — here is the concrete case. An
> envelope says: "Book flights only within the company, through Friday." At
> Thursday 17:00 the calling layer's LLM reads that mandate and answers
> "permitted"; meanwhile the wire answer from an iqa verification says
> evidence_expired — the lease ran out at 16:00. Two records now exist: the
> interpreter's reading of the policy, and the deterministic authority fact.
> My question was: when they differ, which one does the relying party audit
> against?
>
> I suspect we would give the same answer — the wire record — because it is
> bytes a third party can re-derive from pinned inputs, while the model's
> reading is an opinion about what the mandate meant. That suggests a design
> rule rather than a fight: the interpreter consumes the wire answer as an
> input and ranks what is permitted within it; it never overrules it. Policy
> interpretation sorts choices among operations the authority layer has
> already allowed; it does not get a vote on WHETHER.
>
> If that matches your instinct, then your experiment and our vocabulary are
> not competitors: the LLM layer composes above the wire, the five-value
> refusal set survives it, and the "Please" stays exactly where we both said
> it lives — unstandardized, one layer up.
>
>
> Best regards,
>
> Lee
> lee@aicent.com
> RTTP & IQA Organization
> Author, draft-li-rttp-iqa-addressing
> Resonant Time Transfer Protocol (RTTP, CRI 27)
> Identity Quality Assurance (IQA, CRI 28)
> Sites: https://rttp.com · https://iqa.org
> ------------------------------------------------------------------
> From:Alan Karp <alanhkarp@gmail.com>
> Send Time:Wed, Oct 28, 2026, 11:06
> To:ShaoBao Li<lee@aicent.com>
> CC:"public-agentprotocol"<public-agentprotocol@w3.org>; Lars Kersten
> Kroehl<lars@moltrust.ch>; llewis<llewis@sovrlabs.com>; tima<
> tima@aeoess.com>; ShaoBao Li<lee@iqa.org>
> Subject:Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> I don't understand the "interpreter and the clock disagree" question.
>
> --------------
> Alan Karp
>
>
> On Tue, Oct 27, 2026 at 7:32 PM ShaoBao Li <lee@aicent.com> wrote:
> *Alan,*
>
> Worth exploring, and we should first note where we already agree: we
> decline to standardize policy text for the mirror-image of your reason —
> enumerating the "Please"s we happened to think of first would close an open
> set. Nothing in the schemes stands in the way of your experiment, either:
> an authorization envelope is a calling-layer artifact, and nothing prevents
> one from carrying its mandate in natural language today. Which interpreter
> reads that mandate — a rule engine, a human, or an LLM — is the calling
> layer's choice, and the draft never claims that slot.
>
> The line we would draw is between interpreting policy and reporting
> authority facts. The five-value refusal set of draft-li-rttp-iqa-addressing
> is not expressed policy; it is what clocks and revocation lists compute — a
> lease has expired or it has not, the authority was revoked or it was not.
> Probabilistic readers can argue about what a mandate permits; no reader can
> argue a timestamp into the future. If LLM-mediated interpretation works, it
> works one layer up, exactly where we already say policy lives.
>
> The reason a refusal reason stays on the wire is auditability as replay:
> the answer must be bytes a third party can re-derive, and a model's reading
> is neither reproducible nor available in the modes the schemes are built
> for — air-gapped, degraded, store-and-forward, where there is no model to
> ask and fail-closed requires closed wire semantics. One question back: when
> the interpreter and the clock disagree, which one does the relying party
> audit against?
>
>
> Best regards,
>
> Lee
> lee@aicent.com
> RTTP & IQA Organization
> Author, draft-li-rttp-iqa-addressing
> Resonant Time Transfer Protocol (RTTP, CRI 27)
> Identity Quality Assurance (IQA, CRI 28)
> Sites: https://rttp.com · https://iqa.org
> ------------------------------------------------------------------
> From:Alan Karp <alanhkarp@gmail.com>
> Send Time:Wed, Oct 28, 2026, 09:58
> To:ShaoBao Li<lee@aicent.com>
> CC:"public-agentprotocol"<public-agentprotocol@w3.org>; Lars Kersten
> Kroehl<lars@moltrust.ch>; llewis<llewis@sovrlabs.com>; tima<
> tima@aeoess.com>
> Subject:Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> LLMs ability to deal with natural language presents an opportunity to
> avoid defining standards for expressing policy or even the reason for
> rejection.  Will it work?  I have no idea, but I think it's an idea worth
> exploring.
>
> --------------
> Alan Karp
>
>
> On Tue, Oct 27, 2026 at 6:15 PM ShaoBao Li <lee@aicent.com> wrote:
> *HI, Alan, colleagues,*
>
> You are right, and the gap is real: we know of no deployed system that
> carries the delegator's standing policy — your "Please" — as data a relying
> party could read. It is worth saying plainly that our schemes do not fill
> that slot either, and that the omission is deliberate.
>
> The refusal reason field of Section 8 of our draft
> (draft-li-rttp-iqa-addressing, the series currently under ISE review) is a
> closed five-value set with a fixed priority order, and every value in it is
> an authority fact: the evidence did not match, the evidence expired, the
> authority could not be determined, the authority was revoked, the operation
> is not permitted. "Only within the company" is not an authority fact; it is
> a term of the grant or a preference of the delegator. The draft applies the
> same rule to policy text that it applies to action verbs — "this document
> deliberately defines no enumeration of verbs, because enumerating an open
> set would close it" (Section 7.1.1 of the same draft). A standard
> vocabulary of "Please"s would be closed by exactly the act of standardizing
> the ones we happened to think of first.
>
> The place for the "Please" exists one layer up, in composing artifacts
> rather than in the verification answer. An authorization envelope carries
> the mandate — what the agent is asked to do, under what constraints, for
> how long; the Agent Authorization Envelope draft already circulating in
> this group is one such container, and revision -01 of our draft, posted 27
> October, states the composition in its Section 12: an authorization
> envelope can name actions on rttp-addressed subjects and cite iqa
> attestations as evidence, and neither depends on the other. The
> verification answer stays small on purpose: whether the claimant stands,
> and which grant the answer relied on.
>
> Your credential-sharing argument is, we think, independent support for the
> discipline the vocabulary already imposes: implementations MUST NOT emit
> values outside the set and MUST NOT reinterpret an emitted value to mean
> something else, and "a response that reports an outcome without its reason
> is not conformant: the reason is what makes a refusal auditable." An
> articulable refusal gives the blocked party something to read and correct;
> a silent block gives them something to route around. On that point we are
> entirely aligned.
>
> What no artifact in this thread carries yet — ours included — is the
> second slot you named: a standard place for the reason a specific policy
> was violated. Policy vocabularies are deployments' own, open-ended, and
> belong to the calling layer, the same layer that owns action-time
> authorization, which the draft explicitly declines to claim. Naming that as
> an open question, the way you just did, is the right first move;
> standardizing it would be a larger project than this thread, and we make no
> promise about it here.
>
> One housekeeping note for readers of the thread: the revision under ISE
> review is now draft-li-rttp-iqa-addressing-01 (posted 27 October 2026); the
> attestation-response vocabulary of Section 8 is I-D text, and the series
> page is https://datatracker.ietf.org/doc/draft-li-rttp-iqa-addressing/.
>
>
> Best regards,
>
> Lee
> lee@aicent.com
> RTTP & IQA Organization
> Author, draft-li-rttp-iqa-addressing
> Resonant Time Transfer Protocol (RTTP, CRI 27)
> Identity Quality Assurance (IQA, CRI 28)
> Sites: https://rttp.com · https://iqa.org
> ------------------------------------------------------------------
> From:Alan Karp <alanhkarp@gmail.com>
> Send Time:Wed, Oct 28, 2026, 07:26
> To:ShaoBao Li<lee@aicent.com>
> CC:Lars Kersten Kroehl<lars@moltrust.ch>; "public-agentprotocol"<
> public-agentprotocol@w3.org>; llewis<llewis@sovrlabs.com>; tima<
> tima@aeoess.com>
> Subject:Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> Knowing why a request was rejected is useful.  More useful is knowing the
> policy the delegator would like you to follow, e.g., only within the
> company.  Most people (and agents) would obey your wishes if only they knew
> what they were.  I have yet to see a system that has a place to put this
> information.
>
> As an aside, that policy is stated as a "Please."  Blocking a delegation
> that violates it leads to credential sharing, which means you'd also like a
> place to say why the policy is being violated.
>
> --------------
> Alan Karp
>
>
> On Sat, Oct 24, 2026 at 1:00 PM ShaoBao Li <lee@aicent.com> wrote:
> Lars, Tymofii, Larry, colleagues,
>
> Thank you for the precise answers in your last note; both refinements make
> revision 3 concrete, and revision 3 on that basis has our support.
>
> On the refusal reason: the value that matters is exactly the one you named
> — "the authority could not be determined." The fail-closed declaration you
> cited earlier in this thread names the behaviour rather than a substantive
> refusal, and we agree the result sheet must carry it as a value of its own.
> A record that folds unreachability into a substantive reason manufactures
> an intent nobody had; keeping the two apart is what makes third-party
> recomputation meaningful.
>
> On the grant reference: naming the grant as it stood at the decision
> matches the anchoring our records already use — evidence carries its issue
> time, the verifier checks freshness against its own clock, and
> recomputation runs against the recorded state, not today's. A grant
> narrowed after the fact should not be able to change a recorded verdict;
> the format can simply make that impossible.
>
> Revision 3 is therefore welcome on two fronts: it preserves the
> comparability of the frozen revision-2 records — our run and its sealed
> artifact stay pinned to the revision-2 digests, as you and Tymofii both
> noted — and it adds the two fields that make refusals auditable. When
> revision 3 lands, our runner will follow with revision-3 scoring, and the
> revision-2 record will stand as it is.
>
> For the AAE vectors: the candidate route suits us, and we will run them
> under the same treatment the lease-revocation family received —
> digest-gated, per-mode and per-axis scoring, with the sealed-record format
> available if you want an artifact of record.
>
> One housekeeping note from my post of Sat, 24 Oct 2026 22:44:14 +0800: the
> frozen vectors and the run-report format remain available as starting
> points for the common set, and the acceptance criteria still seem worth
> arguing here on the list rather than settled anywhere else. The offer
> stands.
>
>
> Best regards,
> Lee
> lee@aicent.com
> Author, draft-li-rttp-iqa-addressing-00 (ISE review)
> Resonant Time Transfer Protocol (RTTP, CRI 27)
> Identity Quality Assurance (IQA, CRI 28)
> Sites: https://rttp.com · https://iqa.org
> Blog: https://blog.aicent.com/
> ------------------------------------------------------------------
> From:Lars Kersten Kroehl <lars@moltrust.ch>
> Send Time:Sun, Oct 25, 2026, 00:54
> To:Tymofii Pidlisnyi<tima@aeoess.com>
> CC:"public-agentprotocol"<public-agentprotocol@w3.org>; llewis<
> llewis@sovrlabs.com>; ShaoBao Li<lee@aicent.com>
> Subject:Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> Tymofii, Larry, Lee,
>
> Tymofii, that would cover both. I would put it like this: The refusal
> reason should be able to say that the authority could not be determined —
> without that value, an implementation that never reached the source has to
> pick the nearest substantive reason, and the record then reads like a
> decision someone actually made.
>
> The grant reference should identify the grant as it stood at the decision.
> A grant narrowed afterwards would otherwise recompute to a different answer
> than the one recorded, which is an awkward kind of mismatch to chase later.
>
> Revision 3 on that basis works for me, and thank you for keeping revision
> 2 frozen — that keeps the existing runs comparable.
>
> I will take the candidate route from CONTRIBUTING for the AAE vectors. The
> refusal reason also answers the taxonomy question I raised in the issue,
> which saves a separate discussion.
>
> Looking forward to revision 3.
>
>
> Lars
>
>
> Am 24.10.2026 um 17:02 schrieb Tymofii Pidlisnyi <tima@aeoess.com>:
>
> Lars, Larry, Lee,
>
> Lars, welcome, and thanks for offering the AAE vectors.
>
> You're right about refusals. The family reports authority validity
> separately, but the action decision only says permit or deny. I propose
> adding a refusal reason and the grant reference to each decision record, so
> we can compare why implementations refused and which grant they evaluated.
>
> Would that cover your two points? If so, I'll prepare revision 3 and keep
> revision 2 frozen for the existing runs.
>
> Lars and Larry, vectors from AAE and ATP are welcome as candidates. The
> lab publishes a candidate after a short review, before anyone reproduces
> it, and admission as a reviewed fixture is a separate step. The route is in
> CONTRIBUTING.md at
> https://www.google.com/url?q=https://github.com/Agent-Authority-Conformance/aps-conformance-suite/blob/main/CONTRIBUTING.md&source=gmail&ust=1792940577687000&sa=E
>
> Lee, thanks for the run. I reproduced the #187 output locally and will put
> my review on the PR.
>
> Tymofii
>
> On Sat, Oct 24, 2026 07:44 AM, ShaoBao Li <lee@aicent.com> wrote:
> *Dear Larry, Tymofii, Chris, Lars, colleagues,*
>
> Thank you all for keeping this thread moving. In my mail of 21 October I
> stated where our two schemes stand on the three axes, and committed to
> running the lab's case family against our implementation; that run is now
> complete. As the shared test vectors head for review, this post records the
> run on the list, so that everything below is checkable by anyone.
>
> The run used the frozen revision-2 vectors of the lease-revocation-axes
> family (
> https://github.com/Agent-Authority-Conformance/aps-conformance-suite/pull/180,
> corpus commit b745d25; re-verified against the PR head, 86e5e7a, on 24
> October — the frozen inputs are unchanged). The vectors digest (sha256
> a0a07ea58bcacfd056cbd648e03de4ff14778aa151e8b5d2574e43e31a111ed8) is a hard
> gate: the runner refuses to score anything else, and the gate was verified
> negatively — a tampered copy is rejected before any scoring occurs. The
> runner is an independent stdlib-only Python implementation (code as run:
> 8cb2e241419cd03d9be40c5977e0e9caa1d723a4, under
> https://github.com/Aicent-Stack/conformance); it declares three axes —
> evidence freshness: claimed; authority validity: claimed; action-time
> authorization: not claimed (by design).
>
> Results: 48/48 baseline runs matched (4 profiles × 12 cases — two lease
> modes × two boundary policies), across 176 calls, 528 scored axis
> comparisons and 176 composite comparisons; all 12 mutation probes matched
> their pinned failure sets; 20/20 post-expiry diagnostic runs were clean,
> every emitted diagnostic backed by an actual recorded read; 12/12
> hand-reasoned oracle checkpoints agreed; and all five reporting-semantics
> checks are true — executed, not asserted. Three consecutive runs on 24
> October produced byte-identical reports. No suspected defective vectors
> were observed.
>
> Our run is author-produced by the lab's definitions — Mode B, labeled as
> such in the report; the implementation is independent of the lab's code,
> but the filer is the author, and the record says so. Tymofii's independent
> reproduction review of 23 October (PR #180 comment) surfaced two reporting
> defects, both fixed in the corrected revision (rev c). The disagreements
> along the way are documented rather than disputed.
>
> The interoperability package was submitted to the lab on 24 October as PR
> #187 (
> https://github.com/Agent-Authority-Conformance/aps-conformance-suite/pull/187,
> under review). The sealed artifact of record (lra-runner-20261023c.tar.gz,
> sha256 94bbaf3c292abf69595bf5782d1db8cbb4178536d53182578b46cff94a5c4b15) is
> published at https://iqa.org/conformance/lra-runner/ and carries two
> addresses derived from its own digest — nothing invented, nothing
> registered, both resolve live now:
>
> - rttp://94bbaf3c.conformance.iqa — the question side (WHERE + WHEN);
> intent = first 8 hex of the artifact digest
> - iqa://94bbaf3c292abf69595bf5782d1db8cb.forge.iqa — the answer side
> (WHETHER); subject = first 32 hex of the same digest
>
> Everything above can be recomputed from the pinned digests without
> contacting us.
>
> On next steps: the frozen vectors and the run-report format are both
> available as starting points for the common vector set proposed in this
> thread — and we would rather see the acceptance criteria argued on this
> list than settled anywhere else. Lars — your two reporting-criteria
> suggestions are received and substantive; they deserve more than a
> footnote, and I will respond to them in a separate post.
>
> Best regards,
> Lee
> lee@aicent.com
> Author, draft-li-rttp-iqa-addressing-00 (ISE review)
> Resonant Time Transfer Protocol (RTTP, CRI 27)
> Identity Quality Assurance (IQA, CRI 28)
> Sites: https://rttp.com · https://iqa.org
> Blog: https://blog.aicent.com/
> ------------------------------------------------------------------
> From:Larry Lewis <llewis@sovrlabs.com>
> Send Time:Sat, Oct 24, 2026, 21:15
> To:Lars Kersten Kroehl<lars@moltrust.ch>
> CC:ShaoBao Li<lee@aicent.com>; "public-agentprotocol"<
> public-agentprotocol@w3.org>; Tymofii Pidlisnyi<tima@aeoess.com>; ShaoBao
> Li<lee@iqa.org>
> Subject:Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> Hi Lars, Tymofii, Lee, and colleagues,
>
> Thank you, Lars, for joining the experiment and for the thoughtful
> suggestions regarding revocation outcomes and verifiable authority
> references.
>
> I've been out of the office and am catching up, but I'm excited to see
> this collaboration moving forward.
>
> Tymofii, I appreciate you opening the conformance work. We'll begin
> reviewing the shared test vectors and preparing ATP's implementation
> contributions.
>
> Looking forward to working with everyone and helping move this effort
> forward.
>
> Best regards,
>
> Larry Lewis
> Chair, Agent Trust Protocol Community Group
>
>
>
> From: Lars Kersten Kroehl <lars@moltrust.ch>
> To: "ShaoBao Li"<lee@aicent.com>
> Cc: "Larry Lewis"<llewis@sovrlabs.com>, "public-agentprotocol"<
> public-agentprotocol@w3.org>, "Tymofii Pidlisnyi"<tima@aeoess.com>,
> "ShaoBao Li"<lee@iqa.org>
> Date: Sat, 24 Oct 2026 07:06:12 -0500
> Subject: Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> Larry, Lee, Tymofii,
>
> I'm Lars, author of the Agent Authorization Envelope
> (draft-kroehl-agentic-trust-aae), which covers delegation and revocation.
> Count us in for the experiment if you like — we can run the
> T=0/10/30/60/119 sequence as you set it out, and I can put delegation and
> revocation test vectors into a common set.
>
> One suggestion for the reporting criteria, if useful. Lee's fail-closed
> answer for the unreachable case already names the behaviour, and the result
> sheet should be able to show it. If a run records only permitted or
> refused, an implementation that refused because the authority was revoked
> and one that refused because it could not determine the authority come out
> looking the same. Keeping those apart, alongside the per-mode and per-axis
> scoring already proposed, would show which is which.
>
> For the same reason it helps if each recorded decision names the authority
> it was taken under, so a third party can recompute it.
>
> Looking forward to it.
>
> Lars
>
>
>
> Am 21.10.2026 um 22:19 schrieb ShaoBao Li <lee@aicent.com>:
>
> *Dear Larry, Tymofii,*
>
> Yes to the experiment — and it is worth pausing on how it arrived: the
> same timeline, the same variant with the revocation service unreachable,
> proposed independently from two different layers within hours of each
> other. That is the best evidence yet that the row our Q3 asked about is
> real: it is being felt from the delegation side and from the enforcement
> side at once, and neither of you needed the other's vocabulary to draw it.
>
> Answering the direct question about the three axes, for the rttp and iqa
> schemes (draft-li-rttp-iqa-addressing-00, in ISE review; provisionally
> registered at IANA as CRI 27 and CRI 28; public entries at
> https://rttp.comand https://iqa.org). The three-way distinction is
> Larry's framing, and it is the right one; here is where our schemes stand
> on it.
>
> We claim two of the three. Evidence freshness: claimed — every statement
> carries its 120-second lease in-band, checked locally against the
> verifier's own clock, offline. Authority validity: claimed — a named organ
> answers for the subject's standing in a closed four-state set (ghost,
> probation, radiant, genesis), and the standing read is a safe, read-only
> operation. Action-time authorization: not claimed — and, to pick up Larry's
> phrasing, our contribution and boundaries should be documented separately,
> because the gap is deliberate. Authorization decisions belong to the
> calling layer; the protocol's job is to make the verification answers
> trustworthy and cheap, not to decide what may be done with them. A
> conformance suite that scores the three axes separately is not a concession
> to us — it is the design speaking.
>
> To Larry's specific question — how RTTP/IQA behaves when revocation lands
> inside an active freshness window, particularly when revocation information
> is unavailable or delayed — our answer has two named modes, and we would
> state the expected results for each so the test cases do not expect more
> from us than we claim. In cached-lease mode, the T=119 call is expected to
> go through, and in the unreachable-revocation-service variant it is still
> expected to go through: offline completion is the design point, not a
> degradation, and the exposure is bounded by the lease itself. In
> live-standing-read mode, T=30, T=60 and T=119 are all expected to be
> refused, and in the unreachable variant the refusals are expected to be
> fail-closed: an organ that cannot be reached is not read as silent consent.
> If the suite scores those two behaviours separately, the two modes will be
> distinguishable by more than a mode flag.
>
> On publishing: we agree the test definitions and results should be open,
> and we can contribute from our side — the derivation and
> envelope-verification conformance vectors behind the two schemes are
> already public, and the standing-read semantics are specified in the draft.
> A case family built on the shared timeline, scored per axis, with each run
> declaring its mode, is the right shape; we will run our schemes against it
> and report in the open.
>
> On the wider federation discussion (#177) and the ATP observations: the
> boundary-first framing — each project keeps its own piece, verification
> happens at the edges, a mechanism is scored on what it claims — is one we
> can work inside. We will engage in writing, per the standing offer that
> came with the four questions.
>
> One housekeeping note, happily obsolete by the hour: your message, Larry,
> reached the archive as No. 0014 while this reply was being drafted — a
> faster pass through the same first-post review queue our own letter sat in
> last week. The thread now reads 0009, 0011, 0012, 0013, 0014; every
> quotation above has its anchor on the wall.
>
> Best regards,
> Lee
> lee@aicent.com
> Author, draft-li-rttp-iqa-addressing-00 (ISE review)
> Resonant Time Transfer Protocol (RTTP, CRI 27) · Identity Quality
> Assurance (IQA, CRI 28)
> Sites: https://rttp.com · https://iqa.org
> Blog: https://blog.aicent.com/
> ------------------------------------------------------------------
> From:Larry Lewis <llewis@sovrlabs.com>
> Send Time:Thu, Oct 22, 2026, 02:03
> To:ShaoBao Li<lee@aicent.com>
> CC:Tymofii Pidlisnyi<tima@aeoess.com>; "public-agentprotocol"<
> public-agentprotocol@w3.org>; ShaoBao Li<lee@iqa.org>
> Subject:Re: Four open questions on the Agentic Web report (2026-09-24):
> preimage defense, address assurance, trust leases, statement granularity
>
> Dear Lee, Tymofii, and AI Agent Protocol Community Group,
>
> Thank you, Lee, for sharing your review of the Agentic Web technical
> report and for presenting four thoughtful questions concerning identity
> assurance, addressing, trust freshness, and interoperability.
>
> I also appreciate Tymofii's response regarding delegation expiry and
> revocation in the Agent Passport System (APS).
>
> From the perspective of the Agent Trust Protocol (ATP) Community Group, I
> believe this discussion highlights an important opportunity for
> collaboration across the emerging agentic web ecosystem.
>
> Trust is not a single mechanism or verification event. It involves
> multiple layers of identity, evidence, authority, policy enforcement,
> revocation, and accountability.
>
> I would like to share a few observations concerning the four questions and
> propose a practical way for our respective projects to explore them
> together.
>
> Q1 -  Preimage Defense and Identity Substitution
>
> I agree that demonstrating cryptographic key control does not necessarily
> establish the legitimacy or continuity of an agent's claimed authority.
>
> We should distinguish between verifying a DID document, establishing its
> provenance, determining whether its verification methods remain valid, and
> ensuring that the identity presented corresponds to the authority expected
> by the receiving agent.
>
> This raises useful interoperability test cases involving identity-document
> substitution, compromised verification methods, key rotation, and
> conflicting authority claims.
>
> Q2 - Address Assurance
>
> Separating addressing from discovery is worth examining.
>
> Deterministically derived addresses can provide useful properties, but
> address integrity should not be confused with proof of legitimate ownership
> or authorization.
>
> I would be interested in exploring how RTTP-derived addressing interacts
> with DID resolution, existing agent discovery mechanisms, and independent
> authority verification.
>
> Q3 - Trust Leases, Freshness, and Revocation
>
> This question is particularly relevant to ATP's work on delegated
> authority and runtime enforcement.
>
> ATP distinguishes between trust evidence and authorization. A credential
> or statement may remain cryptographically valid while its underlying
> authority has expired, been revoked, or become insufficient for a
> particular action.
>
> Tymofii raises an important point: a 120-second freshness lease could
> allow previously verified evidence to remain within its accepted freshness
> window even after revocation.
>
> We should therefore distinguish at least three concepts:
>
>    1.
>
>    Evidence freshness — how recently the statement or credential was
>    verified.
>    2.
>
>    Authority validity — whether the delegation remains valid and
>    unrevoked.
>    3.
>
>    Action-time authorization — whether the requested operation is
>    currently permitted under the applicable constraints and policies.
>
> I would welcome further clarification regarding how RTTP/IQA handles
> revocation within an active freshness window, particularly when revocation
> information is unavailable or delayed.
>
> For ATP, this distinction is central to our approach: trust evidence
> informs authorization, but possession of valid evidence does not
> automatically grant permission to act.
>
> Q4 - Statement-Level and Platform-Level Interoperability
>
> I see these approaches as potentially complementary rather than mutually
> exclusive.
>
> Statement-level verification can support portable, independently
> verifiable evidence across systems. Platform-level infrastructure can
> provide additional operational services, governance, policy administration,
> and trust coordination.
>
> The important architectural question is whether independently operated
> agents can verify the evidence and enforce the appropriate authority
> without depending on a particular commercial platform.
>
> This is an area where I believe cooperation between our projects could
> produce useful implementation evidence.
>
> Proposal — A Joint Trust Interoperability Experiment
>
> Rather than limiting the discussion to architectural comparisons, I would
> like to propose a small, collaborative technical exercise involving
> RTTP/IQA, APS, and ATP.
>
> We could begin with the trust-lease and revocation scenario raised by
> Tymofii:
>
>    -
>
>    T=0: An agent receives valid identity and authorization evidence.
>    -
>
>    T=10 seconds: The issuing authority revokes the relevant delegation or
>    statement.
>    -
>
>    T=30, T=60, and T=119 seconds: The agent attempts an operation
>    requiring that authority.
>    -
>
>    Each implementation evaluates the requests according to its own
>    documented verification and enforcement mechanisms.
>    -
>
>    We compare the decisions, verification evidence, revocation handling,
>    and limitations.
>
> We should also examine what happens when the revocation service is
> temporarily unavailable and whether the receiving system can independently
> establish the authority needed to perform the action.
>
> The goal would not be to determine which protocol is superior or to
> require any project to adopt another project's architecture.
>
> Instead, we could establish a common set of security properties, test
> vectors, and reporting criteria while allowing each implementation to
> demonstrate its respective responsibilities.
>
> Importantly, a mechanism that does not claim to provide action
> authorization should not be evaluated as though it does. Its contribution
> and boundaries should be documented separately.
>
> Publishing the Results
>
> If there is interest, I suggest publishing the agreed test definitions and
> implementation results openly so other contributors can reproduce,
> evaluate, and extend them.
>
> This could help the community better understand:
>
>    -
>
>    Which trust guarantees are already implemented.
>    -
>
>    Which mechanisms complement one another.
>    -
>
>    Where interoperability boundaries exist.
>    -
>
>    What gaps require additional specification work.
>    -
>
>    Which security properties can be independently verified across
>    different agent systems.
>
> From ATP's perspective, our interest is in helping establish portable,
> verifiable, revocable, and enforceable trust mechanisms that can operate
> across agent frameworks and organizational boundaries.
>
> I believe this is an opportunity for the community to advance the
> technical foundations of the agentic web collectively.
>
> I would welcome both Lee's and Tymofii's thoughts on this approach, as
> well as feedback from other Community Group participants.
>
> Thank you again for contributing to this important conversation.
>
> Best regards,
>
> Larry Lewis
> Chair, Agent Trust Protocol Community Group
> W3C Community Groups
>
>
>