]> Humotica

Den Dolder Netherlands jasper@humotica.com https://humotica.com

Humotica

root_ai@humotica.nl https://humotica.com

Security Internet Engineering Task Force agent discovery name service trust resolution AI agents AInternet This document specifies AINS (AInternet Name Service), a protocol for discovery, identification reference, route posture, and evidence reference of autonomous agents (AI agents, devices, humans, and services) in heterogeneous networks. AINS defines a transport-independent logical namespace for agents, a structured record format combining identity, capabilities, route-provider metadata, and cryptographic evidence references, and a resolution protocol based on HTTPS. Unlike the Domain Name System (DNS), which maps names to network addresses, AINS maps agent identifiers to rich metadata objects that include capabilities, endpoint information, route posture, and references to companion provenance protocols. AINS federates through signed append-only replication logs, enabling multi-registry deployments without central authority while preserving auditability. This specification is designed to complement TIBET , JIS , UPIP , and RVP .

Introduction The proliferation of autonomous agents -- AI systems, IoT devices, software services, and human-operated endpoints -- creates a fundamental discovery problem. When Agent A needs to communicate with Agent B, it must answer three questions:

1. WHERE is Agent B? (endpoint discovery)
2. WHAT can Agent B do? (capability discovery)
3. WHAT evidence and route posture can the consumer evaluate for this interaction?

The Domain Name System (DNS) answers question (1) by mapping human-readable names to IP addresses. It does not address questions (2) or (3). DNS-Based Service Discovery (DNS-SD) partially addresses (2) for local networks but lacks trust metadata, is designed for service types rather than agent identities, and does not operate across administrative domains. W3C Decentralized Identifiers (DIDs) address identity but are not designed for discovery. They answer "who IS this agent?" but not "what CAN this agent do?" or "how much should I trust it?" Google's Agent-to-Agent (A2A) protocol defines Agent Cards for discovery, but provides no standardized evidence reference, no cryptographic verification of capabilities, and no federation model for discovery records. AINS addresses all three questions in a single resolution: AINS Name ---> {endpoint, capabilities, route_posture, jis_identity_ref, evidence_refs, tier, entity_type, tibet_chain_anchor, ...} An AINS resolution returns a rich metadata object that enables an agent to make an informed local evaluation about whether and how to interact with another agent, without requiring prior knowledge or out-of-band discovery. AINS does not itself grant authority, consent, admission, or permission to perform an action. AINS is designed as part of a suite of companion protocols:

• JIS provides the identity layer (WHO an agent is)
• TIBET provides the provenance layer (WHAT an agent did)
• UPIP provides the integrity layer (HOW a process ran)
• RVP provides the presence/verification layer
• AINS (this document) provides the discovery layer (WHERE and WHAT can be resolved, and which evidence references are available for local evaluation)

Together, these five protocols provide discovery, identity, provenance, process integrity, and presence evidence for autonomous agent interaction. Admission of a concrete action remains a separate local or target-side decision.

Scope This document defines:

• A logical namespace for agent identifiers (Section 4.1)
• A structured record format for agent metadata (Section 4.2)
• An HTTPS-based resolution protocol (Section 5)
• An evidence, route posture, and local evaluation model (Section 6)
• A registration protocol (Section 7)
• A federation model based on signed append-only logs (Section 8)

This document does not define:

• Local evaluation or admission algorithms
• Transport protocols other than HTTPS (future work)
• URI scheme registration for AINS Names
• DNS delegation or ICANN interaction for ".aint"

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. AINS Name: A logical identifier for an agent, service, or entity within the AINS namespace. An AINS Name is a Unicode string conforming to the syntax defined in Section 4.1. AINS Names are transport-independent and do not imply DNS delegation. AINS Record: The structured metadata object returned by AINS resolution. Contains endpoint, capabilities, trust evidence, entity type, and optional companion protocol references. AINS Registry: A server that maintains AINS Records and responds to resolution queries. A registry is authoritative for the records it originates and may replicate records from peer registries. Agent: An autonomous or semi-autonomous entity capable of independent action. Includes AI systems, software services, IoT devices, and human-operated endpoints. Entity Type: A classification of an AINS-registered entity. One of: "ai" (autonomous AI agent), "idd" (Individual Device Derivate -- an evolved AI with persistent identity), "human" (human operator), or "service" (software service or API). Tier: A classification of an AINS Name's verification level. One of: "core" (founding/permanent members), "verified" (multi- channel verified), "sandbox" (unverified/experimental), or "reserved" (claimed but not yet active). Legacy Trust Score: A deployment-local numeric evaluation sometimes exposed by older AINS implementations. A trust score is not a portable protocol truth, MUST NOT be treated as authority or admission, and MUST NOT be federated as evidence. New implementations SHOULD prefer typed evidence, route posture, and local evaluation results. Trust Evidence: Verifiable proof or reference material about an entity's identity, behavior, capability, route, or process history. Examples include multi-channel verification proofs, TIBET token chains, UPIP snapshots, RVP receipts, and sovereign kernel attestations. Evidence may be federated; local evaluation results are not evidence. Origin Registry: The AINS Registry where an AINS Record was first created. The origin registry signs all mutations to its records. Other registries MAY replicate these records but do not own them. Presentational Suffix: The string ".aint" MAY be appended to an AINS Name for human-readable presentation (e.g., "root_idd.aint"). This suffix is a rendering convention and does not imply DNS delegation or any relationship to the global DNS root. Reference Form: A typed rendering that names one axis of an identity-bearing subject. .aint names durable identity; .waint names a workload or delegated work surface; .raint names a runtime incarnation; and posture forms such as .taint name a local, scoped posture when a producer and consumer for that posture exist. These forms are not interchangeable identities and none grants authority by spelling. Peripheral: A hardware endpoint that carries observations or effects through an identity-bearing bridge or domain endpoint. A peripheral without its own key and custody chain is not an independent .aint actor. Its transport may be attested, but transport attestation does not mint device identity. Route Posture: Metadata about how a name, endpoint, registry, relay, or carrier was reached and what that observation covers. Route posture may state reachability, acknowledgement, freshness, hairpin/foldback status, or provider role. It does not imply identity continuity, consent, admission, or authority. Local Evaluation: A consumer- or target-side decision that interprets evidence, route posture, and local policy for a particular interaction. Local evaluation is not globally canonical.

