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

[Bradley B <[e-mail]>]

Suresh,

Answering question 3 in depth because it is the one I can bring
implementation evidence to, and the others briefly.

3. Correlation only, or proof of binding as well?

Binding, and the reason is structural rather than aspirational: a
correlation identifier without proof of binding lets any party assert
membership in an interaction, which converts the identifier from a
coordination tool into an attack surface the moment anything
downstream relies on it. Ted's point in the PR 77 discussion, that an
identifier alone is too easy to fake, is the same observation from the
protocol side.

But Brian's binding envelope text contains a question it does not
answer, and Orie's review comment found it: "bound by a party entitled
to bind it" implies something that grounds the entitlement, and
requiring proof of binding without saying what makes the binder
entitled imports a threat model by silence. That is the concern behind
Orie's comment that this drifts toward AUDIT scope.

There is a middle position between mandating a trust model and leaving
entitlement undefined, and it converged on this list over the past
week in the "charter simplification" thread (Zagarella, Sirkkavaara,
Ahuja, Sergeev, Wadkins, and myself, with four independent
implementations behind it). The resulting text is already in the
editors' queue at jdrosen/aiproto-wg issue #49. The shape: the charter
does not select what grounds entitlement; it requires each
architecture to disclose what fills that role, against a small set of
stated properties, including defined behavior when the grounding
cannot be resolved at evaluation time. Concretely, one sentence added
to the binding-envelope deliverable in either rewrite:

"Specifications must state what establishes a binder's entitlement,
how a relying party verifies it at the time of binding, and the
defined behavior when that entitlement cannot be resolved."

This resolves the correlation-versus-binding question without
expanding scope: no root type is chosen, no authorization semantics
are imported from OAuth or WIMSE, and the AUDIT boundary stays clean
because the charter requires disclosure of the binding basis, not
evidence formats for it. It also gives the gap analysis item Brian
added on durable ownership (Naveed's question) something checkable to
analyze against. The reason I trust this shape is operational: we run
a fail-closed authorization control plane, and the defects we have
found and disclosed in our own system were each a claim carried
implicitly rather than stated, with the unresolvable case the one that
fails silently, in a different direction per implementation.

1. Substrate or semantics only? Enough substrate to make the semantics
checkable, and no more. The test: a relying party must be able to
verify a claimed binding from the artifacts alone, without trusting
either endpoint. Semantics that cannot be verified from artifacts are
vocabulary, and vocabulary does not survive a dishonest participant.
That does not require the charter to pin a wire format; it requires
the deliverable to carry verifiable bindings rather than only
descriptions of them.

2. Session lifecycle: out of scope is right, per PR 77. One caution:
defined behavior when a reference or its binding basis cannot be
resolved is not lifecycle, it is binding semantics, and if the charter
is silent on it each implementation decides by accident, which in our
experience defaults to fail-open.

4. Bilateral is sufficient if reference relationships survive:
Jonathan's correlated point-to-point dialogs and Brian's parent-child
references are the same requirement stated twice, and it is the one to
keep, since task decomposition is where bindings actually get
exercised.

5. Terminology and architecture first, thin, Informational; then the
reference and binding deliverable; carrier bindings after. Fewer
deliverables with the binding question answered beats more
deliverables with it deferred.

6. Define the interface properties a term must satisfy rather than the
term itself. The past week's thread converged fastest exactly when it
stopped debating what a root is and started stating what one must do.

IPR disclosure covering the material behind this:
https://datatracker.ietf.org/ipr/7500

Bradley B
11 AI Blockchain Developments LLC