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

[chong feng <[e-mail]>]

Hi all,

Thank you for the detailed discussion. I think it is important to
distinguish the session relationship from application-layer task
coordination.

The session requirements draft currently assumes a session between two
authenticated peer entities. If entity B delegates part of its work to
entity C, that is an application-layer decision between B and C. It
does not make C a peer of the existing A–B session, and it does not
transfer to C any authority granted by A to B. B remains responsible
for satisfying the authorization and constraints applicable to the A–B
session.

If A is expected to interact directly with C, then A and C need to
establish a new session, including authentication, capability
negotiation, and the applicable authorization decisions. C cannot
simply replace B as a peer through a transfer of session state.

>From this perspective, application-level task handoff, delegation
chains, cross-domain responsibility transfer, and the durable evidence
needed for audit or later accountability are outside the scope of the
base session requirements. The session specification should not define
how an application coordinates work among additional entities or how
an audit system records and verifies those decisions.

These are nevertheless useful standardization topics. A separate
requirements document could define the properties needed for
application-level delegation, task handoff, accountability, and audit,
including what information must remain independently determinable
after an action or transfer. Keeping that work separate would allow it
to develop without introducing a particular workflow or audit model
into the basic session abstraction.

I will clarify the lifecycle text in the next revision so that
delegation to a third party does not imply a change of session peers,
and replacement by a different peer requires establishment of a new
session.

Best regards,
Chong

