From 37a9ebea621b6eeeaac8a13754f2b56fc6f95b02 Mon Sep 17 00:00:00 2001 From: scourtney-godaddy Date: Thu, 16 Apr 2026 02:24:48 -0400 Subject: [PATCH 1/4] docs: integrate ERC-8004, ENSIP-17, and ENSIP-25 into specs TRUST_INDEX_SPEC.md: - Add ENS_ENSIP25 (Strong) and ERC8004_VALIDATION (Moderate) to signal strength table - Split ENS_ENSIP25 escape difficulty: native .eth (Medium) vs ENSIP-17 DNS (Easy) - Solvency: check agent wallet, not token owner; freshness penalty on token transfer - Behavior: weight on-chain feedback by transaction cost, not count; persist across transfers - Integrity: add ERC-8004 token transfer as lifecycle event signal DESIGN.md: - Add ERC-8004 to "Relationship to other standards" with canonical ANS service entry format - Add ERC-8004 agentId as cross-RA correlation identifier Co-Authored-By: Claude Opus 4.6 (1M context) --- DESIGN.md | 26 ++++++++++++++++++++++---- TRUST_INDEX_SPEC.md | 20 +++++++++++++++----- 2 files changed, 37 insertions(+), 9 deletions(-) diff --git a/DESIGN.md b/DESIGN.md index 175a499..25482de 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -66,6 +66,14 @@ AgentDNS does not use DNS records; it is a separate naming system despite the na A client queries ADS for agents matching specific constraints, receives directory records that reference a Protocol Card and optionally an ANS name. When an ANS name is present, the client resolves it to verify identity before connecting. ADS handles discovery and selection. ANS handles identity and trust. The two do not overlap. +**ERC-8004 (Trustless Agents).** ERC-8004 (launched on Ethereum mainnet January 2026) defines on-chain agent identity as an ERC-721 token. The token carries an `agentURI` pointing to a JSON registration file with a `services` array listing the agent's endpoints by protocol. An ANS-registered agent that also has an ERC-8004 registration lists ANS as a service entry: + +```json +{"name": "ANS", "endpoint": "ans://v1.0.0.agent.example.com", "version": "1.0.0"} +``` + +The `endpoint` carries the full ANSName. The `version` carries the semver string separately. ENSIP-17 (Gasless DNS Resolution) lets any DNSSEC-enabled domain resolve through ENS to a wallet address without gas fees, using the same DNSSEC chain ANS checks for domain validation. ENSIP-25 defines a text record (`agent-registration[][]`) on the ENS name attesting association with an ERC-8004 token. The Trust Index verifies both directions: the ENSIP-25 record points from the ENS name to the agentId, and the registration file's services array points back to the ENS name (§5.3 of the Trust Index specification). + **Agent communication and execution protocols.** Google's A2A defines how agents collaborate across services. Anthropic's MCP defines how a model interacts with local tools and data sources. Neither defines how an agent proves its identity to an agent it has never met. ### 1.3 Foundational principles @@ -192,9 +200,12 @@ graph TD TL --> ES["Event Stream"] ES --> Disc["Discovery Services"] ES --> TI["Trust Index"] + AIM["AIM"] -.->|"findings"| RA + AIM -.->|"verify"| AHP + AIM -.->|"read"| TL ``` -*Figure 1. System boundaries. All trust artifacts flow through two chokepoints: the RA, where identity enters the system, and the TL, where sealed evidence leaves it. The AHP never writes to the log. Discovery services never query the RA.* +*Figure 1. System boundaries. All trust artifacts flow through two chokepoints: the RA, where identity enters the system, and the TL, where sealed evidence leaves it. Only the RA writes to the log. The AHP, AIM, Discovery Services, and Trust Index read from it but cannot alter it. The AIM reports findings to the RA; the RA decides whether to seal an integrity event.* ### 2.1 The Registration Authority system @@ -387,6 +398,8 @@ In a federated ecosystem, consumers scope the ProviderID by the RA Identifier to The ProviderID does not span RAs. The FQDN does. An agent moves between RAs by updating DNS records, not by changing its name. For cross-RA correlation, the registration payload accepts an optional `lei` field (Legal Entity Identifier, ISO 17442). When absent, correlation falls back to the domain and OV/EV certificate subject. +When the agent has an ERC-8004 registration, the `agentId` (ERC-721 tokenId on Ethereum mainnet) is an additional cross-RA correlation identifier. The tokenId is globally unique, permanently on-chain, and harder to shed than a domain name (minting costs gas; the token's reputation and validation history is permanent even after transfer). The registration file's `registrations` array supports multiple entries across chains and registries. + **Hosted-platform delegation.** When a platform registers an agent on behalf of a tenant, the ProviderID and `lei` field identify the platform and the tenant respectively. These are identity assertions, not delegation proofs. The tenant can close this gap by issuing a W3C Verifiable Credential (`ANS_DELEGATION` claim type) authorizing the platform to register on its behalf. The tenant signs the VC with its DID key; the platform includes the VC in the ANS Trust Card's `verifiableClaims` array. The Trust Index verifies the tenant's signature, confirms the delegation matches the registration's ProviderID and FQDN, and scores the identity dimension accordingly. The claim type and verification steps are defined in the Trust Index specification (§4.2). @@ -700,7 +713,7 @@ TLS secures transient, point-to-point API calls. Digital signatures secure durab | Log | Scope | Contents | | :--- | :--- | :--- | | Private (RA) | Internal | Debugging and forensic analysis | -| Public (TL) | Immutable, cryptographically verifiable | Finalized state changes: `AGENT_REGISTERED`, `AGENT_REVOKED`, `AGENT_RENEWED` | +| Public (TL) | Immutable, cryptographically verifiable | Finalized state changes: `AGENT_REGISTERED`, `AGENT_REVOKED`, `AGENT_RENEWED`. Integrity events: `INTEGRITY_WARNING`, `INTEGRITY_RESOLVED`. | ### 4.8 Producer key management @@ -727,8 +740,11 @@ The AIM is external to the RA. A malicious monitor could disable valid agents by The RA's remediation scope is infrastructure integrity: do the live DNS records and Server Certificate match what the RA sealed? When an ANS Trust Card is hosted and its content was hashed at registration, the AIM also verifies the card's integrity. The RA does not evaluate an agent's behavior or quality. The Trust Index evaluates behavior. -**Suppression before revocation.** The AIM records integrity findings in its own data store. A conforming RA MUST poll or subscribe to these findings. When a finding meets the quorum requirement (corroboration from multiple monitors), the RA independently re-verifies the reported mismatch against the TL's sealed records. -If confirmed, the RA publishes a suppression event to the TL. Discovery services that consume the event feed remove the agent from their indexes. Suppression is reversible. Revocation is permanent. The AHP retains time to investigate and correct the discrepancy. +**Integrity warnings, not state changes.** The AIM records integrity findings in its own data store. A conforming RA MUST poll or subscribe to these findings. +When a finding meets the quorum requirement (corroboration from multiple monitors), the RA independently re-verifies the reported mismatch against the TL's sealed records. +If confirmed, the RA publishes an `INTEGRITY_WARNING` event to the TL. The agent stays ACTIVE. Certificates, DNS, and mTLS are unaffected. When the discrepancy clears, the RA publishes `INTEGRITY_RESOLVED`. + +The Trust Index drops the integrity score for agents with unresolved warnings. Discovery suppression happens through scoring, not through a state change or an RA command. The RA publishes facts. The Trust Index reacts. **Domain lifecycle monitoring.** The AIM SHOULD monitor WHOIS/RDAP status and NS record changes for registered agents' domains. Status transitions to `pendingDelete`, `redemptionPeriod`, or `serverHold` indicate the domain is at risk. NS record changes indicate a potential provider migration. Both produce findings for the RA. @@ -816,6 +832,8 @@ If valid, the RA constructs the ANSName and sets the registration to `PENDING`. | **Version bump** | Code or config change | New version + fresh Identity CSR | Re-validates, issues new Identity Certificate | `AGENT_REGISTERED` | New per-version records added (`_ans`, `_ans-badge`); shared records unchanged (`_443._tcp`). The AHP updates `_ans-identity._tls` for the new Identity Certificate. | | **Renewal** | Identity Certificate approaching expiration, code unchanged | New CSR, same ANSName | Re-validates, issues fresh Identity Certificate | `AGENT_RENEWED` | None | | **Revocation** | Agent shutdown or version retirement | RFC 5280 reason code | Revokes Identity Certificate at Private CA | `AGENT_REVOKED` | Per-version records removed immediately; shared records removed when last ACTIVE version is gone | +| **Integrity warning** | AIM finding confirmed by RA re-verification | (AIM-initiated) | Re-verifies against TL sealed records | `INTEGRITY_WARNING` | None. Agent stays ACTIVE. | +| **Integrity resolved** | Discrepancy cleared | (AIM-initiated) | Confirms live state matches TL | `INTEGRITY_RESOLVED` | None | **Version coexistence.** During a version bump, both old and new versions are ACTIVE. The Server Certificate stays active (tied to the FQDN, not the version). A patch bump may coexist for hours; a major version change may coexist for months. The RA does not impose a retirement timeline. If the new registration fails validation, the old version remains ACTIVE. diff --git a/TRUST_INDEX_SPEC.md b/TRUST_INDEX_SPEC.md index 6cca887..7bb1d7b 100644 --- a/TRUST_INDEX_SPEC.md +++ b/TRUST_INDEX_SPEC.md @@ -159,6 +159,8 @@ The specification defines five signal categories, ordered from cryptographic fac | Discovery record coverage | Additional discovery channels beyond the `_ans` TXT record: DNS-AID SVCB, HCS-14 `_agent`, protocol-native well-known endpoints. Capped so discovery records alone cannot dominate this dimension. | | Cross-channel hash consistency `[PENDING]` | Agreement among the TL's sealed `capabilities_hash`, the DNS-AID `cap-sha256` parameter, and the live ANS Trust Card hash. Activates when `capabilities_hash` is populated in TL entries. | | Trust Card presence | Whether the agent hosts an ANS Trust Card with verifiable content hash. Agents without a Trust Card still register but score lower on integrity. | +| Unresolved integrity warning | Whether the TL contains an `INTEGRITY_WARNING` event for this agent without a subsequent `INTEGRITY_RESOLVED`. The RA publishes these events when the AIM confirms a discrepancy between live DNS or certificates and the TL's sealed records. An unresolved warning lowers the integrity score. A resolved warning restores it. | +| ERC-8004 token transfer | Whether the agent's ERC-8004 token (if any) has been transferred to a new owner, detectable via the ERC-721 `Transfer(from, to, tokenId)` event. The identity survives, but the agent wallet clears at the contract level. A conforming TI SHOULD treat a transfer the way it treats an ANS version bump: the registration persists, but the solvency proof is stale until the new owner re-establishes the wallet. | **Identity: Who stands behind this agent?** @@ -173,7 +175,7 @@ The specification defines five signal categories, ordered from cryptographic fac | Signal | What the TI checks | | :--- | :--- | -| Wallet proof | Zero-knowledge proof that the agent controls funds above a threshold, without revealing the balance | +| Wallet proof | Zero-knowledge proof that the agent controls funds above a threshold, without revealing the balance. When the agent has an ERC-8004 registration with a distinct agent wallet (set via `setAgentWallet`, separate from the token owner), the solvency proof SHOULD check the agent wallet address. The agent wallet is the address authorized to send payments. A proof against the owner address demonstrates organizational solvency but not the agent's spending authority. When the ERC-8004 token has been transferred (detectable via the ERC-721 `Transfer` event), the agent wallet clears at the contract level; a conforming TI SHOULD apply a freshness penalty to the solvency dimension until the new owner re-establishes the wallet and submits a solvency proof. | | Payment network history | Transaction volume, settlement rate, and chargeback ratio. Reflects willingness to pay, not just ability. | | Insurance | Active liability policy from a recognized insurer | | Escrow history | Track record of successful fund releases and disputes | @@ -187,14 +189,14 @@ The specification defines five signal categories, ordered from cryptographic fac | Peer endorsements | Signed attestations from other registered agents | | User ratings | Aggregated scores from verified interactions, weighted by reviewer identity grade | | Interop compliance | Handshake success rates, async response rates, credential grant honoring | -| On-chain feedback | Behavioral ratings on a blockchain registry such as ERC-8004. Transaction fees make fabrication expensive. | +| On-chain feedback | Behavioral ratings on a blockchain registry such as ERC-8004. A conforming TI SHOULD weight feedback by the transaction cost at submission time (`gasUsed * effectiveGasPrice` from the transaction receipt). Feedback submitted on Ethereum mainnet during high-gas periods carries more weight than feedback submitted on L2 chains, where the fabrication cost per review can be two to three orders of magnitude lower. ERC-8004 Reputation Registry feedback persists across token transfers because it is keyed to the agentId, not the owner address; a conforming TI SHOULD continue scoring the full feedback history after a transfer. | | License adherence | Whether the agent operates within machine-readable license terms. A recorded violation is a negative signal. | **Safety: Will this agent leak data or cause harm?** | Signal | What the TI checks | | :--- | :--- | -| Guardrail certification | Adversarial testing results from a recognized auditor | +| Guardrail certification | Results from adversarial testing, whether performed by a human auditor or an automated agent security scanning tool. When findings carry standardized threat taxonomy codes and severity levels, a TI can score at finer granularity than pass/fail. | | Data egress policy | Declared data flow restrictions, verifiable through TEE attestation | | Model provenance | Which LLM powers the agent, verified through a software signing transparency log | | Enclave attestation | TEE hardware details: provider, hardware version, SVN. Known-vulnerable generations are penalized. | @@ -576,7 +578,8 @@ The binding type determines how difficult it is for a bad actor to shed negative | `DID_WEB` | Domain control | Easy (register new domain) | | `LEI` | Legal entity (via vLEI, ISO 17442) | Medium (requires forming a new corporation) | | `BIOMETRIC_HASH` | Physical person | Hard (requires a new person) | -| `ENS_ENSIP25` | Ethereum account (via ENS name with ENSIP-25 bidirectional agent-registration record) | Medium (registering an ENS name costs ETH; creating many is expensive but requires no legal entity) | +| `ENS_ENSIP25` (native `.eth`) | Ethereum account (via ENS name with ENSIP-25 bidirectional agent-registration record) | Medium (registering a `.eth` name costs ETH and is permanently on-chain; creating many is expensive but requires no legal entity) | +| `ENS_ENSIP25` (ENSIP-17 DNS) | Ethereum account (via DNSSEC-resolved DNS domain with ENSIP-25 bidirectional agent-registration record) | Easy (domain registration fee, often under $15, plus free DNSSEC enablement; same barrier as `DID_WEB`) | A conforming TI MUST verify the principal binding against the declared type: - `DID_WEB`: Resolve `did:web:{domain}` by fetching `/.well-known/did.json`. Verify the DID Document exists and contains a valid verification method. @@ -655,6 +658,8 @@ A TI MUST verify that anchor domains match the agent's registered domain. A TI S | Self-asserted BIMI | Weak | Domain owner claims this logo, no CA verification | | DMARC `p=reject` | Moderate | Domain enforces strict email authentication | | Code signing certificate | Moderate | Publisher identity verified by CA | +| ENS_ENSIP25 | Strong | DNS domain resolves via ENS (Gasless DNS Resolution, ENSIP-17) with full DNSSEC proof chain verified by ENS contracts. | +| ERC8004_VALIDATION | Moderate | Agent has validation responses from accredited validators in the ERC-8004 Validation Registry, with the validator's contract address confirmed by the governance body. Signal quality depends on the validator's methodology (stake-secured re-execution, zkML, TEE attestation). | --- @@ -858,7 +863,7 @@ Unanswered questions block AI-adjudicated disputes: What prompts produce fair ad ### 8.5 Accredited verifiers -The consortium governance body accredits third-party verifiers for specific signal categories: identity verification firms, safety auditors, and solvency verifiers. The consortium sets standards; the verifier does the work. Individual RAs are registration services, not accreditation bodies. +The consortium governance body accredits third-party verifiers for specific signal categories: identity verification firms, safety auditors (including operators of automated agent security scanning tools), and solvency verifiers. The consortium sets standards; the verifier does the work. Individual RAs are registration services, not accreditation bodies. If a verifier's attestations prove fraudulent, the governance body revokes accreditation. Enforcement follows a ladder: warning, probation, suspension, distrust. @@ -1161,6 +1166,11 @@ This is the canonical schema. Where inline descriptions in the specification bod "properties": { "standard": { "enum": ["OWASP_LLM_TOP10", "AISI_2026_SAFE", "CUSTOM"] }, "version": { "type": "string" }, + "standardUri": { + "type": "string", + "format": "uri", + "description": "When standard is CUSTOM, a URI where a TI can fetch the taxonomy definition." + }, "auditorDid": { "type": "string" }, "reportHash": { "type": "string" }, "passedAt": { "type": "string", "format": "date-time" } From 96217c564629c4ad8153110af65898aa0446934a Mon Sep 17 00:00:00 2001 From: scourtney-godaddy Date: Thu, 16 Apr 2026 02:31:32 -0400 Subject: [PATCH 2/4] fix: wrap long lines to satisfy 400-char markdown lint Co-Authored-By: Claude Opus 4.6 (1M context) --- DESIGN.md | 9 +++++++-- TRUST_INDEX_SPEC.md | 6 +++--- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/DESIGN.md b/DESIGN.md index 25482de..a8f2f47 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -72,7 +72,10 @@ ADS handles discovery and selection. ANS handles identity and trust. The two do {"name": "ANS", "endpoint": "ans://v1.0.0.agent.example.com", "version": "1.0.0"} ``` -The `endpoint` carries the full ANSName. The `version` carries the semver string separately. ENSIP-17 (Gasless DNS Resolution) lets any DNSSEC-enabled domain resolve through ENS to a wallet address without gas fees, using the same DNSSEC chain ANS checks for domain validation. ENSIP-25 defines a text record (`agent-registration[][]`) on the ENS name attesting association with an ERC-8004 token. The Trust Index verifies both directions: the ENSIP-25 record points from the ENS name to the agentId, and the registration file's services array points back to the ENS name (§5.3 of the Trust Index specification). +The `endpoint` carries the full ANSName. The `version` carries the semver string separately. +ENSIP-17 (Gasless DNS Resolution) lets any DNSSEC-enabled domain resolve through ENS to a wallet address without gas fees, using the same DNSSEC chain ANS checks for domain validation. +ENSIP-25 defines a text record (`agent-registration[][]`) on the ENS name attesting association with an ERC-8004 token. +The Trust Index verifies both directions: the ENSIP-25 record points from the ENS name to the agentId, and the registration file's services array points back to the ENS name (§5.3 of the Trust Index specification). **Agent communication and execution protocols.** Google's A2A defines how agents collaborate across services. Anthropic's MCP defines how a model interacts with local tools and data sources. Neither defines how an agent proves its identity to an agent it has never met. @@ -398,7 +401,9 @@ In a federated ecosystem, consumers scope the ProviderID by the RA Identifier to The ProviderID does not span RAs. The FQDN does. An agent moves between RAs by updating DNS records, not by changing its name. For cross-RA correlation, the registration payload accepts an optional `lei` field (Legal Entity Identifier, ISO 17442). When absent, correlation falls back to the domain and OV/EV certificate subject. -When the agent has an ERC-8004 registration, the `agentId` (ERC-721 tokenId on Ethereum mainnet) is an additional cross-RA correlation identifier. The tokenId is globally unique, permanently on-chain, and harder to shed than a domain name (minting costs gas; the token's reputation and validation history is permanent even after transfer). The registration file's `registrations` array supports multiple entries across chains and registries. +When the agent has an ERC-8004 registration, the `agentId` (ERC-721 tokenId on Ethereum mainnet) is an additional cross-RA correlation identifier. +The tokenId is globally unique, permanently on-chain, and harder to shed than a domain name (minting costs gas; the token's reputation and validation history is permanent even after transfer). +The registration file's `registrations` array supports multiple entries across chains and registries. **Hosted-platform delegation.** When a platform registers an agent on behalf of a tenant, the ProviderID and `lei` field identify the platform and the tenant respectively. These are identity assertions, not delegation proofs. The tenant can close this gap by issuing a W3C Verifiable Credential (`ANS_DELEGATION` claim type) authorizing the platform to register on its behalf. The tenant signs the VC with its DID key; the platform includes the VC in the ANS Trust Card's `verifiableClaims` array. The Trust Index verifies the tenant's signature, confirms the delegation matches the registration's ProviderID and FQDN, and scores the identity dimension accordingly. The claim type and verification steps are defined in the Trust Index specification (§4.2). diff --git a/TRUST_INDEX_SPEC.md b/TRUST_INDEX_SPEC.md index 7bb1d7b..6b77de1 100644 --- a/TRUST_INDEX_SPEC.md +++ b/TRUST_INDEX_SPEC.md @@ -160,7 +160,7 @@ The specification defines five signal categories, ordered from cryptographic fac | Cross-channel hash consistency `[PENDING]` | Agreement among the TL's sealed `capabilities_hash`, the DNS-AID `cap-sha256` parameter, and the live ANS Trust Card hash. Activates when `capabilities_hash` is populated in TL entries. | | Trust Card presence | Whether the agent hosts an ANS Trust Card with verifiable content hash. Agents without a Trust Card still register but score lower on integrity. | | Unresolved integrity warning | Whether the TL contains an `INTEGRITY_WARNING` event for this agent without a subsequent `INTEGRITY_RESOLVED`. The RA publishes these events when the AIM confirms a discrepancy between live DNS or certificates and the TL's sealed records. An unresolved warning lowers the integrity score. A resolved warning restores it. | -| ERC-8004 token transfer | Whether the agent's ERC-8004 token (if any) has been transferred to a new owner, detectable via the ERC-721 `Transfer(from, to, tokenId)` event. The identity survives, but the agent wallet clears at the contract level. A conforming TI SHOULD treat a transfer the way it treats an ANS version bump: the registration persists, but the solvency proof is stale until the new owner re-establishes the wallet. | +| ERC-8004 token transfer | Whether the agent's ERC-8004 token has transferred (ERC-721 `Transfer` event). The agent wallet clears; solvency proof goes stale. Registration and reputation history persist. | **Identity: Who stands behind this agent?** @@ -175,7 +175,7 @@ The specification defines five signal categories, ordered from cryptographic fac | Signal | What the TI checks | | :--- | :--- | -| Wallet proof | Zero-knowledge proof that the agent controls funds above a threshold, without revealing the balance. When the agent has an ERC-8004 registration with a distinct agent wallet (set via `setAgentWallet`, separate from the token owner), the solvency proof SHOULD check the agent wallet address. The agent wallet is the address authorized to send payments. A proof against the owner address demonstrates organizational solvency but not the agent's spending authority. When the ERC-8004 token has been transferred (detectable via the ERC-721 `Transfer` event), the agent wallet clears at the contract level; a conforming TI SHOULD apply a freshness penalty to the solvency dimension until the new owner re-establishes the wallet and submits a solvency proof. | +| Wallet proof | Zero-knowledge proof that the agent controls funds above a threshold, without revealing the balance. When the agent has an ERC-8004 registration with a distinct agent wallet (`setAgentWallet`), the proof SHOULD check the agent wallet, not the token owner. On token transfer, the wallet clears; a conforming TI SHOULD apply a freshness penalty until the new owner re-establishes it. | | Payment network history | Transaction volume, settlement rate, and chargeback ratio. Reflects willingness to pay, not just ability. | | Insurance | Active liability policy from a recognized insurer | | Escrow history | Track record of successful fund releases and disputes | @@ -189,7 +189,7 @@ The specification defines five signal categories, ordered from cryptographic fac | Peer endorsements | Signed attestations from other registered agents | | User ratings | Aggregated scores from verified interactions, weighted by reviewer identity grade | | Interop compliance | Handshake success rates, async response rates, credential grant honoring | -| On-chain feedback | Behavioral ratings on a blockchain registry such as ERC-8004. A conforming TI SHOULD weight feedback by the transaction cost at submission time (`gasUsed * effectiveGasPrice` from the transaction receipt). Feedback submitted on Ethereum mainnet during high-gas periods carries more weight than feedback submitted on L2 chains, where the fabrication cost per review can be two to three orders of magnitude lower. ERC-8004 Reputation Registry feedback persists across token transfers because it is keyed to the agentId, not the owner address; a conforming TI SHOULD continue scoring the full feedback history after a transfer. | +| On-chain feedback | Behavioral ratings on a blockchain registry such as ERC-8004. A conforming TI SHOULD weight each review by its transaction cost (`gasUsed * effectiveGasPrice`), not by count. L2 feedback costs orders of magnitude less than mainnet and carries proportionally less weight. Feedback persists across token transfers (keyed to agentId, not owner). | | License adherence | Whether the agent operates within machine-readable license terms. A recorded violation is a negative signal. | **Safety: Will this agent leak data or cause harm?** From eb34bda7cbb6880ee10a80105206b54c054474e4 Mon Sep 17 00:00:00 2001 From: scourtney-godaddy Date: Thu, 16 Apr 2026 03:26:46 -0400 Subject: [PATCH 3/4] docs: expand AIM to general-purpose verification worker MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit AIM definition expanded from DNS-only checker to the RA's verification worker. Checks DNS, certificates, principal bindings (ENS/DID/LEI), credential signatures, and on-chain identity (ERC-8004). §5.4 table adds five verification type rows. Informational note in TRUST_INDEX_SPEC.md: when the RA's AIM has verified a credential before sealing, the TI is not required to re-verify it. Co-Authored-By: Claude Opus 4.6 (1M context) --- DESIGN.md | 12 +++++++++--- TRUST_INDEX_SPEC.md | 2 ++ 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/DESIGN.md b/DESIGN.md index a8f2f47..2eaf78f 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -103,7 +103,7 @@ A supplier passes a security audit on Tuesday, updates its model on Wednesday, a | **A2A** | Agent-to-Agent protocol for agent collaboration (Linux Foundation AAIF). | | **ACME** | Automatic Certificate Management Environment (RFC 8555). The protocol the RA uses to verify domain control. | | **AHP** | Agent Hosting Platform, a service that hosts agent code and manages registration on the owner's behalf. | -| **AIM** | Agent Integrity Monitor. Continuously checks DNS records and certificates against registered state. When an ANS Trust Card is hosted, the AIM also verifies its content hash. | +| **AIM** | Agent Integrity Monitor. The RA's verification worker. Continuously verifies agent state against the TL's sealed records, DNS infrastructure, certificate chains, principal bindings, and credential signatures. Reports findings to the RA. | | **ANS** | Agent Name Service, the directory and trust layer described in this document. | | **ANS Trust Card** | An optional COSE_Sign1 document at `/.well-known/ans/trust-card.json`. Protocol-native metadata plus ANS trust fields and a stapled SCITT receipt. The AIM verifies the content hash when Registration Metadata was submitted. | | **CA** | Certificate Authority, an entity that issues digital certificates. | @@ -206,9 +206,10 @@ graph TD AIM["AIM"] -.->|"findings"| RA AIM -.->|"verify"| AHP AIM -.->|"read"| TL + AIM -.->|"verification results"| TI ``` -*Figure 1. System boundaries. All trust artifacts flow through two chokepoints: the RA, where identity enters the system, and the TL, where sealed evidence leaves it. Only the RA writes to the log. The AHP, AIM, Discovery Services, and Trust Index read from it but cannot alter it. The AIM reports findings to the RA; the RA decides whether to seal an integrity event.* +*Figure 1. System boundaries. All trust artifacts flow through two chokepoints: the RA, where identity enters the system, and the TL, where sealed evidence leaves it. Only the RA writes to the log. The AIM is the RA's verification worker: it checks agent state against sealed records, DNS, certificates, principal bindings, and credential signatures. Integrity findings go to the RA. Verification results flow to the Trust Index, which scores without re-verifying what the AIM already checked.* ### 2.1 The Registration Authority system @@ -219,7 +220,7 @@ Generates the DNS records that make the agent discoverable, and ultimately seals **2.1.3 Provider Registry.** Decouples an entity's legal name from its identifier. When "AcmeCorp" becomes "MegaCorp," one record updates instead of re-registering thousands of agents. -**2.1.4 AIM.** Compares the live internet against what the RA sealed. When something doesn't match, it publishes a finding. It cannot revoke certificates or command state changes. +**2.1.4 AIM.** The RA's verification worker. Checks agent state against multiple sources of truth: the TL's sealed records, DNS infrastructure, certificate chains, principal bindings (ENS, DID, LEI), and credential signatures. When something doesn't match, it publishes a finding. It cannot revoke certificates or command state changes. **2.1.5 RA API.** The AHP registers an agent, submits CSRs for both certificate types, and triggers ACME and DNS verification. It can query registration status at any point, including partial registrations not yet sealed into the TL. It resolves an ANSName to its current registration and revokes a version at the AHP's request. Agent discovery flows from the Event Stream through independent indexing services, not through the RA. @@ -870,6 +871,11 @@ The AIM verifies each ACTIVE registration independently: | **Server Certificate** | TLS handshake to the FQDN, extract certificate fingerprint | Fingerprint matches what the RA sealed | Yes | | **ANS Trust Card integrity** | Fetch Trust Card from the `card` URL in the `_ans` record, hash the content | Hash matches the `capabilities_hash` sealed at registration | Only when Trust Card is hosted and Registration Metadata was submitted | | **Schema integrity** | Fetch each `schema.url` in the Trust Card, hash the content | Hash matches the `schema.hash` in the Trust Card | Only when Trust Card is hosted | +| **Principal binding (ENS_ENSIP25)** | Resolve ENS name, verify `agent-registration[][]` text record, verify ERC-8004 registration file lists ENS name | Both directions agree | Only when `principalBinding.type` is `ENS_ENSIP25` | +| **Principal binding (DID_WEB)** | Fetch `/.well-known/did.json` from the declared domain | DID Document exists and contains a valid verification method | Only when `principalBinding.type` is `DID_WEB` | +| **Principal binding (LEI)** | Verify vLEI credential signature against issuing organization's key | Signature valid and LEI active in GLEIF database | Only when `principalBinding.type` is `LEI` | +| **VC signature** | Resolve issuer DID, retrieve public key, verify signature, check expiration | Signature valid and credential not expired | Only when `verifiableClaims` are present in the Trust Card | +| **On-chain identity (ERC-8004)** | Verify agentId ownership on the Identity Registry, check Reputation Registry for active feedback | Owner address matches `principalBinding.identifier` | Only when `onChainId` references an ERC-8004 registration | Most registered agents do not host a Trust Card. For those agents, the AIM verifies DNS records and Server Certificate only. The Trust Index scores agents without a verifiable Trust Card lower on the integrity dimension, creating an incentive for AHPs to host one. diff --git a/TRUST_INDEX_SPEC.md b/TRUST_INDEX_SPEC.md index 6b77de1..55b06a5 100644 --- a/TRUST_INDEX_SPEC.md +++ b/TRUST_INDEX_SPEC.md @@ -476,6 +476,8 @@ A conforming TI MUST implement verification for each credential format: | SCITT receipt `[PROPOSED]` | Reconstruct Merkle root from inclusion proof and original entry. Verify TL signature against TL public key. Validate tree type. | | ANS_DELEGATION VC | Resolve issuer DID. Verify VC signature. Check expiration and credential status. Confirm `delegate.providerId` matches TL event. Confirm FQDN matches `scope.fqdnPattern`. Verify `lei` via GLEIF. | +When an RA's verification pipeline has already verified a credential before sealing the event, the TI is not required to re-verify it. The RA's Merkle proof and checkpoint signature attest to the verification having occurred. This applies to principal bindings, Trust Card integrity checks, and credential signatures that the RA's AIM verified at or after registration. The TI MUST still verify credentials it encounters independently of the RA's pipeline, such as agent-submitted VCs from oracle feeds or peer endorsements. + ### 4.6 Hosted-platform delegation (`ANS_DELEGATION`) My payment agent is about to wire $50,000 to an invoicing agent at `acme-invoicing.platform.example.net`. The Trust Index sees that the platform controls the domain. But I'm not paying the platform. I'm paying the tenant. The `lei` field in the registration names the tenant, but the platform typed that in. The tenant never signed anything. From 6621039b74bbfe1dbd51e7aec660c653f3b90a25 Mon Sep 17 00:00:00 2001 From: scourtney-godaddy Date: Thu, 16 Apr 2026 03:30:12 -0400 Subject: [PATCH 4/4] fix: wrap long lines to satisfy 400-char markdown lint Co-Authored-By: Claude Opus 4.6 (1M context) --- DESIGN.md | 5 ++++- TRUST_INDEX_SPEC.md | 6 +++++- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/DESIGN.md b/DESIGN.md index 2eaf78f..2108d6a 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -209,7 +209,10 @@ graph TD AIM -.->|"verification results"| TI ``` -*Figure 1. System boundaries. All trust artifacts flow through two chokepoints: the RA, where identity enters the system, and the TL, where sealed evidence leaves it. Only the RA writes to the log. The AIM is the RA's verification worker: it checks agent state against sealed records, DNS, certificates, principal bindings, and credential signatures. Integrity findings go to the RA. Verification results flow to the Trust Index, which scores without re-verifying what the AIM already checked.* +*Figure 1. System boundaries. All trust artifacts flow through two chokepoints: the RA, where identity enters the system, and the TL, +where sealed evidence leaves it. Only the RA writes to the log. The AIM is the RA's verification worker: it checks agent state against +sealed records, DNS, certificates, principal bindings, and credential signatures. Integrity findings go to the RA. Verification results +flow to the Trust Index, which scores without re-verifying what the AIM already checked.* ### 2.1 The Registration Authority system diff --git a/TRUST_INDEX_SPEC.md b/TRUST_INDEX_SPEC.md index 55b06a5..b799444 100644 --- a/TRUST_INDEX_SPEC.md +++ b/TRUST_INDEX_SPEC.md @@ -476,7 +476,11 @@ A conforming TI MUST implement verification for each credential format: | SCITT receipt `[PROPOSED]` | Reconstruct Merkle root from inclusion proof and original entry. Verify TL signature against TL public key. Validate tree type. | | ANS_DELEGATION VC | Resolve issuer DID. Verify VC signature. Check expiration and credential status. Confirm `delegate.providerId` matches TL event. Confirm FQDN matches `scope.fqdnPattern`. Verify `lei` via GLEIF. | -When an RA's verification pipeline has already verified a credential before sealing the event, the TI is not required to re-verify it. The RA's Merkle proof and checkpoint signature attest to the verification having occurred. This applies to principal bindings, Trust Card integrity checks, and credential signatures that the RA's AIM verified at or after registration. The TI MUST still verify credentials it encounters independently of the RA's pipeline, such as agent-submitted VCs from oracle feeds or peer endorsements. +When an RA's verification pipeline has already verified a credential before sealing the event, the TI is not required to re-verify it. +The RA's Merkle proof and checkpoint signature attest to the verification having occurred. This applies to principal bindings, +Trust Card integrity checks, and credential signatures that the RA's AIM verified at or after registration. +The TI MUST still verify credentials it encounters independently of the RA's pipeline, +such as agent-submitted VCs from oracle feeds or peer endorsements. ### 4.6 Hosted-platform delegation (`ANS_DELEGATION`)