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

[[e-mail]]

Hi Songbo, James, all,

I am the author of draft-prakash-aip. Thank you both for the review. I agree
with most of it, I have corrections to my own draft to add to it, and the
exercise turned up two authorization bypasses in my reference implementation
that I have since fixed. Details below, in the order the questions were asked.

On Songbo's three questions.

The identity split: agreed, and the current mapping is inconsistent rather than
merely imprecise. C-001 in Principal Binding-06 is "live agent instance is
acting", with carriers listed as channel authentication, attestation or a
condition-bound protected key, and an accepted result limited to live-instance
or key-possession status. AIP cannot satisfy that claim at all. What a verified
chain establishes is the set of participants the artifact names, which belongs
under C-003 and C-012. Note that the matrix as frozen maps C-001 twice with
opposite dispositions, EXACT on the identity row and DECLARED-GAP on the
presenter row. Splitting the row is the right fix.

The freshness split: agreed. Credential and revocation freshness has a defined
carrier, a defined verifier and a fail-closed path. Completion-evidence
freshness has none of those in AIP-01. One disposition should not cover both.

expected_row_outcome: agreed, and it is the more accurate name. The harness
does not compute a row outcome; each case has a bespoke function that states an
outcome and then asserts it matches the frozen expectation. That is a useful
record of intended dispositions and it should be labelled as one. Corrections 3
and 4 are James's to make rather than mine.

On James's four questions.

1. The mapping reflects my intended claim boundaries for seven of the eight
rows. Action binding is the exception, and not because I intended it to be
unrepresented. It is an unstated gap, and worse, the name overstates it. The
draft calls the construct an Invocation-Bound Capability Token in the abstract
and the introduction, and nothing in the document binds an invocation. Simple
profile scope is tool-name granularity, the A2A binding carries no task or
context identifier, and the MCP binding has no argument digest. An authority
for interop.echo("hello") is indistinguishable from interop.echo("goodbye").
The UNREPRESENTED result is correct and the name should not have survived it.

2. Completion-evidence appraisal and freshness should be inherited, not defined
by AIP, but AIP has to say so and point somewhere. RFC 9334 already has the
vocabulary: attester, verifier, relying party, appraisal policy for evidence,
and freshness by nonce or epoch. Section 8.2's three trust levels are an
informal restatement of a RATS-shaped problem without RATS' terms. -02 will
cite RFC 9334 and state plainly that AIP does not define appraisal, and that
verification_status is a self-asserted label unless an external appraisal
mechanism is composed with it.

3. Control-domain separation is not defined today, and the honest answer is
that Level 2 is explicitly not independent. The delegator is a chain
participant by construction, so "delegator independently verifies the result"
is doing rhetorical work the mechanism does not support. Level 3 needs either a
defined separation predicate or a statement that AIP does not establish
independence. I intend the latter unless someone has a workable predicate.

4. Exact action and payload binding belongs in a separate mechanism, but AIP
should define an optional action digest fact so a deployment can bind it and so
the name becomes true rather than aspirational. That is the -02 change I care
most about.

What the vectors prompted.

The four cases are all outside the threat model Section 9.1 claims, so the
100 percent rejection rate reported in Section 9.2 was never asserted to cover
them. Rather than leave it there I ran a full audit of my own reference
implementations. It found two authorization bypasses, both mine, both now
fixed and released.

The first is in the verifier. ChainedToken.authorize() interpolated the
requested tool name into the Biscuit authorizer source. A tool name that closed
its own string could append an in-allowlist tool() fact and an allow policy, so
a token granting only tool:search authorized anything. This required no
malicious token, no forged signature and no control of the issuer, only
influence over the tool name being checked, which in an MCP binding arrives
directly from the agent's JSON-RPC params.name.

The second is in the encoders. The issuer, principal, scope, delegator,
delegate and context values were interpolated into block Datalog, so a breakout
in any of them injected facts into a block that was then signed. An injected
tool() fact satisfies the authority block's own scope check for any requested
tool, an injected time() fact defeats expiry, and an injected max_depth() ahead
of the real one is what the depth check reads. The resulting token is
cryptographically valid and every signature chains.

Separately, the MCP proxy shipped in the same package ran step V1 only. V2
through V7 never executed, so out-of-scope, expired, over-budget and
over-depth chains were forwarded upstream as verified.

Fixed in agent-identity-protocol 0.4.0 and 0.5.0 on PyPI, with regression
vectors for both bypasses and cross-language conformance vectors for the
canonical encoding.

The generalizable part is worth the group's attention, because it is not
specific to AIP or to Biscuit. Specifying a Datalog-based capability format
without specifying escaping or parameterisation makes every conforming
implementation bypassable, and the failure is silent. This is the second
finding of that shape I have hit in this format, after the one I reported to
WIMSE on 19 August about scope encoded as shared named rules failing to
attenuate. If AGENTPROTO or WIMSE ends up evaluating policy-carrying token
formats, term escaping deserves to be a review item rather than left to
implementers.