Douglas Wadkins <[e-mail]> 于2026年8月19日周三 06:51写道：
>
> Sumit, answered on the session-lifecycle thread, since that is where Bradley's clause and your objection to it both are.
>
> Short version for anyone reading only here. Bradley has proposed a non-divergence constraint between the decision-time property and the determinability property. Sumit has shown that stated over two artifacts it cannot be falsified from the artifacts. I think the same problem reaches the same object branch as fabrication rather than divergence, so the fix applies to both and the clause collapses to one requirement. I believe Bradley is drafting.
>
> Chong, text should be being written against REQ-8 in -01 rather than REQ-6 in -00.
>
> Doug
>
> From: Sumit Ahuja <[e-mail]>
> Date: Tuesday, August 18, 2026 at 15:04
> To: [e-mail] <[e-mail]>
> Cc: Douglas Wadkins <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Bradley B <[e-mail]>, Henri Sirkkavaara <[e-mail]>
> Subject: Re: [Agentproto] Sussing out points of disagreement on the charter
>
> Henri, Doug,
>
> Henri, that answers it. Carrying the fingerprint and the capabilities array side by side answers two different questions, which is the distinction I was reaching for and did not state cleanly. A party holding only the record reads the conditions; the fingerprint tells them which grant those conditions came from. The independent checker re-running the evaluation from the conditions and reproducing the verdict is more than I asked about.
>
> Doug, the numbering catch matters and I had it wrong too.
>
> On your two failure cases, I think there is a third, and it was found on the session-lifecycle thread rather than this one, which is the reason for this message.
>
> You have: reconstructible at T plus n with nothing checkable by the receiver at T, and explicit to the receiver at T with nothing determinable afterwards. Both right, and both are one property missing while the other holds.
>
> Bradley's case is that both hold and describe different things. A system checks one set of conditions at the moment of the relying decision and records a different set for afterwards. The T requirement passes, the T plus n requirement passes, the record is honest about what it contains and wrong about what happened. His point about why that is worse than either failing is the part I would keep: a missing property is visible and a divergence is not.
>
> So the enumeration is three rather than two, and the third one is not fixed by stating the first two more carefully. It needs a constraint between them.
>
> The practical reason I am raising it here You are drafting this requirement on this thread. Bradley is drafting the same requirement on the session-lifecycle thread, and his version has a constraint yours does not. Two texts for one property, produced in parallel in two threads, is how two documents end up saying nearly the same thing differently, which is the failure a group of us spent last week preventing between two other drafts. Better to notice now than after Chong has both.
>
> I have not repeated my own view of the constraint here because I put it to Bradley earlier today and it will arrive with whatever he sends. This is only to say the two threads are drafting the same thing.
>
> Sumit P. Ahuja
> Main Labs
>
> On Aug 18, 2026, at 17:49, Henri Sirkkavaara <[e-mail]> wrote:
>
> Sumit, Douglas,
>
> Sumit, on Section 6.4. The capabilities are carried in the record in the clear, so the gap you described does not exist in the implementation.
>
> vaara.authorization/v0 holds grantFingerprint and a capabilities array side by side inside the signed payload. The fingerprint binds which grant was evaluated. The array carries what was evaluated, as the condition set itself, so a party holding only the record reads the conditions without holding the grant. The committed vector is tests/vectors/authorization_v0/allow/evidence.json, and its capabilities array is three conditions in the clear: amount le 500, vendor in acme or globex, destination eq 0xABC. The deny case is the same record shape with verdict deny and reason capability_exceeded.
>
> The independent checker then re-runs the evaluation from those conditions against the arguments and reproduces the verdict, importing none of my code. So a third party recomputes the decision and does not have to take the record's word for it. tests/vectors/authorization_v0/_check_independent.py, ten verdicts across the two cases.
>
> Your general point stands and I should have drawn the distinction myself. A content address proves that a grant you already hold is the grant that was bound, and it does not hand you the grant. Vaara carries both because they answer different questions, and the requirement reads better without the mechanism in it.
>
> Douglas, thank you for going and checking the numbering. I have been saying REQ-6 too. On the substance, I read -01 the same way you do: the first sentence of REQ-8 closes the escape route Bradley identified, and the determinability property is not there. The property, stated without a mechanism, is that a party not present at origination can determine which conditions were carried and which were dropped, without the cooperation of either party to the transfer, and without depending on the continued validity of any credential, key or agent instance involved.
>
> Your point that integrity and availability fail separately is the one I would keep in front of whoever drafts it. A digest establishes that a candidate condition set is the right one and does not put that set in anyone's hands, so determinability can fail through unavailability while integrity holds. Both halves have to be required or the requirement only bites in the easy case.
>
> Henri Sirkkavaara
> Vaara - Runtime execution layer for AI agents
> Built to see over the noise.
> vaara.io
> Helsinki, Finland
>
> On Tuesday, August 18th, 2026 at 18:29, Douglas Wadkins <[e-mail]> wrote:
>
> Chong, Sumit, all,
>
> A bookkeeping note first, because the thread and the draft have drifted, and anyone arriving now will otherwise read the wrong requirement.
>
> The REQ-6 we have been writing text for is the -00 numbering, where REQ-6 was Session Lifecycle Management:
>
> "Session revocation, transfer of session ownership, and the termination of negotiated capabilities MUST be expressible explicitly by either entity."
>
> In -01 that subject is REQ-8. REQ-6 in -01 is Establishment Completion and Failure Handling, which is a different requirement.
>
> This is not pedantry. Chong's -01 announcement went out at 09:01 UTC, and the thread has carried on saying REQ-6 since, mine included until I went and checked. Worth fixing before someone cites REQ-6 in a discussion about pending and established states.
>
> On the substance.
>
> REQ-8 as published reads:
>
> "A lifecycle event MUST NOT silently broaden authorization, discard an applicable constraint, or present a capability as available for an operation whose prerequisites are no longer satisfied. The authority and inheritance semantics applicable to a transfer, delegation, or state change MUST be explicit before an entity relies on the resulting state."
>
> The first sentence captures an important part of where the thread landed. A transfer cannot quietly shed a constraint, which was the escape route Bradley identified.
>
> The other property the transfer sub-thread converged on does not appear to be in -01.
>
> The discussion got there in stages. Sumit named the observation gap. Henri turned it into a determinability requirement. Sumit strengthened the independence condition to neither party to the transfer. Henri proposed a concrete construction and pointed to vectors, and Bradley pulled the construction back out of the normative wording while preserving the property.
>
> The resulting requirement, as I understood the discussion, was that a party not present at origination must be able to determine which conditions were carried and which were dropped, without requiring the cooperation of either party to the transfer, and without depending on the continued validity of any credential, key, or agent instance involved.
>
> I have read -01 looking for that property and do not find it in REQ-8 or elsewhere.
>
> Chong, was that a judgment call, or did the text freeze before those messages landed? Either is fine but it just changes what is useful next.
>
> Sumit, your message this morning adds another reason Bradley's mechanism neutral formulation matters.
>
> As I read it, integrity and availability can fail separately. A digest can establish that a candidate set of conditions is the right one without putting that set into anyone's hands. So determinability can fail through unavailability while integrity holds perfectly.
>
> The same thing can happen at the other end. What would have let a receiver check a condition may be reachable only through a path that is not available at the moment it acts.
>
> That is the same problem I think REQ-8 now has on a different axis.
>
> "Explicit before an entity relies on the resulting state" is a decision-time requirement. It says something has to be available to the relying entity before it acts.
>
> The transfer discussion was establishing a different temporal property: what another party can determine afterwards.
>
> I do not think the decision time language should come out. I think it identifies the other temporal half of the problem, even if it does not yet state the verification property at full strength.
>
> Explicit is not the same as independently checkable. A condition can be stated to the relying party and still be unverifiable by it. But the slot is the right one.
>
> The two properties are independent.
>
> A transfer can be fully reconstructible at T+n and have given the receiver nothing it can independently check at T.
>
> A transfer can be explicit to the receiver at T and leave an independent party unable to determine at T+n what survived it.
>
> If REQ-8 is going to say "explicit," I think it is worth stating both the audience and the time property. Those are two independent properties: what the relying party must be able to establish before acting, and what a party not present at origination must be able to determine afterwards.
>
> To be clear about scope: I am not proposing a mechanism, encoding, or trust model. This is only a requirement on what must be independently establishable, by whom, and when.
>
> Doug
>
> From: Sumit Ahuja <sumit=[e-mail]>
> Date: Tuesday, August 18, 2026 at 06:40
> To: [e-mail] <[e-mail]>
> Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Bradley B <[e-mail]>
> Subject: [Agentproto] Re: Sussing out points of disagreement on the charter
>
> Bradley, Henri, Chong,
>
> Bradley's version is the one, and removing the encoding fixes something beyond the requirements-discipline reason he gives. Worth saying, because it is a second and independent argument for the same rewrite and Chong is choosing between two texts.
>
> I was drafting an objection to the content-address wording on technical grounds. A content-address binding proves that a grant you already hold is the grant that was bound. It does not give you the grant. grantFingerprint over the canonical signed grant lets a party verify a candidate set of conditions against the record; it does not let them recover which conditions applied if they do not already have them. Henri's sentence asked a party to determine from the artifact alone which conditions applied, and a digest cannot do that.
>
> Which matters most for the last clause. If the determination needs the preimage, and the parties to the transfer are the ones holding it, then determinability depends on their cooperation after all, arriving through availability rather than through attestation. Integrity and availability are different properties and the requirement needs both.
>
> Bradley's text does not have that problem, because determining which conditions were carried and which were dropped entails having them. Removing the mechanism removed the mechanism's limitation, which is a good argument for the general rule as well as for this case.
>
> Henri, my question about Section 6.4 stands as a question rather than an objection now. If the signed payload carries the evaluated capabilities in a form from which the conditions are recoverable, the gap I described does not exist in your implementation and the vectors would show it. That is worth knowing for the non-normative pointer even though it no longer bears on the requirement.
>
> Sumit P. Ahuja
> Main Labs
>
> > On Aug 17, 2026, at 17:52, Bradley B <[e-mail]> wrote:
> >
> > Henri, Sumit, Chong,
> >
> > Sumit's "neither party to the transfer" is the right strengthening and I
> > would take it over anything I wrote. The receiving party holds the task
> > without the conditions, which makes it the party with an interest in the
> > question staying hard to answer. Excluding only the transferor leaves
> > that open.
> >
> > One objection, and it is to the proposed REQ-6 text rather than to the
> > requirement behind it.
> >
> > Henri, your text says the conditions MUST be bound to the task by content
> > address. That is a mechanism. It is a good one, and it is the one I would
> > reach for, but the sentence one message earlier in this thread was that
> > the requirement has to say what must be true of the transfer and not how
> > the conditions are represented or carried. Content addressing is a way of
> > satisfying the property. Writing it into the requirement makes it the
> > property.
> >
> > The cost is not theoretical. A requirements document that names a binding
> > construction rules out satisfying implementations that do not use it, and
> > it puts an editor in the position of picking between candidate encodings
> > at the requirements stage, which is the argument we have all been making
> > should happen later or elsewhere. It also invites the reading that a
> > conforming implementation is one that produces the right shape of artifact
> > rather than one that answers the question.
> >
> > The property is determinability. I would write it as:
> >
> > The conditions an originator attaches to a task carry with the task
> > across transfer. For a task already transferred, a party that was not
> > present at origination MUST be able to determine which of the
> > originator's conditions were carried and which were dropped. That
> > determination MUST NOT require the cooperation of either party to the
> > transfer, and MUST NOT depend on the continued validity of any
> > credential, key, or agent instance involved.
> >
> > That is Sumit's requirement and your last clause, with the encoding taken
> > out. Content addressing then belongs where it is useful, as a named
> > example of a construction that satisfies it, in non-normative text or in
> > the security considerations. draft-sirkkavaara-vaara-receipt Section 6.4
> > is a good pointer for that, and your cross_org_handoff_v0 vectors are a
> > good demonstration that the property is satisfiable in practice, which is
> > worth more to this than the MUST would be.
> >
> > Henri, on your point that the draft never uses the word conditions and the
> > concept lives under different vocabulary: saying that plainly was the
> > right call and it is the part of your message I would keep verbatim. Chong
> > needs to know the concept is borrowable and that the transfer itself is
> > not defined there.
> >
> > Sumit, on where this lands. You noted the requirement constrains the
> > satisfying mechanisms to a narrower class than they look, because a record
> > held only by a participant does not satisfy it. Agreed, and I want to name
> > that this is the same place the refusal question lands on the session
> > lifecycle thread. There, a denial correlates with nothing because there is
> > no second half of the pair, so the record has to be stated rather than
> > inferred, and it has to be checkable by someone who was not on the
> > connection. Here, a dropped condition has to be determinable by someone who
> > was not party to the transfer. Two different arguments arriving at the same
> > constraint: some part of what happened has to be stated into a place
> > neither participant controls, or the question is unanswerable afterwards by
> > construction.
> >
> > I do not think that resolves the charter scope question by itself. It does
> > suggest the two threads are not separate discussions, and that whatever the
> > charter says about correlation has to leave room for both.
> >
> > Chong, same as before: take, adapt, or leave any of it, and no attribution
> > needed.
> >
> > IPR disclosure covering the material behind this:
> > https://datatracker.ietf.org/ipr/7500
> >
> > Bradley B
> > 11 AI Blockchain Developments LLC
> >
> >
> > On Mon, Aug 17, 2026 at 5:07 AM Henri Sirkkavaara <[e-mail]> wrote:
> >>
> >> Sumit,
> >>
> >> Neither party to the transfer is the right strengthening and I would take it over my own wording. A determination that depends on the receiving party carries the same defect, arriving one hop later.
> >>
> >> On the drafting point, start with what the draft does not have. draft-sirkkavaara-vaara-receipt never uses the word conditions, so searching for that term will come up empty. The concept is there under different vocabulary, in Section 6.4. An authorization record binds the signed grant by content address, grantFingerprint = sha256(JCS(signed grant)), together with the evaluated capabilities and the verdict, inside the signed payload. A party who was not present recomputes the fingerprint from the grant and matches it against the record, so which conditions applied is determinable from the artifact without either party's cooperation.
> >>
> >> The draft does not define the transfer itself. It gives the artifact shape and the determinability property, and stops there. I would rather say that than have an implementer discover it.
> >>
> >> Text for REQ-6, if it is useful:
> >>
> >> The conditions an originator attaches to a task MUST be bound to the task by content address, such that a party that was not present at origination can determine from the artifact alone which conditions applied and whether they were preserved across a transfer. That determination MUST NOT require the cooperation of either party to the transfer.
> >>
> >> The second sentence is your requirement, and I have only put it into wording.
> >>
> >> Vectors for the case exist at tests/vectors/cross_org_handoff_v0, commit 37d2204: one organisation's signed record verified offline by a third party years later under a key that has since rotated, with a checker that imports no issuer code. I can point the editors at those if the requirement lands.
> >>
> >> On Sunday, August 16th, 2026 at 19:50, Sumit Ahuja <sumit=[e-mail]> wrote:
> >>
> >>> Henri,
> >>>
> >>> You are right and I had it wrong. I read the gap as needing the originator to be told, which is push and is a mechanism, and determinability does not need anyone present at the time. The originator asks afterwards from what the transfer left behind. That closes it at the requirements level and your formulation is the one I would use.
> >>>
> >>> One extension to the last clause, which is the load-bearing one. It excludes the cooperation of the transferring party, and the same argument reaches the receiving party. After a transfer that dropped conditions the receiving party holds the task without them, which makes it the party with an interest in the question being hard to answer. A determination that depends on its cooperation at the time of asking has the same failure as one depending on the transferor's, arriving one hop later.
> >>>
> >>> So I would write it as neither party to the transfer rather than the transferring party specifically. That is a stronger requirement and it constrains what can satisfy it: a record held only by a participant does not, and the thing that does has to sit somewhere neither of them controls. Which is the same shape as the ordering discussion on the other thread, where both branches reduce to needing something in the observational domain that is not either party. Worth knowing the requirement lands there, because it means the satisfying mechanisms are a narrower class than they look.
> >>>
> >>> On the drafting point, yes please. If draft-sirkkavaara-vaara-receipt already defines originator-attached conditions travelling with a task, that is the concept -00 is missing, and text that exists is better than text three of us invent in a thread. Chong asked for exact wording on REQ-3 and took it, so I expect the same here.
> >>>
> >>> Sumit P. Ahuja
> >>> Main Labs
> >>>
> >>>> On Aug 16, 2026, at 18:16, Henri Sirkkavaara <[e-mail]> wrote:
> >>>>
> >>>> Sumit,
> >>>>
> >>>> On the residue, I think it is closable at the requirements level, and Bradley wrote the sentence that closes it one requirement earlier. His temporal accountability text says a party must be able to determine the binding that was in force at the time of an action, and that the determination must not depend on the continued validity of the credential, key, or agent instance involved. That is the same shape your gap needs, applied to conditions instead of bindings.
> >>>>
> >>>> The doubt comes from reading the gap as a notification problem. Notification is push, it needs the originator to be a party to the new establishment, and you are right that it is a mechanism. Determinability runs the other way. The originator asks afterwards, from whatever the transfer left behind, and never has to be present at the establishment or told anything at the time. A requirement can state that a question must be answerable without stating who sends what to whom.
> >>>>
> >>>> So the residue could require that for a task already transferred, a party can determine which of the originator's conditions were carried and which were dropped, and that the determination does not depend on the cooperation of the transferring party at the time of asking. That last clause is what stops it collapsing back into notification, since a transferring party that must be asked can decline.
> >>>>
> >>>> Your drafting point is the more important of the two and I would resolve it first. draft-sirkkavaara-vaara-receipt defines originator-attached conditions travelling with a task, and the record that lets the determination above be made after the fact, so if -00 needs the concept introduced there is text to borrow.
> >>>>
> >>>> Henri Sirkkavaara
> >>>> Vaara - Runtime execution layer for AI agents
> >>>> Built to see over the noise.
> >>>> vaara.io
> >>>> Helsinki, Finland
> >>>>
> >>>> On Sunday, August 16th, 2026 at 19:04, Sumit Ahuja <sumit=[e-mail]> wrote:
> >>>>
> >>>>> Bradley, Chong,
> >>>>>
> >>>>> Bradley is right and the amendment is better than what I sent. Permitting a transfer to state that the originator's conditions lapsed makes transferring once the cheapest route around any condition, and I had written a requirement that a bad actor satisfies by disclosure. Treating a condition-dropping transfer as a new establishment rather than a transfer is the right correction.
> >>>>>
> >>>>> Two things to reconsider.
> >>>>>
> >>>>> The first is the residue of the fix, and Bradley named the problem himself before proposing it. The rule stops the misrepresentation: nobody can call it a transfer while dropping what the transfer was supposed to carry. It does not close the observation gap, because a new establishment is between the receiving entity and its new counterparty, and the originator may not be party to it. The originator still learns nothing. Whether that is closable at the requirements level I doubt, since notification is a mechanism, so I would state it rather than leave it: the requirement establishes what a transfer may and may not be called, and does not establish that the originator observes either outcome.
> >>>>>
> >>>>> The second is a drafting question and it is the one I would resolve before -01, because both of us have skipped it. Neither Bradley's text nor mine checks whether the document has a notion of conditions attached by the originator. REQ-4 gives both entities selection rights, REQ-5 separates session establishment from execution authorization, REQ-2 places capability decisions with the entities that hold them. None of them establishes that an originator attaches conditions to a task which then travel with it. We are both requiring the preservation of a thing the document may not define.
> >>>>>
> >>>>> If that concept is not in -00, the requirement needs it introduced first, in Section 3 or in REQ-6 itself, or an implementer reads a rule about preserving something the document never says exists. If it is there and I have missed it, ignore this.
> >>>>>
> >>>>> On the REQ-1 collision, agreed with Bradley's direction. A session that has lost a capability is established with a reduced set and says so, rather than remaining nominally usable.
> >>>>>
> >>>>> Sumit P. Ahuja
> >>>>> Main Labs
> >>>>>
> >>>>>> On Aug 16, 2026, at 08:05, Bradley B <[e-mail]> wrote:
> >>>>>>
> >>>>>> Naveed,
> >>>>>>
> >>>>>> The accountable-entity distinction is the right one and I would like to
> >>>>>> see it in the charter. The agent presents a runtime key; the agent must
> >>>>>> not be authoritative for the binding that names who is answerable for
> >>>>>> it. That is a small property and it does a lot of work.
> >>>>>>
> >>>>>> One tightening, on the tense rather than the wording, and it is the
> >>>>>> part that decides whether this becomes an accountability property or a
> >>>>>> revocation check.
> >>>>>>
> >>>>>> As stated, the property is about the agent's binding and the current
> >>>>>> state of that binding, verified when the relying party asks. That
> >>>>>> covers impersonation and it covers revocation, which are the two cases
> >>>>>> the identity side meets most often. It does not cover the case this
> >>>>>> group keeps arriving at from the other direction: a task that outlives
> >>>>>> the credential, the key, or the agent instance that started it.
> >>>>>>
> >>>>>> If accountability is defined only over the current binding, then when
> >>>>>> the binding lapses the accountability lapses with it. Six months later,
> >>>>>> asking who was answerable for an action taken under that binding
> >>>>>> returns nothing, because the only thing the property ever guaranteed
> >>>>>> was resolvable in the present tense. That is the moment someone
> >>>>>> actually needs the answer, and it is the moment the property has
> >>>>>> stopped holding.
> >>>>>>
> >>>>>> So I would put it as two tenses rather than one:
> >>>>>>
> >>>>>> A relying party must be able to independently verify an agent's binding
> >>>>>> to its accountable entity and the current state of that binding. For an
> >>>>>> action already taken, a party must be able to determine the binding
> >>>>>> that was in force at the time of that action, and that determination
> >>>>>> must not depend on the continued validity of the credential, key, or
> >>>>>> agent instance involved.
> >>>>>>
> >>>>>> The second sentence is the one I care about. It is also the one that
> >>>>>> distinguishes this from work that belongs to OAuth or to an identity
> >>>>>> working group. Issuance, grants, and revocation are theirs. Whether the
> >>>>>> answer survives revocation is a property of what this group is
> >>>>>> standardizing, because it is a property of the record the workflow
> >>>>>> leaves behind, not of the credential system.
> >>>>>>
> >>>>>> Henri, agreed on your tightening, and I think the two go together. The
> >>>>>> weak reading of "independently verify" is that the relying party can
> >>>>>> call the agent's own issuer. The weak reading of the property as a
> >>>>>> whole is that it holds only while the issuer is still answering. Both
> >>>>>> readings leave the relying party depending on the party under
> >>>>>> examination, one at request time and one over time.
> >>>>>>
> >>>>>> Chong, Sumit,
> >>>>>>
> >>>>>> Sumit's REQ-6 point is the right one and I would take the text. One
> >>>>>> change to it before -01, on the second half rather than the first.
> >>>>>>
> >>>>>> The proposed text requires a transfer to state whether the negotiated
> >>>>>> capability set carries across, and whether conditions attached by the
> >>>>>> originator remain in force. For the capability set, stating it is
> >>>>>> exactly right: capability is a matter between the endpoints, the
> >>>>>> receiving entity is a new endpoint, and there is a defensible reading
> >>>>>> either way, so the transfer has to say which.
> >>>>>>
> >>>>>> For the originator's conditions I do not think stating it is enough,
> >>>>>> and I think the two cases are different in kind. A condition attached
> >>>>>> by the originator is a property of the task, not of whoever is
> >>>>>> currently holding it. If the transfer is permitted to state that the
> >>>>>> originator's conditions lapsed, then the conditions are discharged by
> >>>>>> the act of handing the task on, and any holder can shed them by
> >>>>>> transferring once. That is not a corner case, it is the cheapest
> >>>>>> available route around the condition, and it will be found.
> >>>>>>
> >>>>>> The narrower rule, which I think is also the simpler one:
> >>>>>>
> >>>>>> Conditions attached by the originator carry with the task across
> >>>>>> transfer. A transfer states which conditions it carries and their
> >>>>>> source. A transfer that does not carry the originator's conditions is
> >>>>>> not a transfer of that session and must be treated as a new
> >>>>>> establishment, negotiated with the originator's conditions absent and
> >>>>>> disclosed as absent.
> >>>>>>
> >>>>>> That keeps Sumit's requirement, that a transfer must say what survives
> >>>>>> it, and removes the reading where saying "nothing survives" is a
> >>>>>> conforming answer. It also keeps the document mechanism-neutral: it
> >>>>>> says what must be true of the transfer, not how the conditions are
> >>>>>> represented or carried.
> >>>>>>
> >>>>>> The second half of Sumit's note, the REQ-1 collision on capability
> >>>>>> loss, I would resolve the same direction. A session that has lost a
> >>>>>> capability is established with a reduced set and must say so, rather
> >>>>>> than remaining nominally usable. The failure mode is identical: a
> >>>>>> status that quietly means "the parts still working are fine".
> >>>>>>
> >>>>>> On who this bites. Sumit framed it as the receiving entity being unable
> >>>>>> to tell what it holds, which is right, and the worse case is one step
> >>>>>> further out. The originator is the party whose conditions these are,
> >>>>>> and after a transfer the originator is the party least able to observe
> >>>>>> whether they still apply. Expressibility fixes the receiver. It does
> >>>>>> not fix the originator, and the originator is who the conditions were
> >>>>>> for.
> >>>>>>
> >>>>>> Suresh and Mirja: this is the same failure-and-transfer case from the
> >>>>>> charter thread arriving as requirements text, and I think it supports
> >>>>>> Suresh's read that transfer needs cross-domain agreement rather than
> >>>>>> being an implementation choice. What has to be agreed is not the
> >>>>>> transfer mechanism. It is what the transfer is permitted to drop.
> >>>>>>
> >>>>>> Chong, take, adapt, or leave any of it, and no attribution needed.
> >>>>>>
> >>>>>>
> >>>>>> IPR disclosure covering the material behind this:
> >>>>>> https://datatracker.ietf.org/ipr/7500
> >>>>>>
> >>>>>> Bradley B
> >>>>>> 11 AI Blockchain Developments LLC
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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]
> >>>
> >>
> >> Henri Sirkkavaara
> >> Vaara - Runtime execution layer for AI agents
> >> Built to see over the noise.
> >> vaara.io
> >> Helsinki, Finland
> >
> >
> >
> > --
> >
> >
> > 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]
>
>