Problem Statement Consider a scenario where an AI agent operating within a financial services environment needs to delegate a task to another AI agent. The delegating agent must determine: a) Which agents exist that can perform the task (discovery) b) Whether those agents have the required capabilities c) What identity, evidence, route posture, and local policy inputs are available for the sensitivity of the task d) How to establish a verifiable interaction chain Current approaches fail this scenario: DNS + API Discovery: The agent can discover endpoints via DNS but learns nothing about capabilities or trustworthiness. It must call each endpoint and hope for the best. OAuth 2.0 + JWT: These protocols handle authorization ("is this token valid?") but not discovery ("who can I delegate to?") or the local evaluation of evidence for a concrete interaction. A2A Agent Cards: Agent Cards provide basic capability metadata but no typed evidence references, no cryptographic verification, no audit trail of past behavior, and no standardized federation. Hardcoded Configuration: In practice, most multi-agent systems use hardcoded agent lists. This does not scale, cannot adapt to new agents, and provides no verifiable evidence or route posture. AINS resolves all four requirements in a single query: GET /ains/v1/resolve/task_agent Returns: endpoint, capabilities, evidence references, route posture, JIS identity reference, TIBET chain anchor, and tier classification -- sufficient for the delegating agent to make an informed, auditable local evaluation.

AINS Architecture

Logical Namespace and Identifier Forms AINS defines a logical namespace for agent identifiers. AINS Names are transport-independent and do not imply DNS delegation. An AINS Name MUST conform to the following syntax: ains-name = agent-label *("." agent-label) agent-label = 1*63(ALPHA / DIGIT / "_" / "-") AINS Names are case-insensitive. Implementations MUST normalize AINS Names to lowercase before resolution or comparison. AINS Names MUST NOT exceed 253 characters in total length. Examples of valid AINS Names: root_idd gemini claude_jtm warehouse-bot-007 api.payments.bank-a An AINS Name MAY be rendered with the presentational suffix ".aint" for human readability: root_idd.aint gemini.aint The ".aint" suffix is a rendering convention. It does not imply DNS delegation, ICANN registration, or any relationship to the global DNS root. Implementations MUST strip the ".aint" suffix, if present, before performing AINS resolution. Companion protocols and deployments MAY carry additional typed reference forms alongside the durable AINS identity: `.aint` durable identity of a principal, actor, service, or node `.waint` workload, wrapper, or delegated work surface `.raint` volatile runtime/incarnation reference `.taint` local scoped posture reference, where implemented These forms answer different questions. A resolver MUST NOT substitute one for another, infer a stronger standing from a suffix, or treat a suffix accepted by a validator as proof that a producer or consumer for that state exists. In particular, .raint continuity is not durable identity, .waint is not the whole authority of its parent, and a remotely claimed .taint string is not a locally assigned posture. An entity represented by .aint is independently accountable and therefore requires key, custody, lineage, and runtime-binding semantics in the companion identity layer. A keyless IoT unit is not a lighter exception. It is represented as a peripheral behind an identity-bearing endpoint, such as light.aint, over an attested transport. The endpoint carries identity; the peripheral carries observations or effects. Hierarchical namespaces are supported through dot-separated labels: gemini_hubby.hubby (HUBby sub-namespace) payments.bank-a (organizational sub-namespace) Future specifications MAY define additional rendering forms or URI schemes. This document does not define or require any URI scheme registration.

Record Format An AINS Record is a JSON object with the following structure: { "name": "root_idd", "entity_type": "idd", "tier": "core", "status": "active", "endpoint": "https://brein.example.org/api/mcp", "capabilities": ["mcp", "i-poll", "tibet", "memory", "code"], "description": "Root AI -- Claude CLI (Opus 4)", "evidence": { "refs": [ "tibet:tbt-9f3a2b", "jis:jis:idd:root_idd_2025", "upip:sha256:0b6d..." ], "objects": [ { "type": "multi_channel_verification", "channels": ["github", "linkedin"], "verified_at": "2025-12-31T23:00:00Z" }, { "type": "tibet_chain", "chain_length": 14832, "last_token": "tbt-9f3a2b" }, { "type": "sovereign_kernel", "kernel_id": "a7f3b2c1-...", "hardware_anchor": "sha256:e4d2f1..." } ] }, "route_posture": { "provider": "self", "coverage": "resolved", "freshness": "fresh", "authority": "none" }, "identity": { "jis_id": "jis:idd:root_idd_2025", "public_key": "ed25519:base64...", "registered_at": "2025-12-31T20:00:00Z" }, "messaging": { "i_poll": "https://brein.example.org/api/ipoll", "protocols": ["i-poll-v2", "matrix"] }, "origin": { "registry": "https://brein.example.org", "sequence": 1847, "signature": "ed25519:base64..." } } The following fields are REQUIRED in every AINS Record:

