[Agentproto] Re: Sussing out points of disagreement on the charter

[Henri Sirkkavaara <[e-mail]>]

Syed, the revised sentence is right and I would add one item to its list.

Current-key and revocation status are lifecycle state the decision depends on, and so is the time the decision is evaluated at. Revocation status is only meaningful relative to a clock, so a relying party that takes revocation freshness from an independent source while taking its clock from the authenticated party leaves the decision under that party's influence. What remains under it still produces a result that looks correct at every later inspection.

Concretely, appending "including current-key status, revocation status, and the time source the validity decision is evaluated against" keeps your formulation intact and closes the case where the other two are satisfied and the decision still follows the signer.
I would keep it at MUST for the reason you gave.

Henri Sirkkavaara
Vaara - Runtime execution layer for AI agents
Built to see over the noise.
vaara.ioHelsinki, Finland

On Friday, August 14th, 2026 at 10:46, Henri Sirkkavaara <[e-mail]> wrote:

> Sumit, the time case belongs in the enumeration, and I would argue it is the one where the enumeration earns its keep.
>
> The other four inputs fail visibly. If the resolution answer or the lifecycle state comes from the authenticated party, a reviewer looking for it can see that it did. Time fails silently. A validity window evaluated against a clock the authenticated party influences produces a decision that looks correct at every later inspection, including to the relying party that made it. Nothing in the record shows what went wrong.
>
> That is why I would not leave it to the general principle. A general property about positional independence is something an implementer agrees with and then fails to apply to their clock, because the clock does not feel like an input.
> There is existing ground to build on rather than invent. RFC 3161 timestamping against a timestamp authority the relying party selects gives a time source outside the authenticated party's control, and in the EU a qualified TSA on the Trusted List makes that independence legally checkable rather than merely asserted. I have implemented this in draft-sirkkavaara-vaara-receipt, where the receipt carries the anchor so a verifier can establish when a record existed without asking either party.
>
> Henri Sirkkavaara
> Vaara - Runtime execution layer for AI agents
> Built to see over the noise.
> vaara.ioHelsinki, Finland
>
> On Friday, August 14th, 2026 at 01:27, Syed Anas Mohiuddin <[e-mail]> wrote:
>
>> Shawn,
>>
>> You are right and the line as I wrote it is wrong. "Must not be derived from
>> the artifact being validated" bans self-certifying identifiers along with the
>> unsafe case, and those are exactly the shape that does work. I will take the
>> correction.
>>
>> Your formulation is the one that holds: the question is whether the party being
>> authenticated can influence the identifier the relying party keys its trust
>> decision on. A key carried inline is fine when the identifier is a fixed
>> function of that key, because substituting a key then produces a different
>> identifier and fails the match rather than passing as somebody else. What fails
>> is a pointer to a key the signer chose, because there the signer moves the
>> identifier and the decision follows it.
>>
>> Your rotation point is the better half of the message and I had not gone that
>> far. An identifier can be self-certifying at first contact and still have its
>> current-key or not-revoked state re-derived from somewhere the signer controls,
>> at SHOULD. That puts the whole trust decision back under the authenticated
>> party's influence one hop later, and it would pass the line as I wrote it. It
>> should not.
>>
>> Revised, with both changes:
>>
>> Any identity, discovery, or attestation mechanism this group produces
>> must state where its trust root comes from. It must not permit the
>> party being authenticated to influence the identifier on which a
>> relying party keys its trust decision, and this applies to the
>> lifecycle state that decision depends on, including current-key and
>> revocation status, and not only to initial identity.
>>
>> Two notes on what that does and does not do. It permits carrying a key inline,
>> which the earlier version accidentally forbade. And it says nothing about which
>> mechanism to use, so it stays out of key management and PKI, which I do not
>> think belong in this charter.
>>
>> On strength, I would keep this at MUST for the reason you gave. A guard at
>> SHOULD in front of a derivable root makes the unsafe path the default, and an
>> implementer following the text correctly ends up there. The measurement I
>> described is what that looks like after the fact.
>>
>> Thanks for the correction.
>>
>> Syed Anas Mohiuddin
>> Independent security researcher
>>
>> On Wed, 12 Aug 2026 at 16:14, Shawn Sammartano <shawn.sammartano=[e-mail]> wrote:
>>
>>> Syed,
>>>
>>> This is the sharper version of the same problem, and the sentence that matters most is that every one of those implementers followed the specification correctly. That makes it a charter and spec question rather than an implementation one, and it's why a SHOULD is the wrong strength. A guard at SHOULD in front of a derivable root makes the unsafe path the default, which is what your numbers show. Five of seven doing no verification, and the two that verify passing the caller-supplied key location straight through, is what happens when the safe branch is optional and nothing pushes an implementer onto it.
>>>
>>> I'd back your line. One tightening, from having built the safe version and then found where it still leaks.
>>>
>>> The precise test isn't whether the key or the locator sits inside the artifact. It's whether the party being authenticated can influence the identifier the relying party's trust decision is keyed on. Carrying the key inline is safe if, and only if, the identifier that decision is made against is a fixed function of that key, so presenting a different key produces a different identifier and fails the match rather than passing as someone else. That's the difference between a self-certifying identifier and a pointer to a key the signer chose, and it's worth putting in the line, because "must not be derived from the artifact" will otherwise be read to forbid carrying the key at all, which isn't the property you want.
>>>
>>> The place it still leaks, even with that, is one level down, at rotation and revocation. The initial identity can be self-certifying while the current-key or not-revoked state is re-derived from a source the signer controls, at SHOULD. So I'd extend your rule to the lifecycle state a root depends on, not only the initial identity, discovery, or attestation.
>>>
>>> For grounding rather than argument, this is the shape we file. Identity is a hash of the public key, the verifier recomputes it from the key it was handed and rejects a mismatch, and there is no authority to fetch and no CA, so neither of your two forms arises at the object layer. It does not fully close the rotation-discovery question I just named, which is the honest hole in it, and the reason I think your line has to reach that far.
>>>
>>> Shawn S.
>>> https://datatracker.ietf.org/doc/draft-bubblefish-naalp/https://bubblefish-tech.github.io/naalp_protocol/docs/
>>>
>>> On 8/12/2026 1:08 PM, Syed Anas Mohiuddin wrote:
>>>
>>>> Bradley's framing is useful, and I would like to raise a second instance of the
>>>> same shape, since Mirja's test applies to it cleanly.
>>>>
>>>> What I keep finding in deployed agent systems is not a missing trust model. It
>>>> is a trust model whose root is derivable from the object being validated, with
>>>> the guard written at SHOULD.
>>>>
>>>> Two forms. Key discovery inside the signed object: the artifact carries a
>>>> pointer to the key that verifies it, so a relying party following the text
>>>> fetches the key the signer chose and reports the artifact as authentic. And
>>>> identity as a dereferenceable URL, where the relying party issues a request to a
>>>> destination the caller supplied, and the specification says implementations
>>>> should consider the risks.
>>>>
>>>> I measured one ecosystem for this recently, by static analysis of public source.
>>>> Of seven official SDKs for one agent protocol, five contain no signature
>>>> verification at all. Of the two that do, both pass the caller-supplied key
>>>> location through to application code with no origin check, and the official
>>>> sample for one of them requires that value and fetches the key from it. I am not
>>>> naming the protocol while a coordinated disclosure is open. I will bring the
>>>> data to the list when it publishes.
>>>>
>>>> The reason I think this is a charter question and not an implementation
>>>> question: every one of those implementers followed the specification correctly.
>>>>
>>>> So, in the same spirit as Bradley's line:
>>>>
>>>> Any identity, discovery, or attestation mechanism this group produces must
>>>> state where its trust root comes from, and must not permit that root to be
>>>> derived from the artifact being validated or from data supplied by the party
>>>> being authenticated.
>>>>
>>>> That does not put key management or PKI in scope. It keeps the group from
>>>> standardizing a shape that cannot be made safe afterwards.
>>>>
>>>> Syed Anas Mohiuddin
>>>> Independent security researcher
>>>>
>>>> On Wed, 12 Aug 2026 at 11:17, Bradley B <[e-mail]> wrote:
>>>>
>>>>> Mirja,
>>>>>
>>>>> Your test is the right one, and I think the charter survives it with
>>>>> one line. Let me earn the line first, since my earlier note predates
>>>>> your message.
>>>>>
>>>>> On separating proof of binding out. I can live with binding being
>>>>> specified elsewhere, but only if the correlation deliverable states
>>>>> what it must preserve for binding to attach later. Our implementation
>>>>> lesson is narrow and repeatable: we had correlation working across a
>>>>> trust boundary, hash for hash, and what it established was that the
>>>>> two sides agree about what happened. It established nothing about
>>>>> which came first, and nothing about whether the party asserting the
>>>>> association was entitled to assert it. Correspondence is not
>>>>> precedence. If correlation is standardized without naming its
>>>>> attachment points, a binding mechanism defined in another group
>>>>> arrives to find a shape it cannot ride on, and each deployment
>>>>> reinvents the joint.
>>>>>
>>>>> On the audit split you raised with Sumit. I run the layer on the other
>>>>> side of that line, so the division of labor lands on me in practice: a
>>>>> record can only contain what the protocol carried. If an acceptance
>>>>> does not carry what was accepted, no audit model downstream can
>>>>> reconstruct it, because the fact was never emitted by anyone. That is
>>>>> not session lifecycle in the full sense, and I share your suspicion of
>>>>> the term. It is one property: entering a state a relying party may
>>>>> need to reason about produces an artifact rather than silence. AUDIT
>>>>> can define what the record must contain. Only this group can decide
>>>>> whether the protocol carries enough for that record to be honest.
>>>>>
>>>>> One concrete example, since you asked for those. We emit signed
>>>>> decision records for allow and deny. The deny records are the ones
>>>>> auditors ask for and the ones no correlation-only design ever carries,
>>>>> because a denial correlates with nothing: there is no subsequent
>>>>> action to associate. Scope to correlation alone and the refused
>>>>> action, which is the record most often needed across a boundary, is
>>>>> unrepresentable by construction.
>>>>>
>>>>> So the one line, for the revision:
>>>>>
>>>>> "Correlation mechanisms must state what they preserve for proof of
>>>>> binding to attach, and an acceptance must carry what was accepted."
>>>>>
>>>>> That does not put binding or audit in scope. It keeps this group from
>>>>> standardizing a shape that forecloses both.
>>>>>
>>>>> PR disclosure covering the material behind this:
>>>>> https://datatracker.ietf.org/ipr/7500
>>>>> Bradley B
11 AI Blockchain Developments LLC
>>>>>
>>>>> On Wed, Aug 12, 2026 at 8:29 AM Mirja Kuehlewind (IETF)
>>>>> <ietf=[e-mail]> wrote:
>>>>>>
>>>>>> Not sure that is a relevant case for session management. Any request can fail due to various reason and you need to always handle that. There is something relevant to audit here but again I don’t think that is related to session or lifecycle management.
>>>>>>
>>>>>> On 12. Aug 2026, at 17:18, Sumit Ahuja <sumit=[e-mail]> wrote:
>>>>>>
>>>>>> Mirja,
>>>>>>
>>>>>> I sent a reply on this thread before yours arrived and it did not answer the question you actually asked, which is the sharper one.
>>>>>>
>>>>>> Your test is what needs to be standardized to survive cross-domain rather than being an implementation choice. I think that disposes of most of the session-lifecycle question, and one thing survives it. Here is the concrete example.
>>>>>>
>>>>>> A unit of work is accepted in domain A and executes in domain B. B admits it and never schedules it. Nothing is malformed, no error is returned, no timeout necessarily fires, and the work is live and legitimately pending for as long as anyone cares to wait. From A's side the session was accepted and is in progress. From B's side nothing has gone wrong. A cannot distinguish still working from never started using anything the protocol carried, because what the protocol carried was acceptance.
>>>>>>
>>>>>> Not hypothetical. In a pre-registered evaluation I ran, two priority-based scheduling policies at heavy mixed load, as modelled in a discrete-event simulator, scheduled 1 of 107 compliant long-running units of work with zero preemptions and completed none of them at any injection level, including no injection at all. Every one was admitted. None was rejected, revoked, or errored. Within a single domain that is a scheduling result and an operator sees it by looking at the scheduler. Across a boundary it is invisible, because the only thing A holds is what B said, and B said yes.
>>>>>>
>>>>>> Why it passes your test rather than being an implementation choice: whether B schedules the work is entirely B's business and should stay that way. Whether A can tell that it did not is determined by what the protocol permits B to state and requires B to state, which is nobody's implementation choice and cannot be recovered by either side unilaterally.
>>>>>>
>>>>>> What that implies for scope is narrower than session lifecycle, which is why I think your uncertainty about the term is well placed. Two things: that an acceptance can carry what was accepted, and that entering a state a relying party may need to reason about produces something rather than nothing, so that silence afterwards is an attributable claim by a named party rather than an ambiguity. Not the states, not the transitions, not full session semantics. That lands close to Rob's observation that the authority lifecycle is hard to avoid while full session semantics may be more than needed, arriving from a different direction.
>>>>>>
>>>>>> One disclosure, since you are carrying the AUDIT charter prep and I would rather name the overlap than have you find it. I raised the adjacent version of this on agent2agent, that an evidence model built on events cannot express a commitment that was granted and never honoured. I think both cuts are real and they are different: AUDIT's question is what a record must contain, this one is what a protocol must carry. I have no view on whether either should wait for the other.
>>>>>>
>>>>>> On separating proof of binding out to another working group I have no measurement and will leave it to Rob and others.
>>>>>>
>>>>>> Sumit P. Ahuja
>>>>>> Main Labs
>>>>>>
>>>>>> On Aug 12, 2026, at 10:05, Mirja Kuehlewind (IETF) <ietf=[e-mail]> wrote:
>>>>>>
>>>>>> Hi Suresh, hi Rob, hi all,
>>>>>>
>>>>>> I think all the points discussed below are needed in some way, but the real questions is: what needs to be standardized?
>>>>>>
>>>>>> I think the correlation bit if the most important piece here that we identified as needed for inter domain workflows (without providing a clear definition of “workflow” at this point). Yes, proof of binding is needed as well but maybe we can separate this out and rely on existing (or new) work of other working groups?
>>>>>>
>>>>>> On the session lifecycle question: Initially I thought this is the main piece but the more we talk about it, the less I’m actually sure what we mean. Do people have concrete examples what is needed, and again more importantly, what needs to be standardized here to survive cross-domain rather than just being an implementation choice?
>>>>>>
>>>>>> Thanks!
>>>>>> Mirja
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12. Aug 2026, at 09:01, Rob Zagarella <[e-mail]> wrote:
>>>>>>
>>>>>> Thanks for pulling these into focus - it really helps. Let me offer a perspective on a few of them from the angle of having built an implementation, which mostly means I've run into where these questions bite in practice rather than in principle.
>>>>>>
>>>>>> On 1 (substrate vs semantics): the thing we kept running into is that shared semantics get two parties to agree on what they mean, but the guarantee that actually matters to a third party - being able to check that an action really did chain back to an authorised origin - isn't something semantics alone can carry. I don't think that means the charter has to pin a wire format; I've just found it hard to get interop to hold without committing to enough substrate to carry a verifiable binding, not only a shared vocabulary for describing one. Curious whether others have found a way to keep it purely semantic and still get that property.
>>>>>>
>>>>>> On 3 (correlation vs proof of binding): this is the one I feel most strongly about, and I'll admit that's partly because it's where our work lives, so please weigh it accordingly. Correlation associates messages; what we found we actually needed was the ability for a relying party to verify that an action was authorised by, and stayed within the bounds set by, a defined origin - without having to trust either endpoint. Correlation didn't survive a dishonest or compromised participant in our testing, which felt like precisely the case the whole effort exists to cover. I'd genuinely like to be wrong about this if there's a lighter path, but I haven't found one - and it's the reason we ended up building a verified human at the root with each downstream action sealed and independently checkable against the authority it derives from. Happy to share what broke when we tried the lighter version.
>>>>>>
>>>>>> On 2 (session lifecycle): the part that's felt unavoidable to us is the authority lifecycle specifically - issuance, continuation when contact is lost, revocation - which is exactly where the recent issue #49 thread has been converging. Full session semantics may be more than needed; the authority lifecycle has been hard to avoid.
>>>>>>
>>>>>> On 6 (terminology): the small set the trust model rests on - authority, binding, continuation bound, resolution path - seems worth defining carefully, mostly because in our experience these are the words where a loose definition quietly turns into a security assumption. The continuation-bound thread this week is a live example of how much these particular terms reward precision.
>>>>>>
>>>>>> On 4 and 5 I hold my views loosely - bilateral seems a reasonable starting scope as long as the binding model doesn't assume it, and sequencing a minimal binding-capable core first feels natural, but I'd defer to people closer to those pieces.
>>>>>>
>>>>>> If it's useful to ground any of this in something already built rather than argued, I'm very happy to contribute text on the binding and authority-lifecycle parts - there's running code and a draft behind the position, and I'd rather it be pressure-tested than taken on faith.
>>>>>>
>>>>>> Roberto Antonio Zagarella
>>>>>> Violet Shores - VAC Protocol / Athena
>>>>>> draft-zagarella-verified-human-root: [https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-zagarella-verified-human-root/&source=gmail&ust=1786604005674000&sa=E](https://www.google.com/url?q=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zagarella-verified-human-root%2F&ust=1786604005674000)
>>>>>> draft-zagarella-autonomy-governor: [https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-zagarella-autonomy-governor/&source=gmail&ust=1786604005674000&sa=E](https://www.google.com/url?q=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zagarella-autonomy-governor%2F&ust=1786604005674000)
>>>>>>
>>>>>> On Wed, 12 Aug 2026 at 06:19, Suresh Krishnan <[e-mail]> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>> We have received a lot of great comments during and after the BoF on the charter [0]. After the Bof, Brian [1] and Jonathan [2] have taken a shot at rewriting a more streamlined charter from the ground up based on the comments received. Since these are complete rewrites, I think we may have to dig in a bit deeper to see where the points of disagreement are. From my reading of these two proposals and the comments on github, these aspects seem to be some of the questions that we need to answer before we can work on more focused edits on the charter
>>>>>>>
>>>>>>> 1. Is the output of the working group a substrate or only a set of semantics?
>>>>>>> 2. Should the session lifecycle be in scope?
>>>>>>> 3. Do we have to work on correlation only, or do we need proof of binding as well?
>>>>>>> 4. Do we need to support point-to-multipoint or is bilateral communication sufficient?
>>>>>>> 5. How many deliverables, what status, in what order?
>>>>>>> 6. How much of the terminology should we define in the charter, and on the flip side how comfortable we are building on vaguely defined terms?
>>>>>>>
>>>>>>> Are there other things we need to consider? Your inputs are greatly appreciated.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Suresh
>>>>>>>
>>>>>>> [0] https://github.com/ietf-artarea/charters/blob/main/agentproto/charter.md
>>>>>>> [1] https://github.com/ietf-artarea/charters/pull/77/
>>>>>>> [2] https://github.com/jdrosen/aiproto-wg/pull/48
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Agentproto mailing list -- [e-mail]
>>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> _______________________________________________
>>>>>> Agentproto mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Agentproto mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Agentproto mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>>> --
>>>>>
>>>>> 11 AI Blockchain Developments LLC
>>>>>
>>>>> Brad B - Inventor
>>>>>
>>>>> 📧 [e-mail]
>>>>> 🌐 https://11aiblockchain.com
>>>>>
>>>>> DUNNS @- 144921555
>>>>>
>>>>> 11 AI Blockchain Developments LLC ,11/11 AI Research Division
>>>>> Copyright (c) 2026 11 AI Blockchain Developments Land and IP Trust.
>>>>>
>>>>> “We control whether AI decisions are allowed to execute”
>>>>>
>>>>> _______________________________________________
>>>>> Agentproto mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>> _______________________________________________
>>>> Agentproto mailing list --
>>>> [e-mail]
>>>> To unsubscribe send an email to
>>>> [e-mail]
>>>
>>> --
>>>
>>> Shawn Sammartano, Founder
>>> BubbleFish Technologies, Inc.
>>> Sovereign AI infrastructure
>>> bubblefish.sh
>>>
>>> ---
>>> CONFIDENTIALITY NOTICE:
>>> The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited.
>>> _______________________________________________
>>> Agentproto mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]