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

[Sumit Ahuja <[e-mail]>]

Chong, Doug, Bradley,

One word, offered because I think it lets the boundary Chong is drawing and the property Doug and Bradley want both stand without either giving way.

The disagreement is about where determinability lives. Chong's case for a separate document is reasonable and Doug's objection to deferring it is also right: a later document can define how information is recorded and verified, and cannot repair a case where the information was never made observable while the parties were present. Those are compatible if the base document declines to specify determinability without foreclosing it.

As written it forecloses it. REQ-8 says lifecycle events MUST be expressible and observable by the affected entities. That reads as the complete set of parties who must be able to observe, so a later document requiring observability by a party who was not present has to amend REQ-8 rather than extend it, and amending a published base requirement from a companion document is the expensive version of this.

The change is:

  ... MUST be expressible and observable at minimum by the affected
  entities.

That adds no obligation, names no additional party, and requires nothing of an implementation that the current sentence does not already require. It changes a ceiling into a floor, so a document that later requires more is extending rather than contradicting.

If the determinability property ends up in the base document after all, the word is harmless. If it goes into a companion, the companion has somewhere to attach. If it never gets written, nothing has been lost.

On the two-thread problem, resolved from my side: Bradley writing one text and sending it to all of you at once is the right answer and I have nothing further on it.

Sumit P. Ahuja
Main Labs

> On Aug 20, 2026, at 00:51, Bradley B <[e-mail]> wrote:
> 
> Chong,
> 
> The layering is right and I am not arguing with it. If B delegates part of
> its work to C, C is not a peer of the A to B session, and nothing A granted
> B transfers to C by that act. B stays responsible, and A and C needing to
> establish a new session if they are to interact directly is the correct
> consequence. I would not want the session document to define task handoff,
> and I would not want it to define an audit model.
> 
> But I do not think the material I have been arguing for sits on the far
> side of that line, and I would rather test that against your text than
> against my summary of it.
> 
> REQ-8 in -01 opens:
> 
> Session revocation, transfer or delegation of session state, loss
> of a negotiated capability, declaration of a newly available
> capability, and proposed changes to the negotiated capability set
> MUST be expressible and observable by the affected entities.
> 
> and later:
> 
> The authority and inheritance semantics applicable to a transfer,
> delegation, or state change MUST be explicit before an entity
> relies on the resulting state.
> 
> 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.
> 
> Delegation is already normative in REQ-8, and so is not silently discarding
> an applicable constraint. The question is not whether to admit delegation
> into the base session requirements. It is already in them.
> 
> What REQ-8 does not have is the part that survives the session. Both
> sentences above are addressed to the affected entities, at the moment one
> of them relies on the resulting state. Neither says anything about a party
> who was not present at origination, asking afterwards, when neither peer is
> reachable.
> 
> That gap is one sentence, not a separate document:
> 
> Where a lifecycle event transfers or delegates session state, a
> party that was not present at origination can determine which of
> the originator's conditions were carried and which were dropped.
> That determination does not require the cooperation of either
> party to the transfer, and does not depend on the continued
> validity of any credential, key, or agent instance involved.
> 
> No encoding, no chain, no log, no evidence format. It constrains what a
> conforming implementation has to leave behind, not how it represents it.
> It is the same shape as the MUST NOT you already have, moved from the
> moment of reliance to afterwards.
> 
> One thing I would rather raise plainly than leave sitting. The -01
> Acknowledgments credit me with tightening the authority boundary on
> conditions carried across transfer. I read that as generous and I am
> grateful for it. But if that material is out of scope for this document,
> the acknowledgment points at something the document does not contain. I
> would rather ask which you intended than guess. If the answer is that the
> boundary made it in and the determinability did not, that is a coherent
> position and I would just like it said.
> 
> Doug asked the question that decides what is useful next, and I do not
> think it has been answered:
> 
> 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.
> 
> I would add one to it. If this stays out of the session requirements, do
> you intend to write the separate requirements document yourself, or are you
> naming a gap for someone else to fill?
> 
> One process note. Sumit flagged that the same requirement is being drafted
> on two threads at once, which is how two documents end up saying nearly the
> same thing differently. Doug and I are converging on a single text on the
> session lifecycle thread and I am writing it. Whatever you decide about
> scope, I would rather you saw it before it went anywhere, so I will send it
> to you at the same time as to Doug and Henri.
> 
> 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