a2aproject / a2aproject/A2A

[Feat]: Actor-chain extension: a standard payload shape for on-behalf-of delegation

Aperta
#2,028 24 commenti 0 reazioni 0 assegnatari Vedi su GitHub
Lingua principale
Shell
Stelle
25.7k
Fork
2.6k
Merge medio
3g 6h
PR unite (30g)
16

Descrizione

## Is your feature request related to a problem?

A2A v1.0 carries no principal in the payload. Authentication is out-of-band (`SecurityScheme` declarations plus transport mechanisms), and neither `Message`, `Task`, nor the agent card has a field for the human or upstream agent a request is made on behalf of. `tenant` is routing-only, and `metadata` is untyped, so every implementation that needs delegation context invents a private schema there.

The gap shows up as soon as agents delegate to agents. If agent C receives work from agent B, which received it from agent A acting for user U, C sees only B's transport credentials; the chain A→B→C-for-U exists nowhere on the wire. That loses attribution ("which human caused this side effect?"), makes audit reconstruction a cross-hop log-join, and feeds the confused-deputy problem already described in #153. #1937 proposes binding an already-valid delegation to a task/session/target/scope. This request is the complementary half: a standard shape for *carrying* the chain that a binding profile would bind.

## Describe the solution you'd like

An optional A2A extension (using the v1.0 extension mechanism, i.e. an `AgentExtension` entry in `capabilities.extensions[]`) that reserves one metadata member, `actorChain`, on `Message.metadata`, echoed on `Task.metadata`:

```json
{
"actorChain": {
"origin": { "sub": "user:alice@example.com" },
"actors": [
{ "sub": "agent:coordinator", "scopes": ["repo:read", "ci:trigger"] },
{ "sub": "agent:rebase-worker", "scopes": ["repo:read"] }
]
}
}
```

- The shape deliberately mirrors RFC 8693 (`act` claims, optional `may_act`) rather than inventing a delegation vocabulary. The ID-JAG and WIMSE drafts under active development in the OAuth working group build agent delegation on the same primitives, so an A2A chain can round-trip into token-level mechanisms as those ratify.
- Each hop can carry the scopes it held, so authority attenuation is visible in the audit record.
- **Audit, not authorization.** The chain is attribution history. It must not be used to grant access; authorization stays with the credentials the callee actually validated. A payload field any caller can write must never function as a credential, and the extension text should say so normatively.

Peers that don't declare the extension ignore the member (metadata is already tolerate-by-default). Peers that do declare it append their own hop when delegating onward.

## Describe alternatives you've considered

- **Keep it in private metadata** (status quo): works per-deployment, interoperates with nothing.
- **Core schema field instead of an extension**: cleaner long-term, but delegation semantics are still moving in the OAuth WG; an extension can track that work without holding core hostage.
- **Token-only (no payload representation)**: pushes every A2A implementation to parse provider-specific tokens for display/audit; a payload-level chain keeps audit rendering uniform even when the token format varies.

## Additional context

There's a running implementation of this shape (RFC 8693-style chain validated on ingest, hop appended per delegation, carried in `Message`/`Task` metadata) that we'd be glad to align with whatever shape maintainers prefer. If an extension proposal with a fuller spec draft would be more useful than this issue, happy to write that up.

*Disclosure: drafted with AI assistance and reviewed before posting; the design and implementation experience behind it are human-maintained.*

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

The issue proposes an extension to the A2A protocol's payload. Review the existing Message and Task metadata structures in the codebase, likely in specification or schema files. Understand the extension mechanism (AgentExtension in capabilities.extensions[]). The goal is to define a standard actorChain shape in metadata, ensuring it's for audit only, not authorization. Check for any existing implementations or tests related to delegation or metadata handling.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
json
Ambito
api, backend-api-design
Tipo di issue
Funzionalità
Difficoltà
4/5
Tempo stimato
3-5 giorni
Stato di attività
Attiva
Chiarezza
Specificata chiaramente
Idoneità per principianti
45/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.