A2UI without A2A has some gaps

I was segmenting the specification into pure A2UI and A2UI+A2A extensions, and identified some gaps we might want to investigate. Not all of these will be in scope for A2UI (seems like many of the protocols that might want to have an A2UI extension may have already solved these) but the mechanisms needed should be called out somewhere, with suggestions for how to use them.

## Protocol gaps for non-A2A use cases

When A2UI connects to an agent using communication channels other than A2A (such as local standard input/output streams, local inter-process pipes, raw TCP/Unix sockets, or the Model Context Protocol), several protocol gaps appear. The A2A protocol provides native session grouping, out-of-band metadata exchange, and identity signing. Without A2A, the core A2UI protocol itself must offer the vocabulary to handle these transport-agnostic coordination needs.

Below are the identified gaps and recommendations to address them within the A2UI specification.

### 1. Initial connection handshake and capability exchange

A2UI clients and agents must negotiate which catalogs (UI components and client-side functions) they support before rendering can begin. A2A handles this during connection establishment via Agent Cards.
* **The Gap**: The core A2UI protocol does not define a standard initialization or handshake message. On simple transports (like standard input/output or Unix sockets), there is no protocol-level way for the client to announce its rendering capabilities or supported catalogs when it first connects to the agent.
* **Recommendation**: Add an optional connection initiation message (such as `clientInit` or `initializeSession`) to the core client-to-server message schema. This allows a client to stream its capabilities directly as the first message on the control channel, ensuring the agent knows which catalog is supported regardless of the underlying transport.

### 2. Multi-surface session grouping and context mapping

An agent session often manages multiple independent UI surfaces (such as a main view, a status bar, and dialog bubbles). A2A groups these naturally under a single `contextId`.
* **The Gap**: In a raw streaming transport (like standard input/output or a TCP socket), there is no native grouping concept. If an agent spawns sub-agents or manages multiple surfaces simultaneously over the same stream, A2UI has no built-in mechanism to cluster these surfaces under a single logical conversation or workspace.
* **Recommendation**: Add a transport-agnostic `sessionId` or `workspaceId` field to the `createSurface` message and the core message envelopes. This allows the agent and client to group related surfaces logically, facilitating multi-surface coordination over a single raw stream.

### 3. Asymmetric stream pairing

A2UI defines two separate message streams: Server-to-Client (UI updates) and Client-to-Server (actions and errors).
* **The Gap**: Some transports are half-duplex or asymmetric (such as HTTP streams where downstream is SSE and upstream is POST requests). The protocol does not specify how these independent channels correlate their sessions. If a client sends an action, the agent has no spec-defined way to correlate that action back to the active rendering stream unless the transport handles it.
* **Recommendation**: Specify a standard correlation identifier at the envelope level, allowing asymmetric transports to bind incoming client events to the active agent rendering session.

### 4. Client-agent trust and identity verification

In multi-agent configurations, an orchestrator must verify that a UI surface was created by a trusted agent, and that client actions are routed back to the correct agent instance.
* **The Gap**: The core protocol has no fields for conveying security tokens or verifying agent signatures. If an agent is running remotely or inside an isolated container, there is no standardized way to verify the agent's identity or pass security credentials at the protocol layer.
* **Recommendation**: Add an optional `credentials` or `authToken` field to the initial connection handshake. This provides a transport-independent slot for applications to carry security tokens or verification signatures.

### 5. Local resource referencing and file sandboxing

Agents often generate local resources (like images, plots, or PDF reports) that the UI needs to display.
* **The Gap**: A2UI components like `Image` reference assets using a `url` string. In local agent setups (such as an agent running as a CLI subprocess), the agent might generate a file on the local disk. However, the client renderer (which may be a sandboxed web application or desktop app) cannot access local paths (e.g., `file:///path/to/image.png`) due to security restrictions. The protocol lacks a way to transfer binary assets inline or map them to accessible references.
* **Recommendation**: Standardize a binary transfer payload (such as supporting base64-encoded inline data URIs or chunked data attachments in the data model) so agents can stream generated resources directly to the client without relying on external URL resolution.

The issue describes protocol gaps in the A2UI specification. Start by reviewing the core message schemas and transport definitions in the repository. Look for existing handshake, session grouping, and envelope structures. Understanding the A2A protocol extensions will be necessary to design the missing transport-agnostic mechanisms. 'Done' means the specification documents the recommended new fields and messages.

Escrito por el modelo de indexación a partir del texto del issue.