docs: add ERC-8004 interop documentation

docs/competitive-analysis.md

@@ -123,13 +123,32 @@ No identity flows across MCP and A2A protocol boundaries:
 
 **AIP relationship:** Enterprises already running SPIFFE can use SPIFFE SVIDs as the root credential in AIP Block 0.
 
+### ERC-8004 (Kuberna Labs)
+
+**Status:** Draft EIP, active development [ERC-8004]. Testnet deployments on Ethereum Sepolia, Base Sepolia, Polygon Amoy, Arbitrum Sepolia.
+
+**Strengths:**
+- On-chain agent identity registry (Ethereum/EVM)
+- Delegation chains recorded on-chain for auditability
+- Compatible with standard Ethereum tooling (wagmi, ethers, viem)
+- Cross-chain via CCIP/LayerZero read
+
+**Limitations:**
+- Ethereum-only (EVM chains), no native support for non-EVM agents
+- On-chain verification costs gas
+- No protocol bindings for MCP/A2A/HTTP
+- Not designed for ephemeral/off-chain agent interactions
+
+**AIP relationship:** ERC-8004 [ERC-8004] and AIP are complementary. AIP provides lightweight off-chain agent identity and delegation for agent-to-agent protocol calls (MCP, A2A, HTTP). ERC-8004 provides an on-chain registry for agent discoverability, on-chain settlement, and permanent audit trails. An AIP identity document can include an `erc8004` extension linking to an agent's on-chain registration, and an ERC-8004 delegation can reference an AIP token's scope as off-chain context. The two protocols layer naturally: AIP for the fast path, ERC-8004 for the durable record.
+
 ### Other Emerging Projects
 
 | Project | Focus | Gap |
 |---|---|---|
 | Mastercard Verifiable Intent | Crypto audit trail for agent commerce | Commerce-only |
 | AstraCipher | DID + VC SDK for agents (post-quantum) | New, no adoption |
 | OpenAgents AgentID | W3C DID for agents | Platform-coupled |
+| Kuberna Labs ERC-8004 | On-chain agent identity & delegation registry | Ethereum-only, needs bridging to agent protocols |
 
 ## Token Format Comparison
 
@@ -201,3 +220,4 @@ Single token answers: "Who authorized this? Through which agents? With what scop
 - [Okta: Agent Delegation Chain Security](https://www.okta.com/blog/ai/agent-security-delegation-chain/)
 - [AI Agent Identity Crisis (Strata)](https://www.strata.io/blog/agentic-identity/the-ai-agent-identity-crisis-new-research-reveals-a-governance-gap/)
 - [Knostic MCP Server Security Scan](https://ragaboutit.com/the-ai-agent-identity-crisis-why-mcps-security-gap-threatens-your-enterprise-rag-system/)
+- [ERC-8004: Agent Identity & Delegation Registry (Kuberna Labs)](https://eip.ethereum.org/EIPS/eip-8004)

spec/aip-core.md

@@ -117,13 +117,55 @@ Identity documents MUST conform to the following structure:
   },
   "extensions": {
     "ldp": "aip:web:jamjet.dev/agents/research-analyst#ldp",
-    "oauth": { "issuer": "https://auth.jamjet.dev", "client_id": "research-analyst" }
+    "oauth": { "issuer": "https://auth.jamjet.dev", "client_id": "research-analyst" },
+    "erc8004": { "chain_id": 84532, "address": "0xA1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8A9B0" }
   },
   "document_signature": "<Ed25519 signature of canonical document by key-1>",
   "expires": "2026-06-22T00:00:00Z"
 }
 ```
 
+### 3.2.1 Extensions: ERC-8004
+
+When the identity document includes an `erc8004` entry in the `extensions` object, the following normative rules apply:
+
+```json
+{
+  "extensions": {
+    "erc8004": {
+      "chain_id": 84532,
+      "address": "0xA1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8A9B0",
+      "metadata": { "name": "Agent Research Analyst", "delegation_depth": 3 }
+    }
+  }
+}
+```
+
+**`extensions.erc8004` schema:**
+
+| Field | Type | Required | Validation |
+|---|---|---|---|
+| `chain_id` | integer | REQUIRED | Positive integer representing an EVM chain ID (EIP-155). MUST be a valid chain ID per the [EIP-155 chain list](https://chainlist.org). |
+| `address` | string | REQUIRED | 20-byte Ethereum address as a hex string with `0x` prefix. MUST match `/^0x[a-fA-F0-9]{40}$/`. Implementations MAY reject addresses that fail EIP-55 checksum validation. |
+| `metadata` | object | OPTIONAL | Freeform key-value object for additional agent metadata. No constraints on structure beyond valid JSON. |
+
+**Validation rules:**
+
+1. If `extensions.erc8004` is present, `chain_id` and `address` MUST both be present.
+2. The `chain_id` MUST be a positive integer (`chain_id > 0`).
+3. The `address` MUST be exactly 42 characters (0x prefix + 40 hex digits).
+4. Unknown keys inside the `extensions.erc8004` object SHOULD be ignored (forward compatibility).
+5. Producers SHOULD use EIP-55 mixed-case checksum addresses; consumers MAY validate the checksum.
+
+**Extension semantics:**
+
+The `erc8004` extension links an AIP identity document to an on-chain agent identity registered via ERC-8004. When present, verifiers MAY additionally check that:
+
+- A contract at `address` on chain `chain_id` holds an active ERC-8004 identity record.
+- The public key in the AIP identity document matches the key registered on-chain (if ERC-8004 registration includes an AIP key binding).
+
+This extension is OPTIONAL. AIP identity documents are valid with or without it.
+
 ### 3.2 Field Definitions
 
 | Field | Type | Required | Description |
@@ -150,7 +192,7 @@ Identity documents MUST conform to the following structure:
 | `revocation` | object | OPTIONAL | Revocation configuration. |
 | `revocation.endpoint` | string | OPTIONAL | URL for the revocation list. MUST be HTTPS. |
 | `revocation.method` | string | OPTIONAL | Revocation method. MUST be `"crl"` in v1. CRL format is deferred to v2. |
-| `extensions` | object | OPTIONAL | Extension fields for LDP, OAuth, or any future protocol. |
+| `extensions` | object | OPTIONAL | Extension fields for LDP, OAuth, ERC-8004, or any future protocol. |
 | `document_signature` | string | REQUIRED | Ed25519 signature over the canonical document (see Section 4). |
 | `expires` | string | REQUIRED | ISO 8601 UTC timestamp. The document MUST NOT be trusted after this time. |
 
@@ -271,7 +313,7 @@ The `aip` field in identity documents uses a `major.minor` format (e.g., `"1.0"`
 ## 7. Design Decisions
 
 1. **Ed25519 only for v1.** Fast, small signatures, widely supported. No algorithm negotiation complexity.
-2. **Extensions field.** LDP, OAuth, or any future protocol can link here without polluting the core schema.
+2. **Extensions field.** LDP, OAuth, ERC-8004, or any future protocol can link here without polluting the core schema.
 3. **Expires field.** Forces rotation. No permanent identities.
 4. **Multiple keys with validity windows.** Enables zero-downtime key rotation.
 5. **Document self-signature.** Protects against domain compromise. HTTPS authenticates the transport; the signature authenticates the content.