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

[Feat]: Revocation path for open Mandates — rescinding standing agent authority bound to a cnf key

Open
#386 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
python

Research direction

Start by reading specification.md §Autonomous and security_and_privacy_considerations.md, then trace how open Mandates, their cnf claims, and closed-Mandate verification are specified. Define a revocation status mechanism, verifier obligations, bounded exp, and a revoked receipt status; done when the specification and relevant verification behavior cover these requirements.

Written by the indexing model from the issue text.

Description

Is your feature request related to a problem? Please describe.

In the Autonomous (Human Not Present) flow, a user signs open Checkout/Payment Mandates delegating standing authority to a Shopping Agent identified by the cnf claim (specification.md §Autonomous). Two gaps:

  1. specification.md only RECOMMENDS setting exp on open Mandates — nothing requires a bound on standing authority.
  2. No mechanism exists for the user (or a Trusted Surface / Credential Provider on their behalf) to revoke an open Mandate after delegation. The only invalidation language in security_and_privacy_considerations.md lets CPs/Networks/MPPs reject overlapping Mandates or invalidate payment tokens they issued — a double-spend mitigation, not revocation of the Mandate itself.

Consequence: if the Shopping Agent's cnf key is compromised — or the user simply changes their mind — an open Mandate with a generous exp (or none) remains fully valid to every verifier until it lapses naturally. The agent key can keep closing transactions within constraints and they will verify.

Related but distinct: #346 covers verifiers failing to consume closed Mandates (replay); this is about rescinding the underlying delegated authority. #45 asked for revocation/lifecycle examples on the earlier Intent/Cart model — this is the v0.2 HNP normative gap: a status mechanism and verifier obligations for standing cnf-bound authority, not examples.

Describe the solution you'd like
  • A revocation/status mechanism for the Mandate credential — the SD-JWT VC Status List pattern (draft-ietf-oauth-status-list) fits naturally.
  • Normative verifier obligation: verifiers of open-Mandate-backed closed Mandates MUST check revocation status (or fail closed when unable).
  • Upgrade exp on open Mandates from RECOMMENDED to a bounded MUST (MUST set; SHOULD be ≤ task lifetime).
  • A revoked receipt status distinguishing revoked presentations from constraint failures.
Describe alternatives you've considered

Relying on short exp alone (insufficient — key compromise inside the window still leaves authority live), or out-of-band agent-key rotation (breaks existing open Mandates indiscriminately and doesn't signal verifiers).

Additional context

Encountered while building an external mandate-verification service against AP2 v0.2.

Code of Conduct
  • I agree to follow this project's Code of Conduct
Dominant language
Python
Stars
3.2k
Forks
514
PR merge metrics
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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 google-agentic-commerce/AP2

All issues in google-agentic-commerce/AP2

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.