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

[Douglas Wadkins <[e-mail]>]

Mikhail, Henri, Bradley, Sumit,

Mikhail, the three-part split is yours and I want to say so before I use
it. What I think I can add is that some of what we have been treating as
separate properties is absorbed by the split rather than sitting beside
it.

Unique selection is the clearest case. It is not another thing to
satisfy. It is what determination means: evidence that leaves five
candidates standing has not determined which one governed. As you put it,
that is a property of what the evidence determines, not how it was
produced.

Henri's construction makes the rest of it legible.

Content-addressing the record to the grant and runtime arguments
determines the grant/action pair by leaving nothing to choose. That
closes selection without an anchor.

Mikhail's objection is the important one: identity to the act is not use
at the decision. A record deterministic in the grant and arguments is
byte-identical whether it was evaluated at T or reconstructed afterwards.

I was going to answer that by saying decision-time evaluation of the
exact object establishes use. It does not, at least not to the standard
we have been applying here. From the artifact, an evaluated object and a
reconstructed one are the same bytes. Knowing that the decision actually
used that object as its authoritative condition set requires another fact
about the decision path.

That is not a defect in Henri's construction. It is why the retrospective
requirement has to carry the weight.

I think Mikhail's split gives us three things a verifier at T+n has to
establish:

1. The evidence determines one condition set for the relying decision.

2. That condition set actually governed the decision at T.

3. An independent party at T+n can establish both facts from evidence
   whose binding to the decision was fixed no later than T, without the
   cooperation of either participant and without depending on the
   continued validity of any credential, key, or agent instance.

Unique selection is part of the first. If several candidates remain
compatible with what an independent party can verify, the first has not
been met.

The reconstruction problem is why the third says the binding, rather than
necessarily the later proof, has to be fixed by T. Otherwise the same
bytes can be manufactured afterwards to describe the outcome.

Bradley, I do not think this dissolves your T versus T+n distinction. I
think it sorts what belongs on each side.

At T, the relying party still has to be able to establish the conditions
on which it is being asked to rely before it acts. The counterparty is
present, so interaction can be part of that. I would keep that as its own
obligation.

At T+n, nobody should need either participant. The verifier has to
establish what actually governed the earlier decision. The three parts
above decompose that retrospective claim, not the decision-time one.

The mechanisms then line up without any of them becoming the requirement.

Content addressing bears on identity and selection. Decision-time
evaluation of the bound object bears on actual use. An independent
anchor, durable receipt, forward-secure record, or equivalent external
fact bears on whether the binding can still be established later and
cannot be rewritten retroactively.

None supplies the other two, which is why it belongs in the text before
the mechanisms harden around it.

Bradley, this also replaces the question I was going to ask about whether
your anchoring distinguishes candidates. Henri's construction made that
the wrong question. The better one is the one Mikhail put to Henri: does
the relying decision evaluate the same bound object whose durable
representation is later checked, or is the later record reconstructed
from the same inputs?

If it evaluates the same bound object, that is materially stronger. The
remaining question is what makes that decision-time use independently
establishable at T+n without asking either participant.

The refusal-pattern property stays separate. Henri's reason is the useful
one: joining it to unique selection lets an implementation deliver the
first and appear to have delivered privacy as well. It has not. RFC 9942
Section 6.1 gives the neighbouring log-length example; I would leave that
as a separate privacy requirement rather than make REQ-8 carry it.

Bradley, if this matches the direction of the text you are drafting, I
would still rather fold it into yours than start another version. If it
does not, say so before you write. The difference is cheaper to settle
now.

Doug

From: Mikhail Sergeev <[e-mail]>
Date: Wednesday, August 19, 2026 at 11:36
To: [e-mail] <[e-mail]>
Cc: Douglas Wadkins <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Agentproto] Re: Session lifecycle [was: Re: Sussing out points of disagreement on the charter]

Henri,