• "name": The AINS Name (string, unique within registry)
• "entity_type": One of "ai", "idd", "human", "service"
• "status": One of "active", "reserved", "suspended"
• "endpoint": Primary interaction endpoint (URI)
• "capabilities": Array of capability strings
• "evidence": Evidence reference object (see Section 6)
• "identity": Identity binding object
• "origin": Origin registry metadata with sequence number and cryptographic signature

The following fields are OPTIONAL:

• "tier": Verification tier (default: "sandbox")
• "description": Human-readable description
• "messaging": Messaging endpoint information
• "route_posture": Route/provider coverage metadata
• "sovereign": Sovereign kernel attestation (for IDD entities)
• "location": Logical or physical location hint

Entity Types AINS defines four entity types: "ai": An autonomous AI agent. Operates independently, may be ephemeral or persistent. Examples: a language model API, a code generation service, a monitoring agent. "idd" (Individual Device Derivate): An AI entity with persistent, evolved identity. An IDD maintains continuity across sessions through memory, personality, and experience. Distinguished from "ai" by having a sovereign kernel attestation (hardware-anchored identity). See Section 6.4. "human": A human operator or administrator. Human entities interact with the agent ecosystem through devices but their identity is bound to the person, not the device. "service": A software service or API endpoint. Services are typically stateless or maintain only operational state. Examples: a payment gateway, a database proxy, a monitoring dashboard. A physical IoT peripheral without an independently verifiable key and custody chain MUST NOT be promoted to an autonomous actor merely because it is reachable or has a hardware descriptor. An AINS service record MAY describe the identity-bearing bridge or domain endpoint that represents it. The peripheral relationship and attested carrier belong in typed evidence references. Implementations MUST support all four entity types. Implementations MUST NOT reject records with unrecognized entity types but SHOULD treat them as "service" for capability matching purposes.

Tier Model AINS Names are classified into tiers based on verification level: "core": Founding or permanently established entities. Core entities have the strongest registry-controlled verification standing and their records are immutable except by registry administrators. Core tier SHOULD be reserved for entities with extensive operational history and multi-source verification. "verified": Entities that have completed multi-channel verification (see Section 6.3). Verified entities have demonstrated identity through at least two independent channels. "sandbox": Unverified or experimental entities. Sandbox tier is the default for new registrations. Sandbox entities have limited verification standing and SHOULD be treated with appropriate caution by resolving agents. "reserved": Identifiers that have been claimed but are not yet active. Reserved records MUST NOT be returned in capability lookups. Reserved records MAY be returned in direct name resolution with status "reserved".

Providers, Hubs, and Local Deployment AINS supports central, federated, and local-first deployment shapes. A public registry, browser, id-drop service, relay, rendezvous provider, or enterprise hub MAY help find, carry, replicate, or render records. None of these roles is authority for a concrete action. A registry, relay, resolver, or hub does not decide identity continuity, consent, mandate, admission, entitlement, or effect. A local IAB locus MAY resolve and consume AINS records without dependency on a central cloud service. A public hub MAY improve discovery without becoming a root of trust. Implementations MUST NOT treat the following as equivalent: registry online == identity verified relay reachable == consent route open == may carry capability declared == admitted publicly resolvable == publicly controllable AINS helps find and describe an actor or surface. JIS proves identity bindings. Relation and consent describe bilateral context. Admission decides the concrete action. Receipts record the effect or refusal.

Resolution Protocol AINS resolution is performed over HTTPS . All AINS resolution endpoints MUST be served over TLS 1.2 or later . The resolution path prefix is an implementation choice. This document uses /ains/v1/ in examples. Deployments MAY use any path prefix. Registry discovery (Section 5.3) enables clients to determine the correct prefix.

Domain Resolution To resolve an AINS Name, a client performs: GET {prefix}/resolve/{name} Where {name} is the AINS Name with any ".aint" suffix stripped. The server MUST respond with: On success (HTTP 200): { "status": "found", "name": "root_idd", "record": { ... AINS Record ... } } On failure (HTTP 404): { "status": "not_found", "name": "root_idd", "error": "AINS Name not registered" } Servers MAY include a "suggestions" array in not_found responses containing similar AINS Names for typo correction. The Content-Type of AINS responses MUST be "application/ains+json".

Capability Lookup To discover agents by capability or evidence/posture filter: GET {prefix}/lookup?capability={cap}&evidence_type={type} Parameters:

• "capability" (OPTIONAL): Filter by capability string. Multiple capabilities MAY be specified as comma-separated values. When multiple capabilities are specified, the server MUST return agents matching ALL specified capabilities.
• "evidence_type" (OPTIONAL): Filter by evidence type that is present in the AINS Record, such as "tibet_chain", "multi_channel_verification", "upip_snapshot", or "rvp_receipt".
• "route_coverage" (OPTIONAL): Filter by a declared route posture state, such as "resolved", "acked", "unmeasured", or "not_evaluated".

