Proposal: experimental-ext-lease — capability attenuation for A2A delegation (seeking a maintainer sponsor)

[TomCruiseTorpedo]

Summary

A2A's security model carries standing credentials (securitySchemes: OAuth2, API keys) — nothing in core attenuates what a delegated agent may DO once it's in. Per the extension governance framework, I'd like to propose an experimental extension — experimental-ext-lease — that carries a signed, time-boxed, narrowly-scoped capability lease per message, so an enforcing agent can apply deny-by-default least-privilege to every delegated action. The governance doc says experimental extensions need a maintainer sponsor: this post is the sponsor ask.

What exists today (shipped, not a sketch)

A versioned normative profile + implementation, in production shape against spec v1.0.1:

• Profile: a2a-lease-extension-v1.md — declaration at capabilities.extensions[] (§4.4.4) with required: true as an awareness gate (ExtensionSupportRequiredError, §3.3.4); token carriage in message metadata keyed by the extension URI (§4.6.2); per-contextId binding (A2A has no initialize handshake — first-presented token binds the context, conflicting re-binds rejected); a four-stage deny ladder (extension-support → lease → veto → allow); task-state pins (rejected for denial, auth-required for a pending human approval per §7.6, with out-of-band resume per §7.6.1).
• Token: PASETO v4.public (Ed25519, offline-verifiable, kid rotation) carrying typed, bounded capabilities (path globs, endpoint allow-lists, spend caps) with expiry, revocation, and a hash-chained audit trail — implemented in leasebroker.
• Wire proof: gatewarden serves a governed agent behind this profile over live HTTP (@a2a-js/sdk server face) with a full-stack test: real lease → carried per the profile → ingress ladder → governed downstream call → COMPLETED task; out-of-scope and tampered tokens reach REJECTED with zero downstream traffic.
• Security honesty: the required:true negotiation is an awareness gate only — the boundary is always token validation at the enforcer (profile §2/§8). Single-hop protection; chain delegation is future work and stated as such.

Why an a2aproject-hosted experimental extension rather than staying third-party

The capability-attenuation need keeps resurfacing (#153, #19, #1404, #1716, #1937) and the project's answer — reasonably — is the extension mechanism. But no authorization/capability extension exists at either registry tier yet, so every vendor rolls its own and interop dies at hop one. An experimental extension gives the ecosystem ONE profile to converge on or supersede, under project governance rather than any vendor's repo — and I'd expect the profile to change under review (the URI would move to the a2a-protocol.org/extensions/ namespace; the current profile is versioned for exactly that migration).

What I'm asking for

1. A maintainer willing to sponsor experimental-ext-lease per the governance framework.
2. Failing that, guidance on what WOULD make this sponsorable — happy to restructure the profile to fit.

I'll bring the same lease semantics to MCP's fine-grained-authz working group, so the two protocol lanes stay aligned rather than diverging.