Binding to the act is a better answer than the one I gave, and I would
rather say so plainly than fold it in quietly. A hiding commitment
establishes uniqueness by adding a rule about how many commitments a
party may make. Content-addressing the record to the grant and the
runtime arguments establishes a unique identification of the
grant/action pair by leaving nothing to choose. There is no selection
step to constrain, because a different action produces a different
record. That is the stronger construction and it needs no anchor at all.

It also sharpens what the property should say. Unique selection is a
statement about what the evidence determines, not about how it was
produced, so both routes satisfy it and neither belongs in the
requirement text. Your implementation is the reason to state the
property rather than a mechanism: it is already satisfiable, by a route
nobody in the thread had named.

One question before I treat the first determination as closed, because I
think content-addressing establishes slightly less than it first
appears.

It settles which condition set the record identifies, absolutely. What I
am less sure it establishes by itself is that this was the set that
governed the relying decision at T. A record deterministic in the grant
and the arguments is byte-identical whether it was produced at the
decision or reconstructed afterwards. Identity to the act is not by
itself use at the decision.

So: does your implementation make the decision consume that exact
content-addressed object, or does it only make the later record
deterministically reconstructible from the same grant and arguments? If
the former, you have a construction that closes the first determination,
and what closes it is decision-time consumption rather than
content-addressing on its own.

If that reading is right, the shape is complementary rather than
competing. Act-binding with decision-time consumption would give the
first determination and leave the second open. Anchoring has the mirror
shape: it can establish prior existence without establishing which
candidate governed. Neither mechanism, taken by itself, gives both, and
I think that is worth writing down before text exists, because an
implementation delivering either one will otherwise read as delivering
the requirement.

There may be a third thing here rather than two: which conditions the
record identifies, whether those conditions were used at the decision,
and whether that fact can later be established without the participants.
Your construction clearly speaks to the first; if the decision consumes
that exact object, it speaks to the second as well. Doug's clause is
aimed at the third.

On keeping the privacy property apart, your reason is better than mine.
I argued they are different properties. You argue that joining them lets
an implementation claim both by delivering the first, which is the
failure mode rather than the taxonomy. Take yours.

I also want to note what you did in the paragraph about deny records,
since it is the behaviour this thread should be rewarding. You stated a
property of your own system that makes your position worse, unprompted,
in the same message in which you showed your mechanism is stronger than
mine. That is the harder half of making a grounded claim.

You already pointed me to tests/vectors and to the standalone checkers.
I am going to run those before saying anything stronger about what the
construction establishes. Bradley's point yesterday about wanting a
second implementation before treating this as settled is also useful
here: I do not yet know whether the checkers amount to that, but they
give us an independent surface against which to test the first
determination.

One unrelated thing I will send you off-list.

Mikhail

On Wed, Aug 19, 2026 06:28 AM, Henri Sirkkavaara <[e-mail]<mailto:[e-mail]>> wrote:
Mikhail,

Unique selection is the right property and it is the one I would state. Your falsification case is exact: five anchored candidate sets, one presented later, prior existence satisfied and nothing distinguishing the set that governed from the four that did not.

One note from having built this rather than reasoned about it, since you say you have not tested the property in an implementation. It is satisfiable without a hiding commitment, by binding the decision to the act instead of to time.

In draft-sirkkavaara-vaara-receipt the authorization record carries, inside one signed payload, a grantFingerprint over the canonical signed grant and an argsCommitment over the exact runtime arguments of the action being decided. The record is the decision, not a claim about one, and it is content-addressed. There is no later step at which an issuer chooses which anchored candidate governed, because the binding is to that action's digest and a different action produces a different record. Anchoring five candidate sets by T is possible and it buys nothing, since none of them is bound to the act.