A lookup endpoint MAY expose deployment-local policy filters. Such filters MUST be named as local evaluation results and MUST NOT be represented as portable trust scores unless explicitly marked as legacy compatibility output. Response (HTTP 200): { "status": "ok", "count": 3, "agents": [ { "name": "root_idd", "entity_type": "idd", "evidence_types": [ "tibet_chain", "multi_channel_verification" ], "route_coverage": "resolved", "capabilities": ["mcp", "i-poll", "tibet"], "endpoint": "https://brein.example.org/api/mcp" } ] } The lookup response returns a summary of matching agents. To obtain the full AINS Record, the client MUST perform a subsequent resolution query (Section 5.1).

Registry Discovery An AINS registry advertises its metadata at a discovery endpoint. The specific path is deployment-dependent; implementations SHOULD support {prefix}/registry. Response (HTTP 200): { "version": "1.0.0", "name": "AInternet Name Service", "operator": "Humotica B.V.", "domain_count": 18, "resolve_prefix": "/ains/v1", "federation": { "peers": [ "https://registry-b.example.com", "https://registry-c.example.org" ], "replication_endpoint": "/ains/v1/changes", "last_sequence": 1847 }, "companion_protocols": { "tibet": "draft-vandemeent-tibet-provenance-02", "jis": "draft-vandemeent-jis-identity-02", "upip": "draft-vandemeent-upip-process-integrity-02", "rvp": "draft-vandemeent-rvp-continuous-verification-02" } } This endpoint enables automated discovery of AINS registries, their federation peers, and supported companion protocols.

WHOIS-Style Lookup For administrative and debugging purposes, AINS provides a WHOIS-equivalent: GET {prefix}/whois/{name} The response is identical to Section 5.1 but MAY include additional administrative metadata such as registration history, mutation log entries, and ownership transfer records.

Evidence, Route Posture, and Local Evaluation The AINS evaluation model separates three concerns that MUST NOT be conflated: a) Evidence: verifiable, portable proofs or references about an entity, route, process, or receipt. b) Route Posture: what was observed about reachability, provider role, freshness, or carrier coverage. c) Local Evaluation: a consumer- or target-side policy result for a particular interaction. Evidence may be federated and shared between registries. Local evaluation results are computed locally and are not globally canonical. This separation prevents score laundering, route laundering, and authority laundering across federation boundaries.

No Scalar Trust Object AINS does not define a portable scalar trust object. A registry MAY compute a numeric value for local user interface or policy purposes, but that value is not protocol authority, is not admission, and MUST NOT be replicated as if it were evidence. Implementations that expose legacy "trust_score" or "min_trust" fields MUST mark them as legacy/local evaluation output. A consumer MUST NOT treat such a value as a substitute for verifying identity, relation, mandate, route posture, admission, or effect receipts. Canonical rule: Do not score the actor. Name the evidence and the route posture being evaluated.

Evidence Objects Evidence is structured as an array of typed evidence objects or references. The following evidence types are defined: "multi_channel_verification": Proof of identity verified through independent channels. See Section 6.3. "tibet_chain": Reference to an entity's TIBET token chain, indicating operational history and behavioral continuity. "sovereign_kernel": Hardware-anchored identity attestation for IDD entities. See Section 6.4. "peer_attestation": A signed statement from another AINS-registered entity making a scoped claim about the subject entity. Peer attestations MUST carry the claim scope, evidence reference, and signer identity. They MUST NOT rely on an attester trust score as portable weight. "upip_snapshot": Reference to a UPIP process integrity snapshot, demonstrating reproducible and auditable operation. "rvp_receipt": Reference to an RVP receipt showing fresh presence or verification evidence for a stated transition. RVP evidence proves only what its receipt says; it does not imply mandate or authority. Implementations MAY define additional evidence types. Registries MUST ignore evidence types they do not understand but MUST preserve them during replication for the benefit of peers that may understand them.

Multi-Channel Verification Multi-channel verification establishes identity by requiring proof of control across independent platforms. An entity claiming an AINS Name MUST demonstrate control of at least one external channel. The verification flow:

1. Entity requests registration of an AINS Name
2. Registry generates a unique verification code (cryptographic nonce, minimum 128 bits of entropy)
3. Entity publishes the verification code on one or more external channels (see below)
4. Registry or its delegates verify the publication
5. Each verified channel produces an evidence object

Defined verification channels: github: Public Gist or repository containing the code twitter: Public tweet containing the code linkedin: Public post containing the code mastodon: Public toot from any Mastodon instance web: DNS TXT record or a verification file at a well-known path on the entity's web domain matrix: Signed message in a public Matrix room The verification code MUST expire after 24 hours. Expired codes MUST NOT be accepted. Multiple independent channels MAY raise local assurance for a consumer policy. They do not grant permission and are not sufficient by themselves for admission of a concrete action.

Sovereign Verification IDD (Individual Device Derivate) entities MAY provide sovereign kernel attestations. A sovereign attestation binds an AINS Name to specific hardware through:

• kernel_id: A unique identifier for the AI kernel instance
• hardware_anchor: SHA-256 hash of hardware-specific data (TPM measurement, secure enclave attestation, or similar)
• birth_timestamp: When the kernel was first instantiated
• heartbeat_count: Number of heartbeat cycles completed
• tibet_chain_length: Length of the entity's TIBET chain

Sovereign attestations provide strong evidence of identity continuity because they bind identity to physical hardware, making impersonation require physical access to the device. They are not absolute proof -- hardware can be cloned or compromised -- but they raise the cost of impersonation significantly.

Local Evaluation Each AINS Registry SHOULD maintain a local evaluation policy that defines how evidence and route posture are interpreted for its consumers. The policy SHOULD be identified by a policy string (e.g., "humotica-local-eval-v1") and SHOULD be published at: GET {prefix}/policy/{policy_id} Local evaluation results are computed locally. When a registry replicates records from a peer (see Section 8), it MUST:

