Cross-org, no shared AS: accountability layer for first-contact A2A transactions

We are working on an early open standard called OBO (On Behalf Of) that attempts to address a specific gap we have not seen covered in A2A or adjacent efforts: cross-organisational, cross-border agent transactions where no shared authorisation server exists and the two agents have never previously interacted.

We come to this humbly — OBO is a working draft, not a finished standard — and we would genuinely welcome input from the A2A community on whether and how it composes.

**The gap we are trying to fill**

A2A solves agent discovery and task routing cleanly. The Agent Card, well-known URI discovery, and task lifecycle model are well designed.

What A2A currently delegates or leaves open:

- **Principal authority chain** — who delegated authority to the calling agent? Which human or legal entity? Under what governance framework?
- **Cross-org first-contact authentication** — when two agents meet with no shared AS and no prior relationship, OAuth delegation requires federation that doesn't exist. The Agent Card's well-known URI is close to DNS anchoring but the authority verification path is not specified.
- **Tamper-evident post-task evidence** — immutable terminal task states are a good lifecycle model. They are not a cryptographically sealed, offline-verifiable record that a regulator, counterparty, or court can consume without calling anyone.
- **Legal entity accountability** — which organisation is liable if the task causes harm? The agent is not a legal person. The operator — the company that deployed it — is.

**Two patterns, not one**

We think A2A naturally supports two deployment patterns:

**Pattern 1 — within a trust domain:** Shared AS, pre-existing federation, enterprise deployment. OAuth, mTLS, existing A2A security schemes. Well solved. No change needed.

**Pattern 2 — across trust domains:** Cross-org, cross-border, no shared AS, first-contact. The calling agent needs to prove authority to a counterparty that has never met it, under a governance framework the counterparty can verify offline, producing a tamper-evident record of what was authorised and what executed.

Pattern 2 is the gap OBO attempts to fill.

**Proposed composition**

OBO defines two artefacts:
- **OBO Credential** (pre-task): principal_id, agent_id, operator_id, action_classes, intent_namespace, governance_framework_ref — DNS-anchored, offline-verifiable
- **OBO Evidence Envelope** (post-task): intent_hash, action_class, outcome, evidence_digest — tamper-evident sealed record

The composition with A2A would be lightweight:

```
A2A Agent Card → agent discovery, capability advertisement
A2A task routing → task assignment, lifecycle (unchanged)
OBO Credential → carried in A2A task metadata, principal authority chain
verified via DNS, no shared AS required
OBO Evidence → seals what the A2A task executed, post-task
A2A task.id → referenced in OBO evidence envelope as correlation anchor
```

The OBO Credential could be carried as an A2A extension, referenced in task metadata, or declared as a security scheme variant in the Agent Card. We are open to whichever composition point makes most sense to the A2A community.

**Where OBO is today**

OBO is a working draft RFC with a running Go reference implementation exercised end-to-end. It is early. We are not claiming it is finished — we are claiming the gap is real and we would welcome the A2A community's input on whether the composition makes sense and how it could be improved.

RFC draft and reference implementation: https://github.com/kevin-biot/obo-standard

We recognise the A2A steering committee represents serious organisations with deep experience in exactly these deployment scenarios. If this resonates, we would welcome a conversation.

Review the OBO RFC draft and Go reference implementation at the linked repository to understand the proposed credential and evidence artifacts. The issue discusses integrating these as extensions to A2A's Agent Card and task metadata. Start by examining the A2A specification for task routing and security schemes to identify potential composition points. The goal is to propose a design for how OBO artifacts could be carried within the A2A protocol.

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