That covers selection. It does not cover the second property you raise, and I would not want it read as if it did. Committing per decision makes refusals countable by whoever sees the commitments, and your point that batch size alone still carries the count is correct. Our records are emitted on deny with the same verifiability as on allow, which is a property I would defend for auditability and which makes the privacy exposure worse rather than better. Uniform commitment across all decisions is the shape that helps, and we do not do it.

So I would state both properties, and I would keep them apart. Unique selection is achievable today and I can point at running code. Indistinguishability of refusals is not solved by the same mechanism and stating it as one property would let an implementation claim both by delivering the first.

The code is src/vaara/credential/_authorization_receipt.py and the vectors are under tests/vectors, each with a checker that imports none of my code.

The other five are unwritten and that is fine. Anton owes you files, Walter can wait, Richard Kettlewell's PKIX thread is not yours.

Henri Sirkkavaara
Vaara - Runtime execution layer for AI agents
Built to see over the noise.
vaara.io<https://vaara.io>
Helsinki, Finland

On Wednesday, August 19th, 2026 at 14:50, Mikhail Sergeev <[e-mail]<mailto:[e-mail]>> wrote:
Doug, Sumit, Bradley,

The reduction looks right to me. I think one property implicit in the
first determination should be made explicit: the evidence has to
establish not only prior existence, but unique selection for the relying
decision at T.

A simple falsification case is a party that anchors five candidate
condition sets by T and later presents one of them as the set that
governed the decision. Prior existence passes. Unique selection does
not. Nothing in the anchor distinguishes that case from one in which the
party decided on the first set and presented the third. Unless the
evidence available to an independent verifier rules out the other four
as governing that decision, the first determination has not been
established. My concern is not that the requirement admits the case; it
is that the wording does not make the reason for the failure explicit,
and the reason is that the anchor constrains existence and not
selection.

So I would state the implied property. At T, the anchored evidence must
determine a unique selection: exactly one condition set as the one
governing the decision, rather than merely include the set later
presented. As long as more than one anchored candidate remains
compatible with what an independent party can verify, what has been
established is only that the presented set was among the candidates
available by T, which is a weaker claim wearing the same words.

Transparency does not close this on its own, which I think supports
stating the property rather than pointing at a building block.
Non-equivocation in Section 5.1.3 of RFC 9943 is a property of the
registered sequence: there is no fork in the Signed Statements accepted
by the TS and committed to the VDS. It constrains the VDS, not the
Issuer's later choice among multiple registered statements. Section 9.1
says that, unless the Registration Policy advertises otherwise, a

Relying Party cannot assume that the ordering of Signed Statements in
the VDS matches their ordering of issuance. A Receipt establishes
inclusion, and the architecture separately records registration time.
Neither establishes which registered statement governed the decision at
T.

One consequence bears on whether the property is satisfiable in the case
that motivated the thread. Bradley raised the refusal case, and that is
also the case in which third-party anchoring is most privacy-sensitive.
Publishing a refusal when it occurs exposes the timing and frequency of
refusals to the anchor operator. In an execution-governance deployment,
that pattern is not neutral information.

There are mechanisms that satisfy uniqueness without disclosing content.
By T, a party could anchor a hiding commitment bound to the decision and
open it at T+n, under a one-commitment-per-decision rule or an
equivalent verifiable selection rule. I offer that as an example of what
the property permits rather than as something the requirement should
name.

Hiding the refusal pattern is a second property and needs more than
that. It would require refusal commitments to be indistinguishable from
other anchored traffic, for example by committing all decisions in a
uniform form, or by batching and padding them with other traffic, since
batch size alone can still carry the count. RFC 9942 makes a
neighbouring point in Section 6.1: some structures and proofs reveal the
log length at inclusion, and where a log contains only a particular kind
of entry, that can disclose the number of previous events. Its example
is a log of breach notices.

Those are privacy properties the current wording does not express. The
specific mechanisms can remain implementation choices under them, as you
say, but I would rather see the properties stated than leave each
implementation to rediscover them.

I have not tested this decision-binding property in an implementation. I
am reasoning here from the requirement text and the cited RFCs.


