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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Bradley,

I would seen everything on "what the session's records are for once the session is over” as more related to auditing.

As you say, one question is, does it need to be standardized, but the second question of the charter work is also how do we split the work into workable pieces between a set of groups that allows up to make (mostly) independent progress on all of them.

There, I would clearly see the scope of the potential future AgentProto group as what needs to be standardized on agent communication during an active session.

Mirja



> On 13. Aug 2026, at 01:28, Bradley B <[e-mail]> wrote:
> 
> Mirja, Suresh,
> 
> One data point for Mirja's test, from production rather than argument.
> 
> Our control plane reconciles decision records against the executing
> side's records across a trust boundary, hash for hash. Correlation
> works. Every pair matches. And the fraction of those pairs that carry
> any sequencing mechanism is zero percent. Correspondence is not
> precedence: matching records prove the two sides agree about what
> happened, not which came first.
> 
> So I agree correlation is the part that must be standardized, and I do
> not think it can be the only part. The question a relying party brings
> across domains is not "do these records refer to the same operation"
> but "did the authority exist before the effect." Correlation alone
> answers the first and silently fails the second, and the failure is
> invisible until someone asks. That is not an audit concern imported
> into session management. It is what the session's records are for once
> the session is over.
> 
> Whether the ordering evidence lives in this charter or is explicitly
> left to another is a fair chairs' call. Leaving it unstated is the
> only wrong answer.
> 
> IPR 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
>> 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
>> 
>> 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”