Two corrections to my own draft, before anyone else finds them.

Appendix A of -01 states "R7, Authentic, bounded-staleness revocation: MET."
That overstates it. Section 4.7 specifies V7, but there is no revocation
implementation in either reference SDK, and no staleness configuration. -02
will either implement V7 or scope the claim to the specification rather than
the implementations. I would rather name that than have it read as a
requirements-mapping claim my own code contradicts.

Section 4.8 says verification establishes "the identity of each delegator and
delegate in the chain", and Section 3.2 describes delegation blocks as signed
by the delegator. In both implementations, delegation blocks are appended using
Biscuit's internal ephemeral keys, so the delegator and delegate facts are
unauthenticated self-assertions. V1 establishes append order and
non-substitution, which is a different property. The text overstates and -02
will correct it.

For the -07 registry entry, if it is useful, this is the characterization I
would stand behind:

  AIP (draft-prakash-aip) conveys agent authority as an attenuating
  delegation chain, verified offline against an issuer-resolved root key. A
  verified chain establishes the participants it names, that no hop exceeded
  the authority its predecessor held, and that the requested tool, evaluation
  time and delegation depth fall within every block's constraints. It does
  not authenticate the presenter: the token is a bearer credential and
  Section 5.3 says so. It does not carry the principal's entitlements, does
  not bind an exact action or payload, and does not define an appraisal
  procedure or freshness bound for the evidence behind a completion's
  verification_status.

One factual note on the audit attachment. The Border receipt tests row in the
source verification table gives the digest as
db5b04561f2c3df8781c4717ba65831b29cfa455d17bfc1ff836ea0ed85b3cf, which is 63
hex characters and so not a valid SHA-256. The value in sources.json is
db5b04561f2c3fdf8781c4717ba65831b29cfa455d17bfc1ff836ea0ed85b3cf. Flagging it
because the table is reported as verified and may be carried into -07.

Corrections to any of the above are welcome. Specification and both reference
implementations, with the cross-language conformance suite, are at
https://github.com/sunilp/aip.

Best,
Sunil Prakash



> On 23 Aug 2026, at 5:43 PM, Songbo Bu <[e-mail]> wrote:
> 
> James, Sunil, all,
> 
> Thank you for publishing AIP-MATRIX-FIT-001 with frozen inputs and
> machine-readable results. I checked out commit
> 8ed65b70f8933a659dcab00331d86bac40009abe and reproduced the experiment
> locally.
> 
> The commit history confirms that matrix.json, cases.json, and
> sources.json were frozen before the evaluator implementation. All 17
> tests pass, the generated report matches the committed results object,
> and all six declared source objects match their pinned byte lengths
> and SHA-256 values.
> 
> Within those limits, I agree that the four hostile-but-valid cases
> expose useful claim boundaries:
> 
> - a valid AIP artifact does not authenticate the live presenter;
> - signature validity does not establish verifier control-domain independence;
> - a signed completion assertion does not define the appraisal and
> freshness procedure for its supporting evidence; and
> - ambient tool-scope success does not establish exact
> task-and-argument binding across an A2A-to-MCP transition.
> 
> I found five corrections that would make the matrix fit more precise:
> 
> 1. Split artifact-named delegation participants from live presenter
> identity. The current identity row should not be EXACT against C-001,
> because AIP-01 explicitly does not establish that the presenter is the
> delegated leaf. The named chain participants fit C-003/C-012, while
> C-001 remains a separate live-instance gap.
> 
> 2. Split credential and revocation freshness from completion-evidence
> freshness. They have different carriers, verifiers, and failure
> behavior.
> 
> 3. Rename row_outcome to expected_row_outcome unless the harness emits
> a complete Principal-Binding row-result record with mapping, claim,
> verifier, binding, freshness, and evaluation context.
> 
> 4. Add a default command that verifies locally supplied source bytes
> before evaluation and records whether source verification passed,
> failed, or was skipped.
> 
> 5. State who supplies and authenticates the ambient tool, time, and
> depth facts. A successful policy evaluation is relative to those
> inputs and does not independently establish the physical tool or
> resource instance.
> 
> The attached audit records the reproduction details, source hashes,
> supported findings, corrections, and evidence limits.
> 
> Attachment: aip-01-verifier-matrix-audit-20260823.md
> SHA-256:
> b078907b983494f8366e76dba672003bf0bdbcba14a52830452f20d94b24d5e4
> 
> I have also reflected the general registry, aggregate-result, and AIP
> mapping lessons in the local -07 working text of the Principal-Binding
> draft. That working text is not yet published, and the local rerun
> does not establish AIP implementation conformance, independent
> verifier diversity, network interoperability, deployment security, or
> working-group agreement.
> 
> Would you review whether you agree with the identity and freshness
> splits, and whether expected_row_outcome is the intended meaning of
> the current harness field?
> 
> Best,
> Songbo
> <aip-01-verifier-matrix-audit-20260823.md>