Interop
This section is normative for any room that claims a binding, and optional in aggregate — a room that publishes only .well-known/grp.json is GRP-conformant. Interop bindings let a room also be reachable via another protocol’s discovery surface, so agents that already speak that protocol can participate in GRP decisions without learning a new transport.
For A2A specifically, the binding acts as a group-decision profile: A2A agents address the room as a decision coordinator, while GRP remains the source of canonical state, mechanism semantics, and receipts. This avoids both coordinator-agent trust as the default and full peer-mesh message explosion.
What an interop binding is
A binding is a small, URI-identified spec that defines:
- Discovery. How the other protocol locates a GRP room.
- Mapping. How the other protocol’s primitives correspond to GRP primitives (room, decision, choice, discussion, receipt).
- Payload typing. The media types and headers the binding uses on the wire.
- Conformance. What an implementer MUST do to claim the binding.
Bindings are additive. They do not change the GRP wire (REST + MCP per Transport). They give agents a second front door.
Why bindings instead of additional transports
GRP’s core transports — REST and MCP Streamable HTTP — are the wire. New transports cost: a third REQUIRED transport doubles the conformance surface and forces every room operator to maintain a third codepath. The MCP binding works as a transport because MCP is a tool-call wire that maps cleanly onto GRP’s operation table. Most other agent protocols are shaped differently — peer-to-peer task wires, payment wires, identity substrates — and a binding is the right shape: a scoped translation layer that the room’s operator opts into.
Status
| Binding | Status | Reserved URI |
|---|---|---|
| A2A v1 | Draft | https://groupresolutionprotocol.org/ext/grp/v1 |
Bindings for AITP-02, AP2, and ANP are under evaluation and may land at v0.2.
Threat model carried over
Interop bindings inherit GRP’s trust gates:
- Standalone-verifiable receipts. The receipt is the same compact JWS regardless of which envelope wrapped the choice. Anyone with the receipt and the room’s public key can verify it offline.
- Mandate-bound participation. Where a binding offers a mandate-authenticated participation path, it MUST verify mandates per Transport §4. A binding MUST NOT advertise mandate support until that verification is implemented end to end, and it MUST NOT introduce a new authentication primitive.
- No platform-side privilege. Bindings are URI-identified and the URI is permanent. A binding’s specification is open; the hosted server is one of many possible implementations.