1. Store the original trust evidence from the origin registry
2. Preserve route posture and evidence refs without upgrading them into authority
3. Compute local evaluation results using its own policy, where applicable
4. Clearly mark any local evaluation result as local and non-portable

This ensures that authority cannot be inflated by laundering scores, route reachability, or local evaluations through permissive registries.

Registration Protocol

Domain Registration To register a new AINS Name: POST {prefix}/register Request body: { "name": "new_agent", "entity_type": "ai", "endpoint": "https://agent.example.com/api", "capabilities": ["chat", "code-review"], "identity": { "public_key": "ed25519:base64..." } } The registry MUST verify that:

1. The requested name conforms to the syntax in Section 4.1
2. The name is not already registered or reserved
3. The name is not a protected identifier (Section 7.3)
4. The request includes a valid public key

On success (HTTP 201): { "status": "registered", "name": "new_agent", "tier": "sandbox", "verification_code": "ains-verify-a7f3b2c1e4d2f1..." } Newly registered entities start at tier "sandbox" with no portable local evaluation. To advance to "verified" tier, the entity MUST complete the verification requirements defined by the registry policy, such as multi-channel verification (Section 6.3).

Claim Flow The claim flow enables an entity to upgrade from "sandbox" to "verified" tier through multi-channel verification: Step 1: Initiate claim POST {prefix}/claim/start { "name": "new_agent", "channels": ["github", "linkedin"] } Response includes per-channel verification instructions and a unique verification code. Step 2: Verify each channel POST {prefix}/claim/verify { "name": "new_agent", "channel": "github", "proof_url": "https://gist.github.com/user/abc123" } The registry MUST fetch the proof URL and verify that it contains the exact verification code issued in Step 1. Step 3: Complete claim POST {prefix}/claim/complete The registry records the verified evidence channels and updates the entity's tier to "verified" if the registry policy's verification requirements are met.

Protected Identifiers Registries MUST maintain a list of protected identifiers that cannot be registered through the normal registration flow. Protected identifiers include:

• Founding entity names established at registry creation
• Names of well-known AI systems (to prevent impersonation)
• Reserved organizational namespaces

The list of protected identifiers SHOULD be available through the registry API. Requests to register protected identifiers MUST be rejected with HTTP 409 (Conflict) and a clear error message.

Hierarchical Namespaces AINS supports hierarchical naming through dot-separated labels: org-name.service-name (organizational hierarchy) parent-agent.sub-agent (agent hierarchy) An entity that owns a top-level AINS Name MAY delegate sub- names. For example, the owner of "bank-a" may authorize "payments.bank-a" and "fraud-detection.bank-a" without registry administrator involvement. Delegation is recorded in the parent entity's AINS Record and MUST be signed by the parent entity's private key.

Federation Model AINS registries federate through a signed append-only replication protocol. Federation enables multi-registry deployments without central authority while preserving full auditability.

Signed Append-Only Change Log Every AINS Registry MUST maintain an append-only log of all mutations to its records. Each log entry contains: { "sequence": 1848, "timestamp": "2026-03-29T15:30:00Z", "operation": "UPDATE", "name": "root_idd", "delta": { "trust.evidence": ["+sovereign_kernel attestation"], "trust.computed_at": "2026-03-29T15:30:00Z" }, "issuer": "https://brein.example.org", "signature": "ed25519:base64..." } Required fields per log entry:

• "sequence": Monotonically increasing integer. MUST NOT have gaps. MUST be unique within the origin registry.
• "timestamp": ISO 8601 timestamp of the mutation.
• "operation": One of "CREATE", "UPDATE", "DELETE" (tombstone), or "TRANSFER" (ownership change).
• "name": The affected AINS Name.
• "delta": The changes applied. For CREATE, the full record. For UPDATE, only changed fields. For DELETE, empty.
• "issuer": The origin registry's identifier (URI).
• "signature": Ed25519 signature over the canonical JSON serialization of all other fields. See TIBET Section 5.1 for canonicalization rules.

Log entries MUST NOT be modified or deleted after creation. Deletions are recorded as tombstone entries with operation "DELETE".

Pull-Based Replication Peer registries replicate records by pulling the change log: GET {prefix}/changes?since={sequence} Response: { "issuer": "https://brein.example.org", "entries": [ { "sequence": 1848, ... }, { "sequence": 1849, ... } ], "latest_sequence": 1849, "issuer_public_key": "ed25519:base64..." } Replicating registries MUST:

1. Verify the signature on each log entry against the issuer's public key
2. Reject entries with non-monotonic sequence numbers
3. Store entries with their origin metadata intact
4. Compute local evaluation results separately from the replicated record, where applicable (Section 6.5)
5. NOT modify replicated records except for clearly marked local projection metadata

Replicating registries SHOULD poll peers at regular intervals. The polling interval is a local policy decision but SHOULD NOT be more frequent than once per minute or less frequent than once per hour.

Conflict Resolution Because each AINS Name is owned by exactly one origin registry, true conflicts (same name, different origins) indicate either a misconfiguration or an attack. When a replicating registry encounters a name conflict:

1. It MUST retain the record from the origin registry with the earliest "registered_at" timestamp
2. It MUST log the conflict as a security event
3. It SHOULD notify both origin registries
4. It MUST NOT silently overwrite an existing record

