Should delegated authority depend on execution lineage? (PIC, #168) #222

What cA2A checks today

verify_chain checks root trust, signatures, validity windows, issuer/subject continuity, parent_id links, per-hop scope narrowing and credential_id uniqueness within one chain. A DelegationCredential has no task or execution field. So the delegate can present the same valid chain with a request from a different task, and verify_chain accepts it. The holder proof (#97) stops a different party from presenting the chain. It signs the request, including a parent_record_hash that the delegate chooses; nothing in the credential limits that choice, so the rightful delegate can still attach its authority to any lineage.

#198 made lineage authenticated: verify-lineage checks signed TRACE records and their parent links against the chain. Its merge note already says that is not "continuity of a particular live request". #168 stays open for that reason.

The question

Should the authorization decision depend on execution lineage, and if so, should cA2A carry an external model's state rather than define its own?

@ngallo raised this in #150 and proposes PIC (Provenance Identity Continuity): authority is valid only as a continuation of a specific predecessor execution, with lineage as part of the authorization state rather than an audit field. Preprint: https://arxiv.org/abs/2607.08906. Model and drafts: https://github.com/ngallo/pic-model. His view is that cA2A should consume PIC state, not rebuild those semantics.

Prior work on lineage-sensitive authorization to weigh alongside it:

• Abadi and Fournet, Access Control Based on Execution History, NDSS 2003.
• Park, Nguyen and Sandhu, A Provenance-Based Access Control Model, PST 2012.

Options

1. Bind each credential to a task or execution identifier that the inbound path checks. Small change, but it does not compose across hops by itself.
2. Carry PIC state in the A2A message and verify it alongside the chain. Depends on PIC having a stable wire format and verifier.
3. Leave authorization lineage-insensitive and document it as out of scope, as cA2A report version 2 now does in Section 3.

No decision yet. Today's behaviour, run against main at 19407fb (0.4.0): one root credential A to B for invoice.pay, then two holder proofs from B for unrelated tasks with different record_id and parent_record_hash values. verify_chain and verify_holder_proof accept both. A first step for any option is turning that into a test that currently passes and should fail once lineage is enforced.

Refs #150, #168, #198.