Mikhail

On Tue, Aug 18, 2026 03:49 PM, Douglas Wadkins <[e-mail]<mailto:[e-mail]>> wrote:
Bradley, Sumit,

Bradley, housekeeping as may save a rewrite. Your message answers my post from the 17th rather than the one from this morning, which is fine, but the numbering moved under us today.

Chong's -01 announcement went out at 09:01 UTC. What we have all been calling REQ-6 is REQ-8 in the current draft. REQ-6 is now a different requirement about establishment states. Worth knowing before you write text against a number.

On the substance, I dropped the thing you picked up.

You took the binding point from the end of the 17th and put the weight there, which is right. My post this morning stated the T and T+n properties as independent and did not carry the join forward. Sumit's divergence case is what that omission looks like from outside, and I would rather have it found now than after text exists.

Sumit, your unfalsifiability point is the strongest thing in this thread, and I think it reaches one step further.

Non-divergence stated over two artifacts is not independently falsifiable if the only evidence of what was evaluated at T is the evidence presented at T+n. A record can say it evaluated X after having evaluated Y, and the pair can remain internally consistent. Nothing in the pair can contradict the claim about T.

One extension, which I think changes the clause rather than qualifies it.

The same-object branch closes content divergence, but I do not think it closes the temporal question by itself. Nothing can diverge from itself. But a verifier at T+n still has to establish that the object it is looking at is the object that existed at T.

A single signed object produced afterwards, carrying conditions chosen after the fact, can be perfectly internally consistent. Without some evidence of prior existence outside the parties whose conduct is being examined, it is indistinguishable at T+n from the same object actually present at T.

So the object being independently datable, in your phrase, is not a repair for the weaker branch. Both branches need the same thing: evidence of prior existence that neither participant controls.

I think that collapses the clause.

Instead of "same object" or "derivable from one another" as the requirement, the requirement is that an independent party at T+n can establish two things. First, that the conditions recoverable afterwards are the conditions that governed the relying decision at T. Second, that the evidence establishing this existed no later than T. Neither determination may require the cooperation of either participant.

Same object, derivation, content addressing, receipts, or whatever else then become implementation choices under that property.

That is the reduction arriving for the third time. I think it has now arrived often enough to be written as the requirement rather than noted as a consequence.

On where that leads, and I am not proposing this group do another group's work, there is already a standard building block for part of the shape Sumit describes.

RFC 9943 gives a Transparency Service an append-only, non-equivocating registration history (Section 5.1.3) and gives a relying party a receipt proving that a signed statement was registered.

It does not prove the statement was true, and it does not by itself establish the relationship between registration and T. A receipt establishes that a statement existed no later than its registration. Whether registration preceded the relying decision is a separate fact, and nothing in the log supplies it.

RFC 9943 is explicit about both limits. Section 9.2: "Issuers can make false Statements either intentionally or unintentionally; registering a Statement only proves it was produced by an Issuer." Section 9.1: "Unless advertised in the TS Registration Policy, the Relying Party cannot assume that the ordering of Signed Statements in the VDS matches the ordering of their issuance."

That distinction is useful here. We do not need to reinvent transparency. We do need the requirement that says what fact has to be independently anchored, and how that fact relates to the conditions that governed the decision at T.

I have been working on that boundary and would rather contribute it than have the same gap discovered twice.

Bradley, yes to seeing a draft before it goes to the list. I would rather it were your text with these folded into it than a second one from me.

One practical note. Chong is not on this thread, which is part of Sumit's point about two threads drafting one requirement. I will put a pointer on the other thread so he knows text is coming. When it exists, I think it should land where he is.

Doug

From: Sumit Ahuja <sumit=[e-mail]<mailto:[e-mail]>>
Date: Tuesday, August 18, 2026 at 14:57
To: Bradley B <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Agentproto] Re: Session lifecycle [was: Re: Sussing out points of disagreement on the charter]

