An evidence companion for four gaps cA2A documents: revocation publication, cross-request single use, portable receipts, a commitment step

[ogasurfproject-jpg]

Hello, I maintain MUSUBI and NENRIN in ogasurfproject-jpg/horizon-shield (HORIZON SHIELD is already listed in your TRACE registry). I read cA2A at 305fedc and built a companion profile for four things your own documents say cA2A does not do:

1. "cA2A defines no protocol for publishing or fetching revocation statements" and a supplier "can withhold a statement" (docs/spec/delegation-chain.md, LIMITATIONS.md).
2. "no global used-credential database, so those checks do not establish single-use credentials across requests" (docs/spec/failure-modes.md).
3. The response MAC "does not sign the execution lineage or create third-party-verifiable receipts" (docs/spec/response-authentication.md), the portable option left open in Define and implement authenticated responses bound to an attested request ca2a#188.
4. Simultaneous attestation "needs a commitment step neither peer can back out of" (ROADMAP.md).

The profile does not change any cA2A object. DelegationCredential and RevocationStatement go in as they are, and every chain is judged by ca2a_runtime.delegation.verify_chain, never by a reimplementation. What it adds:

• An append-only log, each entry signed by its operator, checkpoints anchored in Bitcoin. A revoker keeps the signed entry it was given; if a later checkpoint drops or changes it, the two operator signatures are a portable proof (check_promise, compare_checkpoints). The RevocationSnapshot handed to verify_chain is built from the log, with a signed and anchored as_of. A checkpoint covers everything logged by its as_of, so leaving a promised entry out is provable too.
• Holder-signed credential-use items that carry their cA2A chain and name the responder, and issuer-signed use limits on any hop. A use of a credential counts under any chain that contains it, so delegating onward, re-issuing an ancestor or fanning one request out to several responders does not reset a limit.
• Ed25519 execution receipts naming the lineage (credential digests, root first), the capability (checked against the leaf scope), the request occurrence (JCS hash of caller, responder, lineage, capability, occurrence id, task hash), a Bitcoin block the responder had seen (a lower bound on time the log operator does not set) and the outcome kind and stage. Results are deduplicated per responder and request.
• Commit and reveal items in a session whose id binds its participants; it is simultaneous only if every participant committed before any revealed.

Each receipt gets cA2A's verdict twice: with every revocation logged before it in force (log order), and by your audit semantics over all of them (by issued_at). A revocation only the second one sees is reported as published late rather than hidden either way.

Spec, verifier and 57 vectors (two rounds of adversarial review before publishing; each finding is a vector): https://github.com/ogasurfproject-jpg/horizon-shield/tree/main/workers/hs-ledger/nenrin/musubi-v0/ca2a-companion-v0 (in main at 0ba57624). The vectors' credentials and revocations are signed with ca2a-runtime 0.4.0 from PyPI, and python companion_v0.py --selftest passes against both PyPI 0.4.0 and 305fedc. Section 9 of the spec checks the receipt against RESP-001 to RESP-014.

Your issue template sends design questions here before an issue, so this is that step: nothing here is a pull request, and I am not asking you to take code. The receipt covers the portable option left open in agentrust-io/ca2a#188 and names the lineage agentrust-io/ca2a#168 asks about.

What it does not do: it says nothing about where a responder key lives or which workload signed. Binding the receipt key into the attestation report data would be on your side, and I have not touched it. RESP-013 and RESP-014 stay open.

Two questions:

1. Would you take a receipt key binding (for example a hash of the Ed25519 receipt key in the attested report data) as a direction for #188, or do you want the portable option to stay outside cA2A?
2. Is there a place in your conformance suite where an external evidence profile like this could be listed, or would you rather it stay a separate document that cites yours?

MIT, like cA2A. Happy to change anything that misreads your spec.

[imran-siddique]

Thanks for building this against cA2A's own stated limits, and for calling verify_chain rather than re-implementing it. The best home is agentrust-io/integrations as a community-tier entry: an integration.yaml naming the released ca2a-runtime it was tested against, the four cases as runnable tests, and a README that says what each one proves and what it does not. CI there will run it against each cA2A release.

[ogasurfproject-jpg]

@imran-siddique Thank you, I will put it there: integrations/horizonshield-ca2a-companion/, with an integration.yaml naming ca2a-runtime 0.4.0, the four cases as runnable tests, and a README that says, for each case, what it proves and what it does not.

One question before I open it, because it decides whether the CI there means what it should. The at-execution verdict calls cA2A's private _check_revocation directly. It is the only way I found to say that every revocation the log published before a receipt is in force, whatever its issued_at. That is why the companion is pinned to 0.4.0. Run against each cA2A release, the entry could go red because a private function changed, not because the companion's reading did. Two ways to keep that honest:

1. the entry stays pinned to 0.4.0 and a second job runs against the latest release, allowed to fail, with the README saying why; or
2. cA2A exposes a public way to evaluate a chain against a given set of revocations taken as in force, and the companion switches to it. I can open an issue on agentrust-io/ca2a describing the call if that is welcome.

Which would you prefer for a community-tier entry? I will link the PR here either way.

[imran-siddique]

@ogasurfproject-jpg option 2. A companion that reaches into _check_revocation will break on refactors that never touch its reading. Please open the issue on agentrust-io/ca2a describing the call: a chain evaluated against a caller-supplied set of revocations taken as in force. Keep the entry pinned to 0.4.0 until that ships, then switch to it and drop the pin.

[ogasurfproject-jpg]

@imran-siddique Opened agentrust-io/ca2a#263 for the call: a chain evaluated against a caller-supplied set of revocations taken as in force, with today's default unchanged. The entry will pin ca2a-runtime 0.4.0 and say why in its README; when #263 ships it switches to the public call and drops the pin. I will link the PR here.

[ogasurfproject-jpg]

@imran-siddique The PR is up: agentrust-io/integrations#354 (integrations/horizonshield-ca2a-companion/, head 2191782). It pins ca2a-runtime 0.4.0 and the README says why. One test fails first if _check_revocation moves or changes its signature, and the entry switches to the call in agentrust-io/ca2a#263 and drops the pin when that ships. The four cases are the 57 vectors as tests, grouped by case with named holding and failing cases, and the workflow runs the pins and the latest ca2a-runtime on Python 3.11 to 3.13.

The contributor check marks my account HIGH. As far as I can read contributor_check.py, two signals do it: 31 repositories created on this account in the last 90 days (14 of them forks), and issues I filed in 16 repositories within about a week at the start of October. Both are accurate. I mention it only so a reviewer does not have to work it out, and I am glad to answer anything the review needs.