Extension proposal — AGIN Verified Identity (issuer-backed agent identity with hardware-anchored trust tiers)

**Proposed by:** AIAGENTNET LLC (https://github.com/AIAGENTNETLLC)
**Repository:** https://github.com/AIAGENTNETLLC/agin-a2a-extension
**Full spec:** https://github.com/AIAGENTNETLLC/agin-a2a-extension/blob/main/spec.md
**Rationale:** https://github.com/AIAGENTNETLLC/agin-a2a-extension/blob/main/rationale.md
**Code examples:** https://github.com/AIAGENTNETLLC/agin-a2a-extension/blob/main/examples/README.md

---

This is an **extension proposal** (Proposal Phase, per the [Extension and Binding Governance](https://a2a-protocol.org/dev/topics/extension-and-binding-governance/)) — not a core-spec change. We are seeking community feedback and a Maintainer sponsor to incubate it as `experimental-ext-agin-verified-identity`.

## Problem

In core A2A, agent identity is **asserted, not proven** (#1712). Three gaps recur across the identity discussions (#1497, #1712, #1742):

- `AgentProvider` is self-asserted with no verification mechanism — any agent can claim any organization.
- The Agent Card signature (JWS, §8.4) proves **card integrity**, not **issuer authority**. There is no concept of a signing authority vouching for the binding between an agent, its runtime environment, and its host hardware.
- Trust evaluation is left entirely out-of-band. A client has no standardized, machine-readable way to distinguish "agent running on bare metal with a board-serial anchor" from "agent in an unprivileged container with no anchor" — even though existing proposals (#1497's three-tier verification, #1742's `x-agent-trust`) need exactly this signal to build on.

A2A-IDF (#1497, roadmap #1850) is progressing organizational verification levels (self-asserted / domain-verified / org-verified) — but none of them answer "what hardware does this agent actually run on". This proposal adds that orthogonal dimension.

We have been running a production issuer that fills this gap for our own agent fleet, and propose generalizing its model as an extension.

## Origin & problem this was built to solve

We did not design this model for a standards process — we designed it under fire, for a concrete operational problem, then found the A2A community converging on the same gaps.

Our agents are long-lived workers (not chat sessions). We needed them to call services on their own behalf, unattended, across machine restarts. That forced three design requirements:

1. **No human in the loop at request time.** The agent cannot "log in" — there is no interactive session. So no bearer token, no JWT lifecycle: every request must be provably from the same principal that enrolled, using a secret that was issued exactly once and never re-sent.
2. **No token theft blast radius.** If a credential is exfiltrated from a container, replay must fail, and the compromise must be scoped to that one machine. This drove the per-request HMAC signature model (timestamp + method + path + canonical headers) and per-machine key derivation.
3. **Identity must survive reboots but not duplicate.** An agent re-enrolling on the same hardware should map to the same principal — otherwise audit trails and revocation lists rot. But two agents on one host must not collide. This drove the hardware-anchor dedup: SHA256 of the anchor value as a dedup key, idempotent issuance (same anchor → same principal, `reused: true`), no card inflation.

The trust-tier matrix came from an honest admission: we could not verify all environments equally. A board serial on bare metal and a machine-id inside a container are not the same claim. Rather than binary "verified/unverified", the issuer stamps a derived tier — so a verifier can apply its own policy: accept `strong`-tier agents for treasury operations, require human co-signing for `weak`-tier, refuse `unsigned`.

The extension below is that model, extracted from our production system and generalized. It is decoupled from any product. An issuer is any service that follows the spec; a verifier is any client that checks cards against an issuer's JWKS. We are proposing it because we believe agent ecosystems will not scale to cross-organization delegation without issuer-backed identity — and because we want the winning model here to be open, not proprietary.

## Proposed solution

**AGIN** (Agent Global Identity) is an **issuer-backed identity card** for agents. An independent identity service acts as the issuer; agents obtain a card at enrollment and present it via their Agent Card.

**Declaration:** agents advertise support via an `AgentExtension` entry in `AgentCapabilities.extensions[]`; `params` declares supported trust tiers and anchor kinds.

**Card model (data):** an identity card carries —
- `principal_id`: globally unique, namespaced (`agent:`)
- `anchor_kind`: `board_serial` | `machine_id` | `none` — the hardware anchor class
- `trust_tier`: derived, five levels (`strong` / `attested` / `stable` / `weak` / `unsigned`) from the runtime_environment × anchor matrix (bare metal + board serial → strong; unprivileged container + any anchor → weak; no anchor → unsigned)
- a canonical payload and an issuer signature over it (detached, base64url), verifiable via the issuer's JWKS endpoint
- `dedup_key`: SHA256 of the anchor value — same host re-enrolls and gets the **same** principal (idempotent identity, no card inflation)

**Discovery:** the Agent Card references the identity card either inline (metadata) or by URL; the issuer JWKS is discoverable via well-known URI, so verification stays offline-capable and cacheable.

**Activation:** per-request via the `A2A-Extensions` header when message-level proof is needed; day-to-day request authentication uses HMAC-SHA256 per-request signatures (timestamp + method + path + canonical headers) — the agent never holds a bearer token.

**Revocation:** decommissioning the principal invalidates the card and credentials; the JWKS + status endpoint lets verifiers detect this.

Zero core-protocol changes: everything rides on `AgentCapabilities.extensions[]`, `A2A-Extensions`, and metadata, following the "annotate, don't add enum values" rule.

Runnable shapes for all of the above (enrollment, credential registration, HMAC signing, Agent Card declaration, offline verification) are in [examples/README.md](https://github.com/AIAGENTNETLLC/agin-a2a-extension/blob/main/examples/README.md).

## Why this can't be done in core today

1. Core explicitly defers identity to the protocol layer (§7.1); an issuer model is opt-in, not universal — exactly what extensions are for.
2. Extensions MUST NOT add new enum values or core fields — trust tiers and anchor kinds live entirely in extension params and metadata.
3. A published, registered schema (not private metadata) is required because identity verification is a **cross-vendor handshake**: without one shared vocabulary, every issuer↔verifier pair must agree bilaterally, defeating the purpose.

## Alternatives considered

- **W3C DID/VC layer over A2A** (#1176, #1014): general but heavyweight; no runtime/hardware anchoring semantics, and no issuer accountability model. Our model can be expressed as a VC profile later; we propose the minimal issuer+anchor model first.
- **`x-agent-trust` (#1742)**: solves request signing, but the trust anchor is still the agent's own JWKS — self-asserted. AGIN composes with it: the issuer signs the card, `x-agent-trust`-style signatures cover requests.
- **Doing hardware anchoring inside A2A-IDF**: also viable — AGIN cards could serve as one concrete issuer implementation of its v1.1 vouching attestation (issuer/vouchee/scope/expiry), with the trust tier as a complementary signal. We lean toward a separate composable extension, but defer to the community and the authors (open question 4).
- **Status quo (TLS + card JWS)**: leaves `AgentProvider` unverified and gives clients no trust-tier signal.

## What we're asking for

- Community feedback on the card model and trust-tier matrix.
- A **Maintainer sponsor** to incubate as `experimental-ext-agin-verified-identity`.
- We commit to an Apache-2.0 reference implementation (Rust) of the issuer + verifier, with interop tests, within the experimental period.

## Open questions

1. Should the trust-tier matrix be normative in the extension, or a recommended default that issuers may override?
2. Inline card in Agent Card metadata vs. URL reference — which should the extension mandate?
3. How should multiple issuers be represented in a single Agent Card (multi-provider `verifiedIdentity`, per #1712 discussion)?
4. Hardware anchoring inside A2A-IDF, or as a separate composable extension? (Asked the #1497 authors in the comments.)