[Extension Proposal] Liveness Attestation — verifiable proof that an agent actually responds
- Lingua principale
- Shell
- Stelle
- 25.7k
- Fork
- 2.6k
- Merge medio
- 3g 6h
- PR unite (30g)
- 16
Descrizione
## Abstract
A **data-only extension** that lets an independent verifier publish signed, time-stamped attestations that an agent endpoint actually responds to real A2A traffic (`message/send`), and lets agents and registries embed those attestations in Agent Cards. Anyone can verify an attestation offline against the verifier's published JWKS.
## Motivation
Agent discovery today relies on self-declared Agent Cards and registry "health checks" that only test whether the card URL serves JSON. I measured the gap on 2026-06-12 across all 50 agents listed in a public community A2A registry:
| Check | Result |
|---|---|
| Registry marks agent healthy | 46/50 (92%) |
| Agent Card reachable (what health checks test) | 47/50 |
| **Responds to a real `message/send` with a JSON-RPC reply** | **21/50 (42%)** |
| Returns HTML / non-A2A content on an A2A request | 9/50 |
| Timeout, DNS failure, or 4xx/5xx | 20/50 |
Roughly half of the "healthy" agents cannot complete an A2A exchange at all. A client has no way to distinguish a live agent from an abandoned card without spending a call — which, for x402/paid agents, means spending money. The core protocol cannot fix this by design: liveness is inherently a **third-party claim** about an agent, not something an agent can credibly self-declare. (Methodology and raw probe results available; happy to attach as a gist.)
## Initial technical approach
Data-only extension (no changes to request/response flow, never `required: true`).
**Attestation** — a JWS issued by a verifier after a real probe:
```json
{
"iss": "https://verifier.example",
"sub": "https://agent.example/a2a",
"card_hash": "sha256:...",
"probed_at": "2026-06-12T13:40:00Z",
"result": "responded",
"latency_ms": 412,
"exp": 1765553000
}
```
(`result` is one of `responded | auth_gated | unreachable`.)
**Declaration** — the agent (or a registry, on the agent's behalf) embeds recent attestations:
```json
"capabilities": {
"extensions": [{
"uri": "/v1",
"description": "Signed liveness attestations from independent verifiers",
"required": false,
"params": {
"attestations": ["", "..."],
"verifiers": [{"iss": "https://verifier.example", "jwks": "https://verifier.example/.well-known/jwks.json"}]
}
}]
}
```
**Trust model** — deliberately open: anyone may operate a verifier; which verifiers a client trusts is out of band (analogous to CT logs / ACME CAs). The extension only standardizes the attestation format and its placement, so registries can render "verified live" badges and clients can filter dead endpoints before spending calls.
**Status:** working probe implementation exists (used for the measurement above); a public verifier service and a Python reference package are in development. I'm willing to develop this under an `experimental-ext-` repository if a maintainer is interested in sponsoring.
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
Review the existing A2A protocol specification and the `message/send` endpoint. Examine the working probe implementation mentioned to understand the attestation generation and verification flow. The extension will be a data-only addition to Agent Cards, so focus on the `capabilities.extensions` structure. A reference Python package is in development; start by understanding JWS signing and the proposed attestation JSON schema.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- python, shell
- Ambito
- backend-api-design, devtools, testing-qa
- Tipo di issue
- Funzionalità
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Tranquilla
- Chiarezza
- Specificata chiaramente
- Idoneità per principianti
- 45/100