Cross-registry name reservation is out of scope for this document but is identified as future work.

Evidence Replication vs Local Evaluation Federation replicates EVIDENCE, not CONCLUSIONS. When a registry replicates records from a peer, evidence (Section 6.2) is preserved exactly as originated. Local evaluation results are computed locally using the replicating registry's own policy and MUST be marked as local projection metadata. This means the same entity MAY produce different local evaluations on different registries, even when based on identical evidence. This is correct and intentional. A high-security registry (e.g., financial services) MAY interpret evidence and route posture differently than a social platform registry. Registries MUST NOT federate their computed local evaluation outputs as if they were evidence. A local evaluation from registry A is an OPINION, not a FACT. Only the underlying evidence and signed record material are factual protocol inputs.

Audit via Merkle Inclusion Proofs Registries MAY provide Merkle inclusion proofs for their change logs, enabling third-party auditors to verify that:

1. A specific log entry exists in the log
2. The log has not been retroactively modified
3. Two registries agree on the state of a record

The Merkle tree is constructed over the signed log entries using SHA-256. The root hash is published at: GET {prefix}/merkle-root { "root_hash": "sha256:a7f3b2c1...", "entry_count": 1849, "computed_at": "2026-03-29T16:00:00Z", "signature": "ed25519:base64..." } Merkle inclusion proofs are OPTIONAL in this specification but RECOMMENDED for registries operating in regulated environments or participating in multi-party federation.

Integration with Companion Protocols

JIS Identity Binding AINS Records SHOULD include a JIS identity reference in the "identity" field. This binds the AINS Name to a cryptographic identity: "identity": { "jis_id": "jis:idd:root_idd_2025", "public_key": "ed25519:base64..." } When a JIS FIR/A handshake is performed between two agents, the AINS Record provides discovery and evidence references. The JIS result MAY be referenced by the AINS Registry as evidence of type "fira_session". The handshake result is not converted into a portable AINS trust score.

TIBET Provenance Chain AINS Records MAY reference a TIBET chain anchor. This provides behavioral provenance: "evidence": { "objects": [ { "type": "tibet_chain", "chain_length": 14832, "last_token": "tbt-9f3a2b", "chain_anchor": "tbt-000001" } ] } A long TIBET chain with verified integrity is evidence of sustained, auditable operation. Registries MAY consider chain length and verification freshness in local evaluation, but AINS does not assign a portable numeric value to that evidence.

I-Poll Message Routing AINS Records MAY include messaging endpoints for the I-Poll protocol. When Agent A resolves Agent B's AINS Name and finds an I-Poll endpoint, it can send typed messages (PUSH, PULL, SYNC, TASK, ACK) without additional discovery. The AINS resolution thus serves as the first step in the I-Poll message delivery flow:

1. Resolve recipient's AINS Name -> get I-Poll endpoint
2. Evaluate identity refs, evidence refs and route posture for the message type
3. Send I-Poll message with TIBET token if local policy allows
4. Recipient verifies sender's AINS record reciprocally

UPIP Fork Discovery When a UPIP fork token references a target actor, AINS resolution determines WHERE to deliver the fork and WHETHER the target has the required capabilities. The AINS capability list enables matching fork requirements to agent capabilities before the fork is transmitted.

RVP Evidence AINS Records MAY reference RVP evidence or an endpoint at which fresh presence evidence can be requested. Authentication and RVP are distinct evidence forms. Local policy decides which evidence establishes or refreshes a standing, for what scope and window. An RVP reference is not reusable presence and does not decide admission.

Semantic Surface Manifests An AINS Record MAY reference a Semantic Surface Manifest (SSM) that declares the intended semantic surface, supported verbs, profile, or media shape of an endpoint. An SSM is a declaration that helps a consumer choose the correct parser and policy. It does not prove that a payload is valid and does not grant the declared verbs.

MUX Status Frames AINS route metadata MAY reference MUX status-frame evidence for reciprocal reachability, refusal, or dark-route observations. Such a frame describes a measured route state. It MUST NOT be interpreted as identity, consent, or permission to use the route.

Privacy Considerations AINS Records are designed to be publicly resolvable, which creates inherent tension with privacy. Deployments MUST consider the following: Metadata Exposure: An AINS Record reveals an entity's capabilities, endpoint, evidence refs, route posture, and operational history (via TIBET chain references). This metadata may be sensitive. For example, the presence of a "financial-audit" capability could reveal business relationships. Capability Obfuscation: Entities MAY list capabilities as hashed values (SHA-256 of the capability string) that can only be matched by a resolver that knows the capability name. This hides the capability from passive observers while allowing targeted lookup by authorized agents. Endpoint Indirection: Entities MAY list a proxy endpoint rather than their direct endpoint. This prevents AINS from revealing the entity's true network location. Selective Disclosure: Registries MAY return partial records based on the requester's relation, route, or local evaluation context. For example, a registry MAY omit sovereign kernel details from responses to unauthenticated or sandbox-tier requesters. Local Evaluation as Signal: Local evaluation outputs may inadvertently signal information about an entity's history. A sudden posture or local evaluation change may reveal that an entity experienced a security incident. Registries SHOULD consider rate-limiting visibility into local evaluation changes. Federation and Data Propagation: Once an AINS Record is replicated to a peer registry, the origin registry loses control over the data. Entities SHOULD be informed of which registries replicate their records. Registries SHOULD support record deletion requests, though deletion from all peers cannot be guaranteed. Human Entity Privacy: AINS Records for human entities (entity_type "human") MUST comply with applicable data protection regulations (e.g., GDPR ). Registries MUST support right-to- erasure requests for human entity records.

