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

[Bradley B <[e-mail]>]

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