Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#222 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
authorization, security

Research direction

Start by reading verify_chain and verify_holder_proof, then reproduce the described case: one credential and two holder proofs for unrelated tasks. Turn that behavior into a test, as the issue suggests. The issue leaves the authorization model undecided, so completion depends on choosing an option and establishing the corresponding expected test behavior.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Python
Stars
9
Forks
14
Avg merge
17h 24m
Merged PRs (30d)
56

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from agentrust-io/ca2a

All issues in agentrust-io/ca2a

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.