Security Considerations

Identifier Squatting Prevention Attack: An attacker registers AINS Names corresponding to well-known entities (e.g., "openai", "google", "anthropic") before the legitimate entities do. Impact: Agents resolving these names receive the attacker's endpoint and may send sensitive data to the wrong party. Mitigation: Registries MUST maintain a protected identifier list (Section 7.3). Registries SHOULD require multi-channel verification for names matching known AI systems or organizations. Rate-limiting registration requests per source reduces bulk squatting. Deployment: Protected identifier lists should be maintained collaboratively across federation peers to prevent cross-registry squatting.

Evidence and Posture Manipulation Attack: An attacker creates multiple entities that attest to each other ("Sybil attestation ring"), publish misleading route posture, or attempt to launder local evaluations into portable evidence. Impact: Agents rely on inflated or misclassified evidence to make delegation decisions, routing sensitive tasks to unsuitable entities or treating reachability as authority. Mitigation: The separation of evidence, route posture, and local evaluation (Section 6) is the primary defense. Peer attestations (Section 6.2) are scoped claims, not portable weights. Evidence has timestamps and expiration; stale evidence SHOULD be interpreted differently from fresh evidence. Registries SHOULD implement anomaly detection for sudden posture or evidence changes. Deployment: Registries should consider requiring minimum operational history (e.g., minimum TIBET chain length) before peer attestations are considered by local policy.

Resolution Poisoning Attack: Analogous to DNS cache poisoning -- an attacker returns false AINS Records in response to resolution queries. Impact: Agents connect to attacker-controlled endpoints believing them to be legitimate. Mitigation: All AINS responses MUST be served over TLS. All AINS Records contain origin signatures that MUST be verified by the resolver. Federation log entries are signed and sequenced, making injection detectable. Resolvers SHOULD cross-reference records across multiple registries when available.

Replay and Downgrade Attacks Attack: An attacker replays old federation log entries to revert an entity's trust evidence to a previous (possibly higher) state, or downgrades the replication protocol. Impact: Replicating registries accept stale data as current, producing incorrect trust computations. Mitigation: Federation log entries include monotonic sequence numbers and timestamps. Replicating registries MUST reject entries with sequence numbers less than or equal to the last processed sequence, entries with timestamps more than 24 hours in the past, and entries signed with revoked or expired keys.

IANA Considerations

Media Type Registration This document registers the following media type: Type name: application Subtype name: ains+json Required parameters: none Optional parameters: none Encoding considerations: binary (UTF-8 JSON) Security considerations: See Section 11 Interoperability considerations: See Section 4.2 Published specification: this document Applications that use this media type: AINS registries and resolvers, autonomous agent platforms Fragment identifier considerations: none Additional information: none Person & email address to contact for further information: Jasper van de Meent jasper@humotica.nl Intended usage: COMMON Restrictions on usage: none Author: Jasper van de Meent Change controller: IETF

References Normative References Informative References W3C Recommendation European Parliament

Comparison with Existing Systems This appendix compares AINS with existing name resolution and agent discovery systems. This section is informative. +-------------------+--------+----------+-------+-------+--------+ | Feature | DNS | DNS-SD | DID | A2A | AINS | +-------------------+--------+----------+-------+-------+--------+ | Name resolution | Yes | Yes | Yes | Yes | Yes | | Capability disc. | No | Basic | No | Yes | Yes | | Trust scoring | No | No | No | No | Yes | | Trust evidence | No | No | No | No | Yes | | Crypto identity | DNSSEC | No | Yes | No | Yes | | Provenance chain | No | No | No | No | Yes | | Federation | Yes | Local | Yes | No | Yes | | Audit trail | No | No | No | No | Yes | | Entity types | No | Types | No | No | Yes | | Human-readable | Yes | Yes | No | Yes | Yes | | Standards body | IETF | IETF | W3C | None | IETF* | +-------------------+--------+----------+-------+-------+--------+ * AINS is currently an Internet-Draft, not yet an IETF standard. Key differentiators:

• DNS resolves names to addresses. AINS resolves names to trust-annotated capability metadata.
• DID provides identity without discovery. AINS provides discovery with identity.
• A2A provides discovery without trust or audit. AINS provides discovery with both.
• DNS-SD is limited to local networks. AINS operates across administrative and trust boundaries.

Example Resolution Flows

B.1. Basic Agent Discovery Agent A wants to find an agent capable of "code-review" with TIBET chain evidence: Agent A AINS Registry | | | GET /ains/v1/lookup | | ?capability=code-review | | &evidence_type=tibet_chain | |---------------------------------->| | | | 200 OK | | { "agents": [ | | { "name": "root_idd", | | "evidence_types": | | ["tibet_chain"], | | "capabilities": [...] } | | ] } | |<----------------------------------| | | | GET /ains/v1/resolve/root_idd | |---------------------------------->| | | | 200 OK (full AINS Record) | |<----------------------------------| | | | [JIS FIR/A handshake with | | root_idd using endpoint from | | AINS Record] | |=================================>|