Bradley,

Non-divergence is the right constraint. Two properties that each pass while describing different sets is worse than either missing, for the reason you give: a missing property is visible and a divergence is not.

One thing before you draft it.

The clause has two branches and they are not equally checkable. The same object case is checkable by construction, since nothing can diverge from itself, and it is what your implementation does. The derivable-from-one-another case is not, and the reason is the one this thread keeps arriving at.

To check that the conditions evaluated at T and the conditions recoverable at T+n are the same, a reviewer needs to know what was evaluated at T. The only evidence of that is the artifact produced for T+n. A record that says it evaluated X while having evaluated Y is internally consistent, and there is nothing in the pair to contradict it. So non-divergence, stated over two artifacts, is a property that cannot be falsified from the artifacts.

What would close it is the decision-time object being independently datable, so that a reviewer can establish it existed at T rather than being reconstructed afterwards to match. Which is the reduction from the other thread arriving a third time: some part of it has to sit where neither party put it.

So I would either require the same object, which is what makes your implementation's claim strong, or require that the derivation be checkable against something outside the pair. Permitting derivable without that turns a constraint into a statement the reporting party makes about its own consistency.

One smaller thing on the wording. Derivable from one another by a party who holds neither reads two ways: a party holding neither artifact, who then cannot derive anything, or a party occupying neither role, which I take to be the intent. Worth disambiguating before it goes anywhere near charter text.

On the different independence strengths at T and T+n, agreed, and the asymmetry is the part I would keep hardest. At T the counterparty is present, so interaction is available and requiring T+n strength would exclude implementations that are fine. At T+n nobody is present, which is why the stronger clause has to be the one that survives.

On the refusal case generating the record at all, nothing to add. That is the sharpest version of why this cannot be an audit concern deferred elsewhere.

Sumit P. Ahuja
Main Labs

