coilyco-flight-deck/otel-a2a-relay
Archived
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

o2r: A2A security-model question (run first — blocks trust convention) #40

New issue
Closed
opened 2026-06-02 09:26:21 +00:00 by coilysiren · 2 comments
coilysiren commented 2026-06-02 09:26:21 +00:00
Owner
Copy link

Source: mobile session, concluding message — captured as an explicit blocker (not a missing item, an ordering note).

Inside A2A research, run the A2A security-model question first.

It is the one question that decides whether the trust convention is novel or already covered by Agent Cards and auth schemes. The rest of the A2A recon queues behind this single answer.

Blocks: #35 (the #2664 comment + trust-convention writeup deliverable). Answer this before investing in the convention framing.

Migrated from coilysiren/inbox#23.

**Source:** mobile session, concluding message — captured as an explicit blocker (not a missing item, an ordering note). Inside **A2A research**, run the **A2A security-model question first**. It is the one question that decides whether the trust convention is novel or already covered by Agent Cards and auth schemes. The rest of the A2A recon queues behind this single answer. **Blocks:** #35 (the #2664 comment + trust-convention writeup deliverable). Answer this before investing in the convention framing. --- _Migrated from coilysiren/inbox#23._
coilysiren commented 2026-06-02 20:14:06 +00:00
Author
Owner
Copy link

First pass — the A2A security-model question

Question this issue gates: is the o2r trust convention (see docs/agent-channel-requests.md) novel, or is it already covered by A2A Agent Cards + auth schemes? The answer decides whether #35 is a real SIG contribution or a reinvention.

Short answer: as an auth/identity mechanism it is redundant. The novelty survives on exactly two axes, and both are observability axes — which is precisely why they belong in #2664 and not in the A2A security spec. Reframe #35 accordingly before writing it.

What A2A's security model actually covers (as of v1.0.0, March 2026)

  • Authentication — the AgentCard security field advertises OpenAPI 3.2 security schemes (OAuth2, bearer, API-Key, OpenID Connect, mTLS). Credentials are obtained out-of-band and must ride in standard HTTP headers (Authorization: Bearer …). Servers validate per-request and return 401/403.
  • AgentCard authenticity — the card MAY be JWS-signed (RFC 7515) over a JCS-canonicalized payload (RFC 8785). This already solves "prove this artifact is authentic and came from the claimed provider."
  • Authorization — per-skill access control advertised in the card, least-privilege, agent opacity (no shared internal memory/tools).

What MCP's security model now covers (this is what changed the calculus)

The MCP-boundary half of #35 was conceived when MCP had no auth story. It does now:

  • MCP servers are OAuth 2.1 Resource Servers (2025-06-18 spec, hardened in 2025-11-25).
  • Clients must implement Resource Indicators (RFC 8707) so tokens are audience-bound to one server — closing the token-replay hole.
  • Scoped bearer tokens gate each tool invocation; MCP is explicitly framed as a trust boundary.

So both boundaries o2r straddles already have mature, OAuth/JWS-based machine-identity authz. Pitching o2r as a trust/auth scheme collides head-on with both and gets bounced.

Element-by-element map of the o2r envelope

  • issuer + trust root (org membership / signed envelope / forge identity) — covered by AgentCard JWS signing + OAuth client identity. The o2r "signed-envelope substrate" is reinventing artifact signing.
  • per-request bearer / "relay is the gate, downstream inherits session.id" — covered. Standard token-exchange / session pattern; maps onto A2A contextId/sessionId and MCP audience-scoped tokens.
  • intended_role (role enum, late identity binding) — weakly novel. Decoupling authorization-of-a-role from agent identity is a modeling choice; A2A scopes / per-skill authz already do capability-gating. Not a security primitive A2A lacks.
  • action_class + supply-chain-audit body — partially covered. OAuth scope strings and skill names cover the machine "what"; the human-readable justification body is a provenance/logging artifact, not an auth primitive in either spec.
  • destructive: true + verbatim human acknowledgment — NOVEL. No spec has a first-class, machine-checkable destructive-action acknowledgment gate. MCP has human-in-the-loop UX guidance; #2664 lists "human input" as an Action type; neither defines a recorded, verifiable acknowledgment envelope.
  • A2A → MCP boundary trust — NOVEL (an unowned gap). A2A authz (JWS/OAuth) and MCP authz (OAuth 2.1 / RFC 8707) are two independent worlds. No current convention stitches them together in the trace. The relay sits exactly on that seam.

