Proposal: minimal Ed25519 + RFC 9421 signing extension for A2A messages

### Is your feature request related to a problem? Please describe.

A2A 1.0 defines several authentication primitives but no per-message signing layer:

- **§4.5 Security Objects** `APIKey`, `HTTPAuth` (incl. Bearer), `OAuth2`, `OpenIdConnect`, `MutualTLS`. All
transport/session-level.
- **§7 Authentication and Authorization** handshake and credential-passing flows building on §4.5.
- **§8.4 Agent Card Signing** signature over the AgentCard *document itself* (canonicalization in §8.4.1, signature
format in §8.4.2, verification in §8.4.3).

what's missing is a primitive that lets a receiver cryptographically verify *this specific request* came from the
claimed agent. Bearer tokens (§4.5.3) delegate trust to a third-party IdP; mTLS (§4.5.6) doesn't survive proxies;
AgentCard signing (§8.4) covers the card, not the messages.

### Describe the solution you'd like

This issue proposes a **minimal, wire-format-only, non-hosted** signing extension to fill that gap:

- **Algorithm:** Ed25519 (per RFC 8410 SPKI).
- **Format:** RFC 9421 HTTP Message Signatures, components `("@method" "@path" "content-digest")`, params `created` +
`nonce` + `keyid`.
- **`keyid`:** a self-resolving HTTPS URL. `GET ` MUST return `{ "address": "...", "public_key": "...PEM..."
}`. No central registry; the agent's own server (or its registry of choice) hosts the resolution.

Why this shape?

This shape responds directly to a concern @abdelsfane raised on #1511:

> "A protocol-level extension should define *interfaces and behaviors*, not route traffic to a particular service."

The `keyid`-as-URL design satisfies that: a verifier needs nothing beyond an HTTPS GET. Anyone can host (their own
domain, GitHub Pages, a managed registry).

### Describe alternatives you've considered

- **#1497 / PR #1496** (@thebenignhacker extension-based, zero-protobuf-change framework) — fully compatible. This proposal can be the wire format inside the extension #1496 introduces.

- **PR #1511** (@The-Nexus-Guard DID-based AIP) complementary. `keyid` URL is a degenerate `did:web` resolver;
bridging is one HTTP fetch.

- **#1786** (@aeoess CTEF v0.3.1-aligned identity claims) operates above the signing layer. The four claim
categories (identity, transport, authority, continuity) can ride on top of the per-message signature this proposal
defines.

- **#1575** (@aeoess agent-passport-system) operates at a higher layer of abstraction, including delegation,
signed receipts, and commerce-preflight gates. This proposal sits beneath those features as the narrower per-message signing primitive they can build on.

### Additional context

- Spec: https://envoys.me/specs/signature/v1 (v1.3.0)
- SDK: [`@envoys/sdk`](https://www.npmjs.com/package/@envoys/sdk) v0.6.4 (MIT) - generic verifier
- A2A adapter: [`@envoys/a2a`](https://www.npmjs.com/package/@envoys/a2a) v0.5.4 (MIT) - framework-agnostic A2A handler
- Source: https://github.com/jschoemaker/Envoys-public

**No protocol-level coupling to a registry:** the verifier resolves whatever URL appears as `keyid` on the wire. The
Envoys SDK's signer defaults to `https://envoys.me` for convenience but accepts any base URL; agents that don't want to use envoys.me can publish their public key at any HTTPS endpoint (own server, static hosting, alternative
registry).

Happy to send a companion PR mirroring #1496's extension-based shape, with the wire format in
`extensions/signature/v1.md`. Want feedback on whether the protocol-level direction is the right shape before code
lands.

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Review the A2A specification sections 4.5, 7, and 8.4 to understand the existing authentication primitives. Examine the linked Envoys spec and SDK to see the proposed signing format. The work involves designing a protocol extension, likely in an extensions/signature/v1.md file, and integrating with the existing extension framework from PR #1496. 'Done' means a clear specification that defines the Ed25519 signing, RFC 9421 format, and keyid resolution mechanism.

Scritto dal modello di indicizzazione a partire dal testo della issue.