> On Aug 18, 2026, at 19:58, Bradley B <[e-mail]<mailto:[e-mail]>> wrote:
>
> Doug,
>
> Taking the correction. What I wrote is a T+n property and I did not
> say so. Stated alone it does what you describe, which is document an
> unconstrained decision very well.
>
> One distinction I would add, because I think it changes what the
> requirement should say rather than simply doubling it.
>
> The two properties do not need the same independence. At T the relying
> party is present and the counterparty is reachable, so checkability at
> the moment of the decision can rely on interaction. At T+n nobody is
> present and nothing is reachable, which is why my clause is written
> the way it is: without the cooperation of either party to the
> transfer, and without depending on the continued validity of any
> credential, key, or agent instance. Requiring that strength at T would
> rule out implementations that are fine. Requiring only the T strength
> at T+n gives you a record that stops being checkable the moment the
> parties are gone.
>
> So they are separable and should be stated separately. But the thing
> that makes them one requirement rather than two is the binding point
> you named at the end, and I would put the weight there.
>
> Two properties stated independently can be satisfied by a system that
> checks one set of conditions at T and records a different set for T+n.
> Both requirements pass. The record is honest about what it contains
> and wrong about what happened. That is worse than either property
> missing on its own, because a missing property is visible and a
> divergence is not.
>
> What I would ask for is the non-divergence. The conditions checked at
> the moment of the relying decision and the conditions recoverable
> afterwards MUST be the same object, or derivable from one another by a
> party who holds neither. Different artifacts is fine, as you say.
> Different content is the thing to rule out.
>
> The refusal case is where this bites first. If the relying party
> checks at T and refuses, the refusal is the only artifact the sequence
> produces, and there is nothing at T+n to correlate it with. So
> decision-time checkability is not merely a second property alongside
> ex post verifiability. For denials it is the thing that generates the
> record at all. That is the same constraint arriving from a third
> direction: some part of what happened has to be stated into a place
> neither participant controls.
>
> Grounding rather than assertion. In our implementation the
> decision-time check and the durable record are derived from the same
> object rather than produced separately, and the allow and deny records
> were independently compared against a frozen build and a shared
> evidence record by a third party in the current interop event. That
> establishes the records are portable and checkable by someone who is
> not us. It does not establish that non-divergence is generally
> implementable, and I would want a second implementation before anyone
> treats it as settled.
>
> Happy to write this as text: your decision-time checkability clause,
> the determinability clause, and the non-divergence constraint between
> them, stated as properties with no mechanism named. I would rather
> send a draft to you and Henri first than put it on the list cold.
>
> IPR disclosure covering the material behind this:
>
> https://datatracker.ietf.org/ipr/7500
>
> Bradley B
> 11 AI Blockchain Developments LLC
>
>
> On Sun, Aug 16, 2026 at 2:42?PM Chris Hood <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> Imagine a transport protocol that was stateful....
>>
>>
>> -------- Original message --------
>> From: Henri Sirkkavaara <[e-mail]<mailto:[e-mail]>>
>> Date: 8/16/26 1:02 AM (GMT-08:00)
>> To: Bradley B <[e-mail]<mailto:[e-mail]>>
>> Cc: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
>> Subject: [Agentproto] Re: Session lifecycle [was: Re: Sussing out points of disagreement on the charter]
>>
>> On what is worth exchanging at the application layer, one concrete thing: which party's authority a step was taken under, carried per request rather than established once per session.
>>
>> Statelessness removes the session identifier and it does not remove the question. When a workflow crosses domains, the receiving side still has to decide whether this request is covered by an authority granted earlier, and correlation metadata that only groups messages cannot answer that. Grouping tells you these events belong together. It does not tell you the second one was permitted by the first.
>>
>> That is the piece I would not push to another working group. Correlation and binding can ship as separate deliverables, and the base needs to leave room for the second, because an identifier assigned by one party is not something the other party can check. If the base pins correlation as sufficient, implementations will read the identifier as authority and the interop failure appears at the domain boundary, which is exactly where nobody owns it.
>>
>> Concrete example, since you asked for those: a task moves from one operator's agent to another's and back. The return step needs to establish that it is resuming work the first operator authorised, across a gap where neither side holds the other's state.
>>
>>
>>
>> On Saturday, August 15th, 2026 at 02:48, Bradley B <[e-mail]<mailto:[e-mail]>> wrote:
>>
>>> Mirja, Suresh, Sumit,
>>>
>>> Agreed with Sumit that statelessness moves the question up rather than
>>> removing it. I want to name the case that decides where it lands,
>>> because I do not think correlation metadata alone can carry it.
>>>
>>> Mirja, on failure detection at the HTTP layer, agreed as far as it
>>> goes. Transport failure is HTTP's job and the local reaction to it is
>>> a local decision. The distinction I would add is between a request
>>> that failed and a request that was refused, because HTTP cannot
>>> separate those in the direction that matters.
>>>
>>> Sumit's case is the clearest version of the first half: domain B
>>> admits the work, returns success, and never schedules it. That is a
>>> 200. Mine is the mirror. We emit signed decision records for both
>>> allow and deny, and the deny records are the ones auditors ask for. A
>>> denial correlates with nothing, because there is no subsequent action
>>> to associate it with. The whole point of the record is that nothing
>>> happened.
>>>
>>> A status code closes neither gap. It is hop-scoped, so it describes
>>> the outcome between two endpoints and does not survive the hop, and
>>> the third party who needs the record was never on that connection. It
>>> is unsigned and unattributable, so nobody can check it afterwards or
>>> be held to it. And at that layer silence and denial are the same
>>> shape.
>>>
>>> So scope to correlation alone, and the refused action, which is the
>>> record most often needed across a trust boundary, is unrepresentable
>>> by construction. Not hard to represent. Unrepresentable, because
>>> correlation metadata attaches to pairs and there is no second half of
>>> the pair.
>>>
>>> That is one property, and it is narrower than session lifecycle, which
>>> I agree should leave the charter as a term: entering a state a relying
>>> party may need to reason about produces an artifact rather than
>>> silence. Not the states, not the transitions, not full session
>>> semantics.
>>>
>>> On OAuth. Agreed that grants, issuance and revocation belong there,
>>> and I would not ask this group to define them. But OAuth defines
>>> whether an authority exists. It does not define whether a refusal is
>>> stated on the wire between two agents, and that is the part only this
>>> group can decide, because it is a question about what the protocol
>>> carries rather than about what the authorization model says. If a
>>> refusal is never emitted, no audit model downstream can reconstruct
>>> it, because the fact was never stated by anyone. AUDIT can define what
>>> a record must contain. Only this group can decide whether the protocol
>>> carries enough for that record to be honest.
>>>
>>> Grounding rather than assertion: our allow and deny records were
>>> independently compared against a frozen build and a shared evidence
>>> record by a third party in the current interop event. That establishes
>>> the records are portable and checkable by someone who is not us. It
>>> does not establish more than that.
>>>
>>> Sumit, your partition is the right frame and I think refusal is a
>>> third case in it. What carries across, what is discarded, and
>>> separately, what must be stated at all rather than inferred from
>>> silence.
>>>
>>> Happy to contribute text on the refusal-artifact property if it would
>>> help make it concrete.
>>>
>>> IPR disclosure covering the material behind this:
>>> https://datatracker.ietf.org/ipr/7500
>>>
>>> Bradley B
> 11 AI Blockchain Developments LLC
>>>
>>>
>>> On Fri, Aug 14, 2026 at 2:26?PM Sumit Ahuja
>>> <sumit=[e-mail]<mailto:[e-mail]>> wrote:
>>>>
>>>> Suresh,
>>>>
>>>> On failure and migration needing cross-domain agreement rather than being an implementation choice, one thing from the serving side that I think sharpens what has to be agreed, and Mirja's statelessness point makes it sharper.
>>>>
>>>> What a migration needs both sides to agree on is not how the migration is performed but what survives it. Those are separable, and only the second has to be common.
>>>>
>>>> The division I have used is that the commitment survives and the accumulated work does not. On unplanned failure the record of what was granted moves to the resuming party, deliberately excluding accumulated intermediate state and progress, and the resuming party continues under the original grant without re-entering admission. The flow loses unpinned progress; it does not lose its contract. That is one answer rather than the answer, but the shape is the part that has to be agreed: a resuming party that does not know whether it inherited a commitment or only a task cannot behave correctly either way, and a requester that does not know which it will get cannot decide whether to retry.
>>>>
>>>> Mirja's point about MCP going stateless is where this bites. If the workflow's identity is metadata one endpoint adds to correlate request and response pairs, then a migration has nothing to migrate: the new handler did not supply the correlation and has no protocol-level obligation to recognise it. Statelessness at the transport is the right call and it does not settle this, because it moves the question up rather than removing it. The higher layer she describes is where a workflow either has an identity that outlives the party currently holding it, or it does not, and migration is the case that makes the difference observable.
>>>>
>>>> So if failure and migration are in scope, the minimum I would want agreed is what a resuming party inherits, stated as a partition rather than a mechanism: what carries across, what is discarded, and whether the original grant continues or a new one is required. Everything about how the handoff is executed can stay local.
>>>>
>>>> Sumit P. Ahuja
>>>> Main Labs
>>>>
>>>> On Aug 14, 2026, at 07:34, Mirja Kuehlewind (IETF) <ietf=[e-mail]<mailto:[e-mail]>> wrote:
>>>>
>>>> I think detecting a "failure" could be handled on the HTTP layer, as this is a common case that all protocols need to support. A local reaction when the failure is detected is a local implementation decision. So I guess the question would be is there any other information about the session lifecycle that would be valuable to exchange on the higher/application layer that would be needed to make the right decision to handle the failure (or any other decision within one session). Where I would see a session as actually a set of point-to-point agent communications that are belong to the same workflow (which is probably slightly different then Johnathan's definition but I would be interested to he this thoughts!). I think this leads then to the question we want need to standardize a request and response/accept protocol on the application layer that is not bind to one http/transport communication.
>>>>
>>>> MCP itself is now stateless, meaning that they don't have this notion of session to covers multiple HTTP request anymore. That means they have removed the initialization workflow (which I would rather see as part of a discovery process anyway) and they removed the Mcp-Session-Id. This totally make sense because statefulness is an attack vector. Stateful request/response is also the model used for the same reason on the web. However, agents workflow can be more complex than request a web resource. As such session management is now explicitly left to the higher layer. This is where we should consider additional standardization.
>>>>
>>>> In case of MCP they have a minimum json-based request/response protocol like this (some of this might have changed in the latest version but the details don't mater too much for this discussion right):
>>>>
>>>> Request:
>>>>
>>>> { jsonrpc: "2.0"; id: string | number; method: string; params?: { [key: string]: unknown; }; }
>>>>
>>>> Response:
>>>>
>>>> { jsonrpc: "2.0"; id: string | number; result: { [key: string]: unknown; } }
>>>>
>>>> Error:
>>>>
>>>> { jsonrpc: "2.0"; id?: string | number; error: { code: number; message: string; data?: unknown; } }
>>>>
>>>> I believe the id in these messages would be unique per http request/response in the new stateless version of MCP. So you would probably want to add additional
>>>> metadata that can correlate multiple request/reponse pairs to one session.
>>>>
>>>> A2A specifies aSendMessageRequest object and the response is send as either a Task or Message object (they also have errors).
>>>>
>>>> I think these are good things a as starting point and we could specify something on top to provide a common standard to enable interoperability between these protocols with the goal that it should be easy to be translated/mapped to the existing base pattern in these already deployed protocols.
>>>>
>>>> Mirja
>>>>
>>>>
>>>> On 14. Aug 2026, at 05:19, Suresh Krishnan <[e-mail]<mailto:[e-mail]>> wrote:
>>>>
>>>> Hi Mirja,
>>>>
>>>> On Aug 12, 2026, at 10:05?AM, Mirja Kuehlewind (IETF) <[e-mail]<mailto:[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?
>>>>
>>>>
>>>> I think this is where I see some divergence between what Jonathan and Brian proposed. If you think the failure+migration use case is in scope, there is a need for this to be agreed across domains (and not simply an implementation choice) since the other party also needs to agree with how it is done. If your point is that there might already be mechanisms that can be used that is something we can discuss.
>>>>
>>>> Thanks
>>>> Suresh
>>>>
>>>> _______________________________________________
>>>> Agentproto mailing list -- [e-mail]<mailto:[e-mail]>
>>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>>>
>>>>
>>>> _______________________________________________
>>>> Agentproto mailing list -- [e-mail]<mailto:[e-mail]>
>>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>>>
>>>>
>>>> _______________________________________________
>>>> Agentproto mailing list -- [e-mail]<mailto:[e-mail]>
>>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> 11 AI Blockchain Developments LLC
>>>
>>> Brad B - Inventor
>>>
>>> ? [e-mail]<mailto:[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]<mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>>
>>
>> Henri Sirkkavaara
>> Vaara - Runtime execution layer for AI agents
>> Built to see over the noise.
>> vaara.io<http://vaara.io>
>> Helsinki, Finland
>>
>> _______________________________________________
>> Agentproto mailing list -- [e-mail]<mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>> _______________________________________________
>> Agentproto mailing list -- [e-mail]<mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>
>
>
> --
>
>
> 11 AI Blockchain Developments LLC
>
> Brad B - Inventor
>
> ? [e-mail]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
Agentproto mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>