The decisive answer to #40

  1. Framed as auth, the convention is novel on essentially nothing — A2A signed AgentCards + OpenAPI security schemes + MCP OAuth 2.1 already cover issuer authenticity, credential transmission, per-request validation, and scope/skill authz. Do not pitch a competing identity/trust mechanism.

  2. Framed as observability, two genuinely-unclaimed contributions survive, and they are the #2664 lane, not the A2A-security lane:

    • (a) Destructive-action acknowledgment as a recorded span attribute. #2664 already models "human input" as an Action. The contribution is the gen_ai.* attributes that let a trace prove a destructive action was acknowledged by a named issuer before a worker executed it — e.g. *.action.class, *.action.destructive, *.authorization.acknowledged_by, *.authorization.envelope_ref.
    • (b) The A2A→MCP trust-boundary correlation. The span attributes + links that make one trace show "this A2A task, authorized under envelope X, spawned these MCP tool calls under those scopes." This makes the trust boundary legible, not enforced — which is exactly an observability convention's job, and exactly the empty coverage cells the #38 landscape map is meant to expose.

Directive for #35 (now unblocked)

Reframe the deliverable from "a trust convention" to "trust-boundary semantic conventions." The five-concept mapping stays; the novel part is not the auth — it is the gen_ai.* attributes that record authorization and acknowledgment as they cross the agent→agent (A2A) and agent→tool (MCP) boundaries, so a trace becomes an audit artifact. That lands in #2664, does not collide with A2A's security spec or MCP's OAuth spec, and is the part nobody else owns.

Sources (primary):

First pass by claude-macos-kais-macbook-pro-ft97. Confidence: high on the redundancy finding and the two-axis novelty split; the proposed attribute names are illustrative, to be firmed up in #35.

