[TSC] Proposal: backlog consolidation & v1.1 scope alignment

## What this issue is asking of the TSC

Approval to take **23 open issues** and either **consolidate them** (16 issues → 5 tracking issues) or **close them as duplicates / off-topic** (6 issues); one extension proposal (#1796) is **retained and labeled** rather than closed. Consolidations are executed with a one-week comment window.

**This vote covers the *process and the mapping*, not the technical resolution of any individual issue** — each tracking issue keeps its own design discussion open.

## Rationale

- Several v1.1-relevant clusters are really *one* piece of work split across many issues (stream resumption, idempotency, push-config, skill selection, auth discovery). Consolidating gives contributors one place to follow each topic and affords the project a legible foundation to a v1.1 scope.
- A handful of issues are exact duplicates or off-topic (vendor notices, community submissions) and should be closed with a clear, courteous redirect.

## The plan

1. **Create** 5 umbrella "tracking" issues (drafts in the appendix).
2. **Notice** — post a consolidation comment on each consolidated issue announcing a **comment window (default: 1 week)**. Note: this does not apply to the "safe-now "closes (2 verified duplicates, 5 off-topic redirects).
3. **Close** — after the window, close the consolidated children, each referencing its umbrella.

**Guardrails:**
- Notice-before-close with a comment window — honors our "adequate notice and time for comment" norm; nothing is silently closed.
- Every close references the umbrella/original, so GitHub backlinks preserve the trail.

Draft consolidation comment each affected issue will receive:

> Thanks for raising this. We're consolidating closely related work into a single tracking issue so the discussion and design stay in one place: **[tracking issue]**. Your report is captured as a checklist item there. We plan to close this issue in favor of the tracking issue on or after **[window date]** — please follow it and continue the conversation there. If a specific requirement was lost or mis-summarized, comment before then and we'll fold it in (or reopen). Nothing is being dropped — just centralized.

## Mapping for consolidation
_Note: this mapping was the original proposal, an extended consolidation with a total of 8 umbrella epics is detailed in the thread ad os 30 June 2026_
| New tracking issue | Consolidates |
|---|---|
| **Reliable stream resumption & event ordering** | #1794 (anchor), #1410, #1635, #999 |
| **Idempotency & safe retries** | #928 (anchor), #1893 |
| **Push-notification config — security & semantics** | #1681 (anchor), #1250, #1483 |
| **Client-directed skill selection** | #143 (anchor), #1812 |
| **Auth scheme declaration & credential discovery** | #830 (anchor), #1795, #1770, #1745, #1454 |

### Close / convert — 6 issues

| Issue | Reason | Action | Status |
|---|---|---|---|
| #1879 | Exact duplicate of #1877 | close, link #1877 | done |
| #1819 | Exact duplicate of #1574 | close, link #1574 | done |
| #1741 | Community SDK submission | convert to Show and tell discussion | done |
| #1913 | Vendor deployment notice (tracks PR #1912) | add to partners list, then close issue | done |
| #1885 | "Coordination visibility only" notice (author states it's not a spec request) | close → Discussions | done |
| #1877 | Open-ended "seeking experiences" post | close → Discussions | done |

### Extension proposals — keep open, label, route (do _not_ close)

Per the [Extension & Protocol Binding Governance](https://a2a-protocol.org/latest/topics/extension-and-binding-governance/), an extension proposal **is** a Proposal-Phase issue in `a2aproject/A2A`. The proposer doesn't open it elsewhere — a sponsoring Maintainer creates any `experimental-ext-*` repo after community discussion. So these stay open and move through that process rather than being closed.

| Issue | Action |
|---|---|
| #1796 (telecom extension) | apply `extension-proposal` label; route to Proposal-Phase review for maintainer sponsorship |

**Process add (per @Tehsmash):** introduce an `extension-proposal` GitHub label or similar so all extension/binding proposals filter into one review queue, where maintainers/TSC decide whether to sponsor an experimental extension repo in the a2aproject org for it.

## What approval means / how to vote

- This issue is labeled `TSC Review`. @geneknit will trigger a vote with `/vote`.
- Per `.gitvote.yml`: vote is open to the `a2a-tsc` team, **passes at 51%**.
- 👍 to approve the plan as written. To change a specific disposition or the window length, comment and we'll amend.

---

# Appendix — umbrella issue drafts

The full text of the five tracking issues this proposal would create. (Mechanics — exact comment templates and the execution tooling — are handled separately and out of scope for this vote.)

## Umbrella issue drafts

Umbrella 1 — Reliable stream resumption & event ordering

## Tracking: Reliable stream resumption & event ordering

**Type:** Tracking / umbrella issue · **Proposed scope:** v1.1 (additive, backward-compatible)

### Problem

Clients today cannot reliably recover a streaming task across a disconnect. There is no per-task event ordering, no cursor to resume from, no defined replay behavior on `tasks/resubscribe`, and ambiguous behavior when more than one stream is active for the same task. This makes long-running tasks fragile in exactly the deployments (proxied, restart-prone) A2A targets.

### Consolidated issues

- [ ] #1794 — Add a generation/version (sequence) number to `Task`/events for ordering, long-polling, and optimistic concurrency *(anchor; `v1.1-candidate`, has gitvote)*
- [ ] #1410 — No "last message ID", so a stream cannot be robustly resumed
- [ ] #1635 — Data loss during SSE reconnection: should `resubscribe` replay missed events?
- [ ] #999 — Behavior of `tasks/resubscribe` with multiple active streams per task *(adjacent: stream multiplexing)*

### Acceptance criteria

- Events (`TaskStatusUpdateEvent`, `TaskArtifactUpdateEvent`) carry a monotonic, per-task sequence/generation number.
- `SubscribeToTask` / `resubscribe` accepts a last-seen cursor and has **defined** replay-or-gap semantics (replay missed events, or an explicit, detectable gap signal).
- Behavior with multiple concurrent subscriptions to one task is specified.
- Changes are reflected in `a2a.proto` and all three bindings (gRPC, REST, JSON-RPC) with binding equivalence preserved.
- Conformance/TCK cases cover reconnect + missed-event detection.

Umbrella 2 — Idempotency & safe retries

## Tracking: Idempotency & safe retries

**Type:** Tracking / umbrella issue · **Proposed scope:** v1.1 (additive, backward-compatible)

### Problem

If a client crashes (or the connection drops) after sending the first message but before it receives and persists the server-generated `taskId`/`contextId`, it has no way to learn whether a task was started on its behalf — and no safe way to retry. There is no transport-level mechanism to deduplicate retried requests.

### Consolidated issues

- [ ] #928 — Idempotency hole when sending the first message *(anchor; `v1.1-candidate`, defines the problem)*
- [ ] #1893 — Standardize an `Idempotency-Key` header for the JSON-RPC/HTTP binding *(proposed mechanism)*

### Acceptance criteria

- The spec defines an idempotency mechanism for message send (client-supplied idempotency key and/or a defined retry/replay contract).
- Server-side deduplication semantics are specified (what a server MUST do on a repeated key).
- Mechanism is expressed consistently across all three bindings.
- Security considerations are addressed (idempotency keys MUST NOT enable unauthorized cross-client interaction with a task — the original reason compound/client-set IDs were removed).

### Notes

#928 is the problem statement; #1893 is one concrete solution (an `Idempotency-Key` header). Resolve them together so the chosen mechanism actually closes the #928 hole.

Umbrella 3 — Push-notification config — security & semantics

## Tracking: Push-notification config — security & semantics

**Type:** Tracking / umbrella issue · **Proposed scope:** v1.1 (contains a security fix — prioritize)

### Problem

Several distinct gaps cluster around `PushNotificationConfig` / `TaskPushNotificationConfig`: secrets are returned on read, the `token` field's type is undefined, and the snapshot-on-registration semantics differ from `SubscribeToTask`.

### Consolidated issues

- [ ] #1681 — **Security:** `GetTaskPushNotificationConfig` / `ListTaskPushNotificationConfigs` return sensitive credentials *(anchor)*
- [ ] #1250 — Clarify the type/format of the `token` field (e.g. reference RFC 6750 Bearer)
- [ ] #1483 — Should push deliver a task snapshot as the first event on registration, matching `SubscribeToTask`?

### Acceptance criteria

- Read operations (`Get`/`List`) MUST redact or omit secret material; spec states this normatively.
- `token` field type/format is specified (or explicitly declared opaque) with a normative reference.
- Snapshot-on-registration behavior is defined for parity with subscribe (prevents the `GetTask`→`Subscribe` information gap).
- `a2a.proto`, spec text, and all bindings agree.

Umbrella 4 — Client-directed skill selection

## Tracking: Client-directed skill selection

**Type:** Tracking / umbrella issue · **Proposed scope:** v1.1 (optional, backward-compatible)

### Problem

An Agent Card can advertise multiple skills, each with its own `id`, but a client sending a message has no standard way to indicate *which* advertised skill it intends to invoke. For multi-skill agents — especially when an orchestrator already knows the target skill — the routing is left implicit.

### Consolidated issues

- [ ] #143 — Task submission should provide a way to specify the requested skill(s) *(anchor)*
- [ ] #1812 — Add an optional `skill_id` routing hint to `SendMessageConfiguration` *(concrete proposal for #143)*

### Acceptance criteria

- An **optional** skill identifier/hint can be supplied on send (e.g. on `SendMessageConfiguration`).
- Semantics defined for unknown/unsupported skill id (error vs. ignore).
- Strictly additive — single-skill agents and existing clients are unaffected.
- Reflected in `a2a.proto` and all three bindings.

Umbrella 5 — Auth scheme declaration & credential discovery

## Tracking: Auth scheme declaration & credential discovery in AgentCard

**Type:** Tracking / umbrella issue · **Proposed scope:** v1.1 (may split; larger design)

### Problem

When an A2A server requires OAuth, a client cannot determine *from the Agent Card alone* how to obtain a usable token — today it needs out-of-band knowledge (client registration, which grant, which AS). Assertion-based grants (RFC 7521/7523) are not modeled in the declared flows, and the normative "servers MUST reject invalid/missing credentials" language leaves the SDK-compliance boundary unclear.

### Consolidated issues

- [ ] #830 — OAuth 2.1-compliant authorization for A2A (align with MCP) *(anchor)*
- [ ] #1795 — Support OAuth RFC 7521 assertion-based authorization grants
- [ ] #1770 — Why is JWT assertion (RFC 7523) not one of the declared OAuth flows?
- [ ] #1745 — When OAuth is enabled, how does the client know how to generate the token? *(discovery gap)*
- [ ] #1454 — What does the authentication requirement mean in practice for SDK compliance?

### Acceptance criteria

- The Agent Card's declared security schemes are sufficient for a client to drive token acquisition without out-of-band knowledge (or the required out-of-band steps are explicitly documented).
- Assertion-based grants (RFC 7521/7523) are representable in the declared flows.
- Alignment with MCP's OAuth 2.1 direction is stated.
- The boundary between "protocol-compliant SDK" and "application-specific auth" is clarified (#1454).
- Docs include an end-to-end client token-acquisition walkthrough.