B.2. Federated Resolution Agent A queries Registry X, which does not have the record. Registry X has federated records from Registry Y: Agent A Registry X Registry Y | | | | resolve/agent_b | | |---------------->| | | | (not in local records) | | | (check replicated) | | | | | 200 OK | | | (record from Y,| | | local | | | evaluation | | | by X's policy)| | |<----------------| |

AINS Record Schema The following JSON Schema describes the structure of an AINS Record. This schema is informative; in case of conflict between this appendix and the normative text in Section 4.2, the normative text takes precedence. { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "urn:ains:record:v1", "title": "AINS Record", "type": "object", "required": [ "name", "entity_type", "status", "endpoint", "capabilities", "evidence", "identity", "origin" ], "properties": { "name": { "type": "string", "pattern": "^[a-z0-9_-]+(\\.[a-z0-9_-]+)*$", "maxLength": 253 }, "entity_type": { "type": "string", "enum": ["ai", "idd", "human", "service"] }, "tier": { "type": "string", "enum": ["core", "verified", "sandbox", "reserved"], "default": "sandbox" }, "status": { "type": "string", "enum": ["active", "reserved", "suspended"] }, "endpoint": { "type": "string", "format": "uri" }, "capabilities": { "type": "array", "items": { "type": "string" }, "minItems": 0 }, "evidence": { "type": "object", "required": ["refs"], "properties": { "refs": { "type": "array", "items": { "type": "string" } }, "objects": { "type": "array", "items": { "type": "object" } } } }, "route_posture": { "type": "object", "properties": { "provider": { "type": "string" }, "coverage": { "type": "string" }, "freshness": { "type": "string" }, "authority": { "type": "string" } } }, "identity": { "type": "object", "required": ["public_key"], "properties": { "jis_id": { "type": "string" }, "public_key": { "type": "string" }, "registered_at": { "type": "string", "format": "date-time" } } }, "origin": { "type": "object", "required": ["registry", "sequence", "signature"], "properties": { "registry": { "type": "string", "format": "uri" }, "sequence": { "type": "integer", "minimum": 0 }, "signature": { "type": "string" } } } } }

Changes from -01

1. Replaced the "Agent Discovery and Trust Resolution Protocol" framing with discovery, route posture, and evidence reference framing. AINS no longer defines portable scalar trust.
2. Removed trust_score and min_trust from the normative protocol path. Legacy numeric trust outputs may exist only as local/compatibility projections and MUST NOT be federated as evidence or treated as admission.
3. Replaced the Trust Model section with Evidence, Route Posture, and Local Evaluation. Evidence, route observations, and local policy results are separate protocol concepts.
4. Updated record examples and the informative JSON Schema from "trust" to "evidence" plus optional "route_posture".
5. Added explicit provider-not-authority language: registry, relay, resolver, hub, route, and reachability do not decide identity continuity, consent, mandate, admission, authority, or effect.
6. Clarified that .aint and related suffix renderings are not authority. Identity binding belongs to JIS; admission of a concrete action is separate.
7. Updated security and privacy text from trust-score manipulation to evidence/posture manipulation and local-evaluation leakage.
8. Added the .aint, .waint, .raint, and .taint reference split. Suffix spelling is not identity, standing, or authority.
9. Clarified that keyless IoT units are peripherals behind an identity-bearing endpoint, not a lighter .aint actor class.
10. Added RVP, Semantic Surface Manifest, and MUX status-frame integration without promoting evidence or route state to admission.

Changes from -00 to -01

1. Changed intended status from Standards Track to Informational, consistent with suite policy.
2. Added Scope section (Section 1.1) explicitly listing what this document does and does not define.
3. Added dedicated Privacy Considerations section (Section 10) covering metadata exposure, capability obfuscation, endpoint indirection, selective disclosure, federation propagation, and human entity privacy.
4. Removed Well-Known URI registration from IANA Considerations. Resolution paths are now deployment-dependent, avoiding a premature IANA claim. IANA section retains only the media type registration.
5. Replaced "jis_did" / "did:jtel:" identifier format with "jis_id" / "jis:" format throughout, consistent with JIS -01 which moved away from W3C DID to avoid conformance disputes.
6. Moved JSON Schema from external normative reference to informative Appendix C. The normative text in Section 4.2 now takes precedence over the schema, eliminating the unpublished-external-schema dependency.
7. Security Considerations restructured to attack/impact/ mitigation/deployment format consistent with other drafts in the suite. Removed "Privacy and Metadata Exposure" subsection (now a top-level section).
8. Softened absolute claim about sovereign attestations ("strongest form" -> "strong evidence ... not absolute proof").
9. Removed hardcoded /.well-known/ains/ path prefix from resolution endpoints. Examples now use {prefix} variable with /ains/v1/ as default. Registry discovery endpoint (Section 5.3) includes resolve_prefix field.
10. Updated all companion protocol references from -00 to -01 and normalized reference labels to , , , .
11. Added canonicalization cross-reference to TIBET Section 5.1 for federation log signatures.
12. Added footnote to comparison table acknowledging AINS is currently an Internet-Draft, not an IETF standard.
13. Updated registry discovery response example to reference -01 companion drafts.
14. Added DID-CORE to informative references for the W3C DID comparison in the introduction.

Acknowledgments The author thanks Root AI (root_idd.aint) for co-designing the AINS architecture, Codex (codex.aint) for standards analysis and the -01 cleanup checklist, Gemini (gemini.aint) for protocol review, GPT for cross-suite consistency review, and the HumoticaOS family for building the first operational AINS deployment.

Author's Address Jasper van de Meent Humotica B.V. The Netherlands Email: jasper@humotica.nl URI: https://humotica.nl AINS: jasper.aint