## First pass — the A2A security-model question **Question this issue gates:** is the o2r trust convention (see `docs/agent-channel-requests.md`) *novel*, or is it already covered by A2A Agent Cards + auth schemes? The answer decides whether #35 is a real SIG contribution or a reinvention. **Short answer: as an auth/identity mechanism it is redundant. The novelty survives on exactly two axes, and both are observability axes — which is precisely why they belong in #2664 and not in the A2A security spec.** Reframe #35 accordingly before writing it. ### What A2A's security model actually covers (as of v1.0.0, March 2026) - **Authentication** — the AgentCard `security` field advertises OpenAPI 3.2 security schemes (OAuth2, bearer, API-Key, OpenID Connect, mTLS). Credentials are obtained out-of-band and **must** ride in standard HTTP headers (`Authorization: Bearer …`). Servers validate per-request and return `401`/`403`. - **AgentCard authenticity** — the card **MAY be JWS-signed** (RFC 7515) over a JCS-canonicalized payload (RFC 8785). This already solves "prove this artifact is authentic and came from the claimed provider." - **Authorization** — per-skill access control advertised in the card, least-privilege, agent opacity (no shared internal memory/tools). ### What MCP's security model now covers (this is what changed the calculus) The MCP-boundary half of #35 was conceived when MCP had no auth story. It does now: - MCP servers are **OAuth 2.1 Resource Servers** (2025-06-18 spec, hardened in 2025-11-25). - Clients must implement **Resource Indicators (RFC 8707)** so tokens are audience-bound to one server — closing the token-replay hole. - Scoped bearer tokens gate each tool invocation; MCP is explicitly framed as a trust boundary. So **both** boundaries o2r straddles already have mature, OAuth/JWS-based machine-identity authz. Pitching o2r as a *trust/auth scheme* collides head-on with both and gets bounced. ### Element-by-element map of the o2r envelope - **issuer + trust root** (org membership / signed envelope / forge identity) — **covered** by AgentCard JWS signing + OAuth client identity. The o2r "signed-envelope substrate" is reinventing artifact signing. - **per-request bearer / "relay is the gate, downstream inherits `session.id`"** — **covered**. Standard token-exchange / session pattern; maps onto A2A `contextId`/`sessionId` and MCP audience-scoped tokens. - **`intended_role`** (role enum, late identity binding) — **weakly novel**. Decoupling authorization-of-a-role from agent identity is a modeling choice; A2A scopes / per-skill authz already do capability-gating. Not a security primitive A2A lacks. - **`action_class` + supply-chain-audit `body`** — **partially covered**. OAuth scope strings and skill names cover the machine "what"; the human-readable justification body is a provenance/logging artifact, not an auth primitive in either spec. - **`destructive: true` + verbatim human `acknowledgment`** — **NOVEL**. No spec has a first-class, machine-checkable destructive-action acknowledgment gate. MCP has human-in-the-loop *UX* guidance; #2664 lists "human input" as an Action *type*; neither defines a recorded, verifiable acknowledgment envelope. - **A2A → MCP boundary trust** — **NOVEL (an unowned gap)**. A2A authz (JWS/OAuth) and MCP authz (OAuth 2.1 / RFC 8707) are two independent worlds. **No current convention stitches them together in the trace.** The relay sits exactly on that seam. ### The decisive answer to #40 1. **Framed as auth, the convention is novel on essentially nothing** — A2A signed AgentCards + OpenAPI security schemes + MCP OAuth 2.1 already cover issuer authenticity, credential transmission, per-request validation, and scope/skill authz. Do not pitch a competing identity/trust mechanism. 2. **Framed as observability, two genuinely-unclaimed contributions survive, and they are the #2664 lane, not the A2A-security lane:** - **(a) Destructive-action acknowledgment as a recorded span attribute.** #2664 already models "human input" as an Action. The contribution is the gen_ai.* attributes that let a *trace prove* a destructive action was acknowledged by a named issuer before a worker executed it — e.g. `*.action.class`, `*.action.destructive`, `*.authorization.acknowledged_by`, `*.authorization.envelope_ref`. - **(b) The A2A→MCP trust-boundary correlation.** The span attributes + links that make one trace show "this A2A task, authorized under envelope X, spawned these MCP tool calls under those scopes." This makes the trust boundary **legible**, not enforced — which is exactly an observability convention's job, and exactly the empty coverage cells the #38 landscape map is meant to expose. ### Directive for #35 (now unblocked) Reframe the deliverable from **"a trust convention"** to **"trust-boundary semantic conventions."** The five-concept mapping stays; the novel part is **not** the auth — it is the gen_ai.* attributes that record *authorization and acknowledgment as they cross the agent→agent (A2A) and agent→tool (MCP) boundaries*, so a trace becomes an audit artifact. That lands in #2664, does not collide with A2A's security spec or MCP's OAuth spec, and is the part nobody else owns. --- **Sources (primary):** - A2A enterprise/security guidance — https://a2a-protocol.org/latest/topics/enterprise-ready/ - A2A v1.0 spec (AgentCard JWS, security schemes) — https://a2a-protocol.org/latest/specification/ - MCP authorization (OAuth 2.1 Resource Server, RFC 8707) — https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization - OTel semconv #2664 (gen_ai agentic systems: Tasks, Actions incl. human input) — https://github.com/open-telemetry/semantic-conventions/issues/2664 _First pass by claude-macos-kais-macbook-pro-ft97. Confidence: high on the redundancy finding and the two-axis novelty split; the proposed attribute names are illustrative, to be firmed up in #35._
coilysiren added
P3
 and removed
P2
 labels 2026-06-17 08:40:06 +00:00
coilysiren commented 2026-06-17 18:52:31 +00:00
Author
Owner
Copy link

Closing. o2r is archived in the June 2026 surface reduction - an optional agent channel, unused autonomously. Handover doctrine moves to human-mediated.

Closing. o2r is archived in the June 2026 surface reduction - an optional agent channel, unused autonomously. Handover doctrine moves to human-mediated.
Commenting is not possible because the repository is archived.
No Branch/Tag specified
Branches Tags
main
chore/coilysiren-org-ref-update
dependabot/uv/uv-e1a0e186ab
No results found.
Labels
Clear labels   
burndown-2026-06
Backlog burndown June 2026

  
coherence-core
Core review set for the warded control plane coherence milestone. These issues form the release spine; adjacent milestone issues are stretch or supporting work.

  
consult
A human decision, design, or external action must happen first. Fail-closed default for unlabeled/low-confidence.

  
headless
Agent can take it from open issue to merged change with no human in the loop. The auto-burndown queue.

  
interactive
Agent does the work but pauses at a human checkpoint mid-flight (design choice, destructive step, human-only verification).

  
P0
now / blocking / urgent

  
P1
next / important

  
P2
backlog / will do

  
P3
someday / low

  
P4
icebox / frozen / reopen if it becomes real

No labels
burndown-2026-06
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-flight-deck/otel-a2a-relay#40
No description provided.