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.
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:
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:
The composition with A2A would be lightweight:
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.