rfc: propose delegation-link verification, with the vectors that argue it - #3
rfc: propose delegation-link verification, with the vectors that argue it#3lywinged wants to merge 9 commits into
Conversation
|
❔ Contributor Check: UNKNOWN
Automated check by AgenTrust Contributor Check. |
…e it The `delegation` block is normative in v0.2 and nothing says what a verifier does with a chain of them. `spec/trace-v0.2.md` never mentions `parent_record_hash` or `credential_id`; the only prose is one sentence in `docs/schema.md`, and every operative term in it is open — which bytes the digest covers, what "the delegation chain" is when no credential object exists in the schema, what a verifier does with a link it cannot compute. Two implementations can satisfy every constraint the repository states today and agree on nothing. `docs/rfcs/a2a-delegation-profile.md` proposes ten rules over the fields that already exist, so adopting it requires no schema change. `examples/delegation-link/` carries 23 vectors that score an implementation against them. Requirement keywords in the RFC are lowercase on purpose: a proposal that writes itself in the imperative is a specification nobody agreed to. Three forks in the current text had to be settled before a single vector could be written, and each is recorded with its reason rather than assumed: The digest covers the complete parent record, signature included. A digest over the signed body alone does not bind the parent's *signer* — anyone may re-sign identical bytes under another key and satisfy the child's commitment — so the child would have committed to what its parent said and not to who said it. Vector 05 is a complete, correctly signed chain whose only defect is which bytes its link was computed over. There is no cycle rule. A cycle needs each record's block to carry a digest covering the block that names it back, which is a hash collision; a rule against it would be untestable by construction. The reachable analogue is an unbounded chain, and that is the only reason the depth bound exists. Stated so a reader can tell which of the two was decided and which was forgotten. A link naming a digest algorithm the verifier cannot compute makes the chain unverifiable, not invalid. Reporting `parent_not_found` for it would be a finding nobody made: the verifier did not fail to find the parent, it did not look. This is the delegation-surface instance of the semantics merged in `docs/verification.md`, and `parent_not_found` is explicitly guarded on algorithm support so the two cannot be produced together for one link. Coverage is held to agentrust-io#124's discipline from the first vector rather than as a later hardening pass: two load-bearing vectors per rule, and for every rule at least one declared implementation defect that one vector catches and the other misses. All ten defects model a real shortcut — verifying the leaf only, anchoring on any trusted key found, an off-by-one bound, case-insensitive lookup of an opaque identifier, issuer and holder compared to the wrong ends of the hop, half a validity window, narrowing checked at one hop, the link algorithm read once and assumed uniform. Two of those declarations found faults in the walk while it was being written, which is the argument for declaring them rather than asserting margin and stopping. The walk's break condition originally repeated the depth comparison, so a weakened bound never got to walk further than a correct one and both depth vectors moved together under every mutation — margin without independence. And an earlier vector 09 put an untrusted root three hops down, which no defect could separate from vector 08; the version that separates them places a *trusted* key partway up the chain, which is the shortcut an implementation actually takes. Reproducibility is a property of the corpus, not a courtesy. Keys derive from one published seed by role label. `tests/test_generators_reproduce_fixtures.py` (agentrust-io#171) discovered the generator with no new guard code and holds it to byte reproduction with no entry in the `NOT_GENERATED` ledger, which is the bar agentrust-io#178 proposes for the repository's corpora. Every record in every vector, including the ones built to fail, validates against `schema/trace-claim.json`: a defect the schema already rejects is not a profile defect, and a rule that looks covered only because its vector is malformed in some louder way is not covered. Nothing enters the package's public API. The walk lives in `tests/`, beside the action-receipt verifier it is modelled on, because the rules it implements are not normative yet. Signed-off-by: Louielunz <48041247+lywinged@users.noreply.github.com>
The proposal argued for cross-verification and did not do any, which left its central section a plan. This runs the 23 vectors against `ca2a_verify.verify_trace_dag` at ca2a 5dd77b2 and writes down what came back, including the parts that went against the draft. The §4.1 digest decision is confirmed from outside this repository. `ca2a_runtime.trace_binding.trace_record_hash` computes the sha256 of the complete signed record's RFC 8785 bytes — byte-identical to what the profile specifies, arrived at separately. Vectors 01-07 agree in verdict and in reason. Vectors 22 and 23 disagree exactly as §4.3 predicted: cA2A accepts a `sha384:` link at block validation, compares it against a hash it only ever computes as `sha256:`, and reports the chain as "a tampered or reparented record". An intact chain addressed under the other permitted algorithm is reported as tampering. The distinction between unreadable and contradicted is now observed rather than argued. Two things the draft got wrong, corrected here rather than left standing: It said cA2A "states that its credentials are cross-verifiable with agent-manifest" and that nothing tests the claim. The claim in `ca2a_runtime/canonical.py` is narrower — that RFC 8785 makes the signed byte string identical across conforming implementations, so signatures verify either side. Read as credential interoperability it is a claim ca2a does not make. Checked on the axis it does make: ca2a hand-implements JCS rather than taking a library, and that implementation is byte-identical to the reference on all four vectors of `examples/canonicalization-boundary/`, both UTF-16 key-order cases included. Upheld. A first pass recorded that cA2A has no depth bound. It has one — `max_depth`, default 8, on the credential chain rather than on the record DAG. A bound in a different place is not an absent bound. The credential surfaces turn out not to be comparable at all, which is the finding rather than an obstacle to it: three repositories, three delegation models, no conversion between them. §7.1 tabulates them. Two consequences worth carrying forward — agent-manifest already narrows on `data_classifications`, which is independent support for D-9 belonging on this surface, and cA2A credentials carry no validity window at all, so D-8 has no counterpart there. The trust contract also differs and cannot be normalised away: `verify_trace_dag` requires every record's key to be trusted, this profile anchors on the root's. Under this profile's contract cA2A rejects every valid chain longer than one record. Neither is wrong; they fit different deployments, and cA2A itself uses the root-anchored model on its other surface. No code changes. The vectors are untouched and both suites still pass. Signed-off-by: Louielunz <48041247+lywinged@users.noreply.github.com>
…'s outcomes
The cross-check so far only pushed this corpus outward, which shows that cA2A
rejects what the profile rejects and nothing about whether the profile describes
what the ecosystem emits. This runs it the other way and reads the third
implementation's declared outcomes.
`ca2a/examples/trace-dag/demo.py` emits a signed three-hop TRACE DAG through
cA2A's own `trace_binding`. Against it: three schema-valid records, both links
matching the section 4.1 preimage exactly, all three signatures valid under D-1,
and the chain returns `verified` with no codes and no adjustment to the walk. A
chain produced by an independent implementation verifies here unchanged.
agent-manifest turns out to settle section 4.3 rather than leave it open. Its
corpus declares results as data in the vector files -- VALID, MISMATCH,
UNVERIFIABLE, EXPIRED, REVOKED, SIGNATURE_MISSING, INCOMPLETE,
INCOMPATIBLE_VERSION, ATTESTATION_UNAVAILABLE -- and AM-VEC-012 declares
`{"result": "UNVERIFIABLE", "fields_verified": {"delegation_chain":
"UNVERIFIABLE"}}` for a delegation chain with no public keys. Evidence the
verifier lacks what it needs to check, recorded as unreadable rather than as a
finding against the chain: section 4.3, on this surface, in a second
implementation, arrived at independently. Two of the three distinguish
unreadable from contradicted; cA2A's TRACE DAG verifier collapses them, which
makes the sha384 divergence a gap rather than a preference.
Its `fields_verified` shape is prior art this proposal does not have. A verdict
per field says more than a verdict per chain, and section 8 should probably ask
about it.
Two smaller things recorded where they were found. `examples/trace-dag/` commits
a README and a demo but no vectors -- the DAG is produced at runtime and not
kept, which is the gap this corpus fills from the trace-spec side. And cA2A uses
the field name `parent_record_hash` in two formats: the schema's prefixed digest
in a TRACE record, and a bare hex digest in its own provenance DAG, on records
carrying no TRACE fields. Both deliberate, neither wrong, and a hazard for
anyone writing a parser against the name.
No code changes; the vectors are untouched and both suites pass.
Signed-off-by: Louielunz <48041247+lywinged@users.noreply.github.com>
Both are gaps in this document rather than in anything it argues, and both were found by reading `ROADMAP.md:21` against §6 rather than by anyone raising them. **The mutual case.** That line scopes the v0.3 A2A profile as "binding rules over the `delegation` block ... including the mutual case". §6 lists six things this proposal does not do and omitted the one the roadmap names. Nothing here covers mutual delegation: every rule walks one chain in one direction, and the block as it stands names one parent and no peer. Calling two agents each holding the other's authority "two chains" would be deciding that question rather than raising it, so §6 now says so plainly. It is the largest distance between the roadmap's line and this document. **Who this is for.** The same line names cA2A as the reference implementation and says nothing about who writes the binding rules, and this was written without asking. §8 opens with that question ahead of the design ones, because the answer changes what the document should become: the profile itself would need the mutual case, a credential model and a ratification path; an input stays a set of rules with executable material behind them, liftable or discardable a rule at a time. Neither is a change to a rule, a vector or a suite. 585 passed.
…written The document presented the three decisions in §4 as decisions and never said how they were arrived at. They were not read out of `docs/schema.md`; they were hit, because no vector could be written without settling them, and in each case the text supports both branches. A reader passes over all three without noticing. Someone building a fixture cannot get to the end of one. That order -- corpus first, and let it interrogate the text -- is the part worth keeping if every rule here is replaced, because it yields a measurement this repository does not otherwise have. Not whether tests cover the rules, which measures an implementation, but whether two independent readings of the same normative text produce the same rules, which measures the specification. Agreement means the text is doing its job; divergence names the sentence that is missing. §7.1 was already that measurement run once and was not labelled as one. Two implementations written without reference to this document agree with §4.1 and with each other on the digest preimage, and split on the unresolvable-algorithm question -- one calling it unreadable, one calling it tampering. The first result is the text working. The second is a located gap that took no argument to find, because the same question was put to two implementations rather than debated. It also settles what a second profile design would be for. One reading measures nothing, so an independently written set of binding rules is the experiment, not a collision with this one. No rule, vector or suite changed. 585 passed.
The previous entry read that line as mutual delegation and reported this document as short of it. That was a guess at the referent, made without checking, and it is wrong. In the reference implementation the mutual case is mutual attestation. ca2a/docs/spec/mutual-attestation.md describes a callee-issued challenge and a caller offer bound to it, so each side establishes what the other is running before a payload opens. It separates the two concerns explicitly -- it "establishes what each side is running", while "the delegation chain remains the thing that says what it is allowed to ask for" -- and it does not mention a Trust Record anywhere. Nor does cA2A's own docs/spec/trace-a2a-profile.md, whose A2A profile is the delegation-link block and nothing else. Which changes what the entry says. The roadmap asks the A2A profile to cover something with no record representation today in either repository, sitting at the transport layer rather than on this surface. That is a scoping question -- either mutual attestation gains a binding into the record, which is a schema question rather than a verification one, or the v0.3 profile is two profiles -- and not a coverage failure in these rules. A reader comparing this document against that roadmap line would otherwise conclude the second. The bidirectional-delegation reading is kept as a separate note rather than dropped, because it is true and unreachable for the reason section 4.2 gives, and because the two readings should not merge later. Every claim above traced to its file before writing: grep for "trace" in mutual-attestation.md returns 0, grep for "mutual" in trace-a2a-profile.md returns 0, and both quotations were checked against the source with whitespace normalised, since the file wraps mid-sentence and a single-line grep misses them. No rule, vector or suite changed. 585 passed, ruff clean.
48b9cb6 to
bfdeb9a
Compare
Brings the branch up to f51e1f7, twenty-one commits on from the base it was opened against. The only conflict is CHANGELOG.md, where both sides added an entry at the top of Unreleased/Added: key revocation from agentrust-io#187 and this branch's delegation profile. Both are kept, the merged change first and the proposal under it, since one describes what landed and the other what is proposed. Nothing in the RFC needed changing. Its section references are its own, and the one external citation, spec/trace-v0.2.md section 3.1, still resolves. The "No revocation" limitation still stands as written: agentrust-io#187 anchors revocation of a record-signing key, and what this profile leaves open is revocation of a delegation credential, which is a different object. Signed-off-by: Louielunz <48041247+lywinged@users.noreply.github.com>
… merged agentrust-io#186 added criteria that every vector set on disk is measured against, and test_every_vector_set_on_disk_is_measured_somewhere fails for a set in neither SETS nor MEASURED_ELSEWHERE. This branch was opened three days before those criteria landed, so merging upstream leaves `delegation-link` as the one set nothing grades, and it is the only failure in the merged tree. Registered in SETS rather than named in MEASURED_ELSEWHERE, because the set holds up when it is actually graded rather than only pointed at: delegation-link: 23 vectors, 3 accepting, 10 distinct failure codes No shortfall on either criterion decidable from the fixtures. It is not satisfiable by an implementation that answers "accept" to everything or one that answers "reject" to everything, and every one of the ten failure codes is carried by exactly two vectors, which is the margin agentrust-io#124 asks for. Boundaries are counted by failure code, the default. adequacy.py says that assumption is the set's to justify: here the codes are the unit, because tests/delegation_margins.json records the per-code margin and tests/test_delegation_completeness.py holds each rule to being load-bearing for both of its vectors, deleting the rule from the registry rather than matching source text. The criteria adequacy.py leaves to each set, a rule nothing pins and a weakness shared across a boundary's vectors, are implemented there too, by rebuilding the registry without an entry and by substituting shortcut checks that read only the first link or the first hop. 605 passed, 1 skipped. Verified by removing the SETS entry again, which fails test_every_vector_set_on_disk_is_measured_somewhere on its own. Signed-off-by: Louielunz <48041247+lywinged@users.noreply.github.com>
Section 7.1 recorded the cA2A disagreement in the present tense: its block validator accepts a sha384: link, compares it against a hash it only computes as sha256:, and reports ProvenanceLinkBroken with "a tampered or reparented record was detected". That was true when the corpus was run and is not true now, so the document was carrying a defect report against another repository that the other repository has already fixed. Checked at ca2a 52141e8 rather than taken from the report: src/ca2a_verify/dag.py:194 raises TraceDigestUnsupported with the detail "the chain is unverifiable here, not invalid" at line 199, and the parent-link comparison that produced ProvenanceLinkBroken is at line 201, after it. So the guard precedes the comparison and vectors 22 and 23 now describe fixed behaviour. Both places are re-tensed rather than deleted. What the case establishes is not that one verifier had a bug: a corpus written to argue a rule found the case, the other implementation changed, and the shape it changed to is the distinction section 4.3 asks for. Deleting it would drop the strongest evidence in the document that the corpus does what it claims. The second passage said two of three implementations distinguish unreadable from contradicted; it is now all three. Section 4.3's rule text is untouched, since it states the rule rather than reporting on an implementation. 605 passed, 1 skipped. Signed-off-by: Louielunz <48041247+lywinged@users.noreply.github.com>
|
Closing: this landed upstream as agentrust-io#184 on 23 August, and leaving the branch open here makes it look like the work is still pending when it is merged. Checked rather than assumed. Of the 31 paths this branch touches, 30 are byte-identical on The single remaining file is Generated by Claude Code |
Rehearsal PR on the fork. Not for upstream yet — this is where the shape gets reviewed before it is proposed to anyone.
What this is
The
delegationblock is normative in v0.2 and nothing says what a verifier does with a chain of them.spec/trace-v0.2.mdnever mentionsparent_record_hashorcredential_id. The only prose is one sentence indocs/schema.md:Every operative term in it is open — which bytes the digest covers, what "the delegation chain" is when no credential object exists in the schema, what happens to a link the verifier cannot compute. Two implementations can satisfy every constraint this repository states today and agree on nothing.
docs/rfcs/a2a-delegation-profile.md— ten rules over fields that already exist. No schema change.examples/delegation-link/— 23 vectors, generator, published seed.tests/test_delegation_vectors.py— the reference walk and the correctness run.tests/test_delegation_completeness.py— margin, independence, and the ratchet.Requirement keywords in the RFC are lowercase on purpose. It binds nothing until adopted, and a proposal that writes itself in the imperative is a specification nobody agreed to.
Three forks that had to be settled before a vector could exist
Each is in the RFC with its derivation, not asserted.
The digest covers the complete parent record, signature included. A digest over the signed body alone does not bind the parent's signer: anyone may re-sign identical bytes under another key and satisfy the child's commitment, so the child would have committed to what its parent said and not to who said it. Vector 05 is a complete, correctly signed chain whose only defect is which bytes its link was computed over — under one reading it verifies, under the other the link resolves to nothing.
A consequence worth stating, because it changes what an attacker can reach: every ancestor's bytes are committed to by its child, so no record on a chain can be altered in place except the leaf. An ancestor with an invalid signature has to be built that way before its child signs. That is why every defect here is a build-time parameter of the generator and none is a post-hoc mutation.
There is no cycle rule. A cycle needs each record's block to carry a digest covering the block that names it back, which is a hash collision — a rule against it would be untestable by construction. The reachable analogue is an unbounded chain, and that is the only reason the depth bound exists. Said out loud so a reader can tell which of the two was decided and which was forgotten.
A link naming an algorithm the verifier cannot compute makes the chain unverifiable, not invalid. Reporting
parent_not_foundfor it would be a finding nobody made: the verifier did not fail to find the parent, it did not look. This is the delegation-surface instance of the semantics merged indocs/verification.md, andparent_not_foundis explicitly guarded on algorithm support so the two cannot be produced for one link.Coverage
Ten rules, two load-bearing vectors each, and for every rule at least one declared implementation defect that one vector catches and the other misses — agentrust-io#124's criterion, applied from vector 1 rather than as a later hardening pass. The defects model real shortcuts: verifying the leaf only, anchoring on any trusted key found, an off-by-one bound, case-insensitive lookup of an opaque identifier, issuer and holder compared to the wrong ends of the hop, half a validity window, narrowing checked at one hop, the link algorithm read once and assumed uniform.
Two of those declarations found faults in the walk while it was being written, which is the argument for declaring them rather than asserting margin and stopping:
digest_algorithm_unsupportedfrom the registry made the walk step off the end of the index and raise, because control flow was reading the registry's contents. A registry whose entries exist to be mutated cannot carry cross-rule invariants that crash. Whether the walk can continue is now asked as a structural question; the registry only says why not.Neither is visible from a green test run. Both came out of mutation.
Reproducibility
Keys derive from one published seed by role label — no secret, reissuable by anyone.
tests/test_generators_reproduce_fixtures.py(agentrust-io#171) discovered the generator with no new guard code and holds it to byte reproduction with no entry in theNOT_GENERATEDledger. That is the bar agentrust-io#178 proposes for this repository's corpora, adopted here from the first vector rather than retrofitted.Every record in every vector — including the ones built to fail — validates against
schema/trace-claim.json. A defect the schema already rejects is not a profile defect, and a rule that looks covered only because its vector is malformed in some louder way is not covered.Scope
Nothing enters the package's public API. The walk lives in
tests/, beside the action-receipt verifier it is modelled on, because the rules it implements are not normative yet. Vector ids areTRACE-DELEG-NNNand deliberately notACTION-*— that namespace belongs to ca2a's conformance set, whose own rule is that its identifiers are never reused.Not covered, and named in the RFC rather than left to be noticed: credential format, revocation, authorization withdrawn before execution and authority-epoch staleness (the two gaps agentrust-io#66 has already named), and cross-verifier agreement.
That last one is the load-bearing omission. One implementation passing its own corpus is self-agreement. What would make this a profile rather than a local convention is these same vectors run through
ca2a_verifyandagent_manifest.verify_delegation_chain— both public, both shipping, andca2a/src/ca2a_runtime/delegation/credential.pyalready claims the two are cross-verifiable while nothing in any of the three repositories tests that claim.Checks
tests/test_sign.py::test_verify_record_future_skew_is_deployment_configurableflaked once during this work and is unrelated: it setsiat = int(time.time()) + 601and asserts a raise atmax_future_skew_seconds=600, so crossing a single second boundary between the two calls makes the skew exactly 600 and the raise does not happen. A one-second margin, pre-existing, reproducible on a clean tree by timing alone. Filed separately rather than touched here.Review focus
data_classnarrowing (D-9). It is the only scope-like comparison the current fields support, and it may belong with a general scope model rather than with delegation.tests/is the right home for a reference walk that a third party might want to run.Generated by Claude Code