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

[Henri Sirkkavaara <[e-mail]>]

Agreed that correlation is the thing that has to survive and that session lifecycle mostly does not. One consequence worth stating while the scope is being drawn.

If correlation metadata is the standardised part, then it has to be verifiable by someone who holds neither end of the session. Correlation that only the two endpoints can check is an implementation detail with a registry attached. The test I would apply to any proposed correlation format: can a third party, given only the artifacts, decide whether these two request/response pairs belong to the same task, without asking either party?

That is a low bar and it rules out most session-identifier designs, because an opaque identifier minted by one side is an assertion. A content-addressed correlation value is checkable. draft-sirkkavaara-vaara-receipt uses the latter for exactly this reason, and the cost is one digest per artifact.
MCP being stateless makes this easier rather than harder: with nothing to carry in the session, the correlation has to be in the artifacts, which is where a third party can reach it.

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

On Friday, August 14th, 2026 at 14:05, Mirja Kuehlewind \(IETF\) <ietf=[e-mail]> wrote:

> Please see inline.
>
>> On 14. Aug 2026, at 12:35, Rob Zagarella <[e-mail]> wrote:
>>
>> Hi Mirja,
>>
>> On separating binding out - I think that can work, and the one condition I'd add from experience is that the charter would still need to own the interface to binding, even if the constructions live elsewhere. Concretely: whatever correlatable artifact this group defines needs a mandatory slot for a verifiable binding and a defined resolution path for checking it - with the schemes themselves imported (OAuth, WIMSE, or the VC world all have candidates). The case I'd want us to avoid is a correlation-only charter, because correlation is only as good as the honesty of the parties doing the correlating. In our testing, a compromised participant correlated perfectly - to a lie. Binding is what turned the correlation into something a third party could check - though if someone has made correlation-only survive a hostile endpoint, that's exactly the evidence I'd want to see, and I'd happily stand corrected. If the charter defines the slot and the resolution semantics, and other groups supply the constructions, I think you get the separation you're describing without losing the property.
>
> What I was trying to say is that the binding itself is needed to be standardized and should be done in this new group. However, the proof of binding might not necessarily need entirely new work as it depends on the binding mechanism that is used.
>
>> On session lifecycle - I'd drop the term, keep three properties, and I think your instinct that part of this is audit-shaped is right. Applying your test (what must be standardised to survive cross-domain rather than being an implementation choice), what survived for us wasn't session state at all, but authority state. Revocation is the cleanest case: whether an authority granted in domain A has been revoked must be checkable from domain B - neither side can recover that unilaterally, so it can't be an implementation choice. Issuance is the same property at the front. And the continuation question isn't error handling in disguise: the question a relying party asks isn't "did a request fail" but "was the action the agent took during the gap authorised at the time it acted" - which only has a cross-domain answer if the protocol requires authority state to be stated and resolvable rather than inferred from silence. That's also where I'd connect your audit observation to Sumit's: the protocol carries the authority state; the record proves what it was at the moment of action. So: issuance, revocation resolution, and continuation bounds - and I'd happily see the words "session lifecycle" leave the charter entirely.
>
> Anything on authorization and delegation should be discussed in oauth group. If their is additional state information (not sure what exactly that is) that need to be provided between agents, I think it best to do that based on a extension to the protocol that is used for authorization.
>
> Mirja
>
>> Happy to contribute text on the binding-slot interface if it would help make the separation concrete.
>>
>> Roberto Antonio Zagarella
>> Violet Shores - VAC Protocol / Athena
>> [https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-zagarella-verified-human-root/&source=gmail&ust=1786789749798000&sa=E](https://www.google.com/url?q=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zagarella-verified-human-root%2F&ust=1786789749798000)
>> [https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-zagarella-autonomy-governor/&source=gmail&ust=1786789749798000&sa=E](https://www.google.com/url?q=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zagarella-autonomy-governor%2F&ust=1786789749798000)
>> _______________________________________________
>> Agentproto mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]