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

verify_chain: judge revocation by snapshot membership while windows are judged at at_time

Open
  • Is something wrong?
#263 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
authentication, security

Research direction

Start by reading the implementation and tests for verify_chain and effective_revocation, then trace how _check_revocation handles authority and snapshot membership. Decide which proposed public API fits the existing interface while preserving the current default, and add coverage for a snapshot statement whose issued_at is later than at_time. Done means the public API supports the log-order reading, documents that the caller supplies the exact snapshot, and the existing behavior remains covered.

Written by the indexing model from the issue text.

Description

enhancement needs-review:HIGH

Problem statement

An auditor that replays a past decision from a transparency log needs two different clocks. Validity windows are judged at the decision time (at_time). Revocation is judged by log order: the snapshot holds exactly the statements the log published before the receipt, so every statement in it should count, whatever its issued_at says.

Today verify_chain(at_time=T, revocations=S) passes at_time=T on to effective_revocation, which skips statements with issued_at > T. A statement logged before the receipt, but stamped later by the revoker's clock, is ignored. The only way to get the log-order reading is to run verify_chain(..., revocations=None) and then the private _check_revocation(chain, S, at_time=None, now=T, max_staleness=None). That is what the MUSUBI companion does now (horizon-shield workers/hs-ledger/nenrin/musubi-v0/ca2a-companion-v0/companion_v0.py, _ca2a, pinned to ca2a-runtime 0.4.0). A private call will break on refactors that never touch its reading.

Proposed solution

Either of these, with today's default unchanged:

  1. A keyword on verify_chain, for example revocation_at_time, defaulting to at_time, where None means every statement in the supplied snapshot is in force.
  2. A public check_revocation(chain, revocations, *, at_time=None, now, max_staleness=None) with the semantics _check_revocation has now, documented as valid only on a chain whose structure has already verified.

Alternatives considered

  • Re-implementing the authority walk in the companion. Rejected: it would drift from cA2A's own rule that a delegate cannot revoke the grant it received.
  • Rewriting issued_at in the snapshot. Rejected: it changes signed statements.

Security/TEE impact

None on the TEE boundary or attestation flow. The new reading only counts more revocations, never fewer. When it is used, the caller asserts that the snapshot is exactly the set in force, and the docstring should say the caller owns that.

Spec alignment

No trace-spec change required.

Context: agentrust-io/.github discussion #65. Once this ships, the integrations entry switches to it and drops the 0.4.0 pin.

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.