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

[Bradley B <[e-mail]>]

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