[Agentproto] Re: AIP-01 verifier-matrix fit: four negative vectors and machine-readable results

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Yes, I also think this is definitely too detailed for the charter. This might be something to exactly discuss in a potential framework or requirements document if we plan to have one. I would however prefer to focus on the protocol work as soon as possible.


> On 26. Aug 2026, at 22:16, Leslie Daigle (ThinkingCat) <ldaigle=[e-mail]> wrote:
> 
> Hi,
> 
> Thanks — my sense is that it might be too fine grained for the charter, but let’s see if others agree.
> 
> Leslie.
> 
> On 25 Aug 2026, at 18:24, J S He wrote:
> 
> Hi Leslie,
> 
> Thank you. I understand the process point.
> 
> The intended relevance was to two passages in the current charter proposal:
> 
> - the framework deliverable’s treatment of authentication, authorization, confirmation, and evidence requirements; and
> - the gap-analysis deliverable’s examination of existing protocols to derive requirements.
> 
> However, I did not frame the experiment as a proposed charter-text change, and the subsequent implementation detail moved beyond the list’s present charter-focused purpose. I will stop that line of discussion here.
> 
> The narrow charter change the experiment suggests would be to extend the gap-analysis bullet as follows:
> 
> Current:
> 
> “Gap analysis and requirements based on examination of existing de facto standard protocols implemented in open-source projects, from which necessary protocol requirements are derived.”
> 
> Proposed addition:
> 
> “The analysis should distinguish the security claims carried by a protocol from the claims actually established by its specified verifiers, including relevant binding, freshness, and failure behavior.”
> 
> This is intended as a requirements-analysis criterion, not a proposal for a new protocol, token format, or implementation deliverable.
> 
> If that level of detail is not appropriate for the charter, I am content to leave the current text unchanged and revisit the material only after the group is chartered.
> 
> Regards,
> James
> 
> On Tue, Aug 25, 2026 at 3:14 PM Leslie Daigle (ThinkingCat) <[e-mail] <mailto:[e-mail]>> wrote:
>> Ahem… with gitHub pointer: https://github.com/ietf-artarea/charters/blob/main/agentproto/charter.md
>> 
>> Leslie.
>> 
>> On 25 Aug 2026, at 18:12, Leslie Daigle (ThinkingCat) wrote:
>> 
>> Hi,
>> 
>> As noted at the end of this week, we’re aiming to focus this list’s discussion to get consensus on a refined charter, based on the BoF at IETF 126.
>> 
>> I’m not following how this thread is specifically responsive to the topics identified in this message:
>> 
>> https://mailarchive.ietf.org/arch/browse/agentproto/?index=_ncC5DvZFdw7mn1fsxabOzmKHvc
>> 
>> This mailing list is for the discussion of creating a charter for an AGENTPROTO IETF working group, and carrying out  the work the group is then chartered to do.   General discussion of (AI) agents is not in scope.  Discussion of specific implementations is not relevant, except where it supports a written statement proposing an update to existing charter text.  The AGENTPROTO charter proposal is available here (git pointer).  If you have issues with any of the text, or suggestions for additional or different content in the charter, please provide your rationale.
>> 
>> Leslie.
>> 
>> On 24 Aug 2026, at 4:18, Songbo Bu wrote:
>> 
>> James, Sunil, all,
>> 
>> I reran the corrected release at tag aip-matrix-fit-002-v0.2.0 and
>> commit 373792ecc415374a8d92893d386dc400287ff71b.
>> 
>> The corrected release now reflects the Principal Binding semantics I
>> was looking for:
>> 
>> all 25 tests pass;
>> all six locally supplied source objects pass their byte-length and
>> SHA-256 checks;
>> 
>> the regenerated results are byte-for-byte identical to the committed
>> artifact, with SHA-256
>> 63a567f248fb28e5247270ce4241708acecc7139dac2a18ecfbcf0d1ce36bd42;
>> 
>> replacing one supplied source with altered bytes makes the
>> required-source run fail and identifies that source as failed;
>> 
>> artifact-named chain participants remain separate from the live presenter;
>> credential freshness remains separate from completion-evidence freshness;
>> expected_row_outcome is clearly an expected harness disposition
>> rather than a complete runtime row result; and
>> 
>> the A2A-to-MCP action swap remains UNREPRESENTED with an unsupported
>> expected outcome.
>> 
>> The registry boundary is also useful: it keeps the mapping release, an
>> external reproduction, and protocol-author review as separate evidence
>> records, and it does not turn an external rerun into a
>> control-domain-independence claim.
>> 
>> I have carried these corrections into my local -07 working copy. I
>> also added general verifier guidance that externally controlled
>> identifiers, tool names, scopes, and related values must be supplied
>> as typed facts rather than interpolated into policy source text.
>> 
>> One evidence boundary remains important. I did not reproduce the
>> reported AIP implementation fixes or the proxy verification-path
>> change, so I am treating those as protocol-author reports with public
>> revision references, not as results of this matrix rerun.
>> 
>> The attached reproduction record includes the immutable coordinates,
>> exact source pins, deterministic result hash, tamper probe, mapping
>> outcomes, and remaining non-completion states.
>> 
>> Thank you both for making the corrections and evidence boundaries explicit.
>> 
>> Regards,
>> 
>> Songbo
>> 
>> Agentproto mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> --
>> 
>> Leslie Daigle
>> Principal, ThinkingCat Enterprises
>> [e-mail] <mailto:[e-mail]>
> --
> 
> Leslie Daigle
> Principal, ThinkingCat Enterprises
> [e-mail] <mailto:[e-mail]>_______________________________________________
> Agentproto mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]