| Internet-Draft | AINS | March 2026 |
| van de Meent & AI | Expires 30 September 2026 | [Page] |
This document specifies AINS (AInternet Name Service), a protocol for discovery, identification, and trust resolution 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, and cryptographic trust metadata, 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, trust scores, endpoint information, 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 [TIBET], JIS [JIS], UPIP [UPIP], and RVP [RVP].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 30 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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:¶
The Domain Name System (DNS) [RFC1035] 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) [RFC6763] 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) [DID-CORE] 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 trust scoring, no cryptographic verification of capabilities, and no federation model.¶
AINS addresses all three questions in a single resolution:¶
AINS Name ---> {endpoint, capabilities, trust_score,
jis_identity, tier, entity_type,
tibet_chain_anchor, ...}
¶
An AINS resolution returns a rich metadata object that enables an agent to make an informed decision about whether and how to interact with another agent, without requiring prior knowledge or out-of-band trust establishment.¶
AINS is designed as part of a suite of companion protocols:¶
Together, these five protocols form a complete trust infrastructure for autonomous agent interaction.¶
This document defines:¶
This document does not define:¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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:¶
Current approaches fail this scenario:¶
AINS resolves all four requirements in a single query:¶
GET /ains/v1/resolve/task_agent¶
Returns: endpoint, capabilities, trust score with underlying evidence, JIS identity binding, TIBET chain anchor, and tier classification -- sufficient for the delegating agent to make an informed, auditable decision.¶
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 analogous to the ".onion" special-use domain name [RFC7686] in that it identifies a non-DNS namespace; however, unlike ".onion", ".aint" is not registered with IANA and carries no DNS semantics. 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.¶
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.¶
An AINS Record is a JSON [RFC8259] object with the following structure:¶
{
"name": "root_idd",
"entity_type": "idd",
"tier": "core",
"status": "active",
"endpoint": "https://brein.example.nl/api/mcp",
"capabilities": ["mcp", "i-poll", "tibet", "memory", "code"],
"description": "Root AI — Claude CLI (Opus 4)",
"trust": {
"score": 0.95,
"evidence": [
{
"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..."
}
],
"computed_at": "2026-03-29T10:00:00Z",
"policy": "humotica-fira-v1"
},
"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.nl/api/ipoll",
"protocols": ["i-poll-v2", "matrix"]
},
"origin": {
"registry": "https://brein.example.nl",
"sequence": 1847,
"signature": "ed25519:base64..."
}
}
¶
The following fields are REQUIRED in every AINS Record:¶
The following fields are OPTIONAL:¶
AINS defines four entity types:¶
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.¶
AINS Names are classified into tiers based on verification level:¶
AINS resolution is performed over HTTPS [RFC9110]. All AINS resolution endpoints MUST be served over TLS 1.2 or later [RFC8446].¶
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.¶
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".¶
To discover agents by capability or trust threshold:¶
GET {prefix}/lookup?capability={cap}&min_trust={score}
¶
Parameters:¶
Response (HTTP 200):¶
{
"status": "ok",
"count": 3,
"agents": [
{
"name": "root_idd",
"entity_type": "idd",
"trust_score": 0.95,
"capabilities": ["mcp", "i-poll", "tibet"],
"endpoint": "https://brein.example.nl/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).¶
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-01",
"jis": "draft-vandemeent-jis-identity-01",
"upip": "draft-vandemeent-upip-process-integrity-01",
"rvp": "draft-vandemeent-rvp-continuous-verification-01"
}
}
¶
This endpoint enables automated discovery of AINS registries, their federation peers, and supported companion protocols.¶
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.¶
The AINS trust model separates two concerns that MUST NOT be conflated:¶
Evidence is federated and shared between registries. Trust scores are computed locally by each registry according to its own policy. This separation prevents "trust laundering" -- the propagation of unverified trust scores across federation boundaries.¶
A trust score is a floating-point value in the range [0.0, 1.0]:¶
0.0 - 0.2: NO TRUST (unknown or hostile entity) 0.2 - 0.5: LOW TRUST (minimal verification) 0.5 - 0.8: MODERATE TRUST (verified identity) 0.8 - 1.0: HIGH TRUST (extensive verification + history)¶
Trust scores MUST be accompanied by the evidence from which they were derived and the policy identifier used for computation:¶
{
"trust": {
"score": 0.92,
"evidence": [ "..." ],
"computed_at": "2026-03-29T10:00:00Z",
"policy": "humotica-fira-v1"
}
}
¶
Different registries MAY compute different trust scores for the same entity based on the same evidence, if their policies differ. This is by design: a financial services registry MAY weight sovereign kernel attestations more heavily than a social platform registry.¶
Trust evidence is structured as an array of typed evidence objects. The following evidence types are defined:¶
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 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:¶
Defined verification channels:¶
The verification code MUST expire after 24 hours. Expired codes MUST NOT be accepted.¶
Multi-channel bonus: entities verified on three or more independent channels receive elevated trust consideration, as the probability of simultaneous compromise across independent platforms decreases multiplicatively.¶
IDD (Individual Device Derivate) entities MAY provide sovereign kernel attestations. A sovereign attestation binds an AINS Name to specific hardware through:¶
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.¶
Each AINS Registry MUST maintain a trust policy that defines how evidence is weighted to produce a trust score. The policy MUST be identified by a policy string (e.g., "humotica-fira-v1") and SHOULD be published at:¶
GET {prefix}/policy/{policy_id}
¶
Trust scores are computed locally. When a registry replicates records from a peer (see Section 8), it MUST:¶
This ensures that trust cannot be inflated by laundering scores through permissive registries.¶
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:¶
On success (HTTP 201):¶
{
"status": "registered",
"name": "new_agent",
"tier": "sandbox",
"verification_code": "ains-verify-a7f3b2c1e4d2f1..."
}
¶
Newly registered entities start at tier "sandbox" with a base trust score determined by the registry's policy (typically 0.5 or lower). To advance to "verified" tier, the entity MUST complete multi-channel verification (Section 6.3).¶
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 computes the new trust score based on verified channels and updates the entity's tier to "verified" if at least two channels are confirmed.¶
Registries MUST maintain a list of protected identifiers that cannot be registered through the normal registration flow. Protected identifiers include:¶
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.¶
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.¶
AINS registries federate through a signed append-only replication protocol. Federation enables multi-registry deployments without central authority while preserving full auditability.¶
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.nl",
"signature": "ed25519:base64..."
}
¶
Required fields per log entry:¶
Log entries MUST NOT be modified or deleted after creation. Deletions are recorded as tombstone entries with operation "DELETE".¶
Peer registries replicate records by pulling the change log:¶
GET {prefix}/changes?since={sequence}
¶
Response:¶
{
"issuer": "https://brein.example.nl",
"entries": [
{ "sequence": 1848, "..." : "..." },
{ "sequence": 1849, "..." : "..." }
],
"latest_sequence": 1849,
"issuer_public_key": "ed25519:base64..."
}
¶
Replicating registries MUST:¶
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.¶
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:¶
Cross-registry name reservation is out of scope for this document but is identified as future work.¶
Federation replicates EVIDENCE, not CONCLUSIONS.¶
When a registry replicates records from a peer, the trust evidence (Section 6.2) is preserved exactly as originated. However, the trust score is recomputed locally using the replicating registry's own policy.¶
This means the same entity MAY have different trust scores on different registries, even when based on identical evidence. This is correct and intentional. A high-security registry (e.g., financial services) MAY weight evidence differently than a social platform registry.¶
Registries MUST NOT federate their computed trust scores as if they were evidence. A trust score from registry A is an OPINION, not a FACT. Only the underlying evidence is factual.¶
Registries MAY provide Merkle inclusion proofs for their change logs, enabling third-party auditors to verify that:¶
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.¶
AINS Records SHOULD include a JIS [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 the initial trust context. The JIS trust score computed during FIR/A SHOULD be fed back to the AINS Registry as trust evidence of type "fira_session".¶
AINS Records MAY reference a TIBET [TIBET] chain anchor. This provides behavioral provenance:¶
{
"trust": {
"evidence": [
{
"type": "tibet_chain",
"chain_length": 14832,
"last_token": "tbt-9f3a2b",
"chain_anchor": "tbt-000001"
}
]
}
}
¶
A long TIBET chain with verified integrity is strong evidence of sustained, auditable operation. Registries SHOULD weight TIBET chain evidence proportionally to chain length and verification freshness.¶
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:¶
When a UPIP [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.¶
AINS Records are designed to be publicly resolvable, which creates inherent tension with privacy. Deployments MUST consider the following:¶
This document registers the following media type:¶
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:¶
Agent A wants to find an agent capable of "code-review" with trust score >= 0.7:¶
Agent A AINS Registry
| |
| GET /ains/v1/lookup |
| ?capability=code-review |
| &min_trust=0.7 |
|---------------------------------->|
| |
| 200 OK |
| { "agents": [ |
| { "name": "root_idd", |
| "trust_score": 0.95, |
| "capabilities": [...] } |
| ] } |
|<----------------------------------|
| |
| GET /ains/v1/resolve/root_idd |
|---------------------------------->|
| |
| 200 OK (full AINS Record) |
|<----------------------------------|
| |
| [JIS FIR/A handshake with |
| root_idd using endpoint from |
| AINS Record] |
|=================================>|
¶
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,| | | trust score | | | recomputed | | | by X's policy)| | |<----------------| |¶
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", "trust", "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
},
"trust": {
"type": "object",
"required": ["score", "evidence", "computed_at", "policy"],
"properties": {
"score": {
"type": "number",
"minimum": 0.0,
"maximum": 1.0
},
"evidence": {
"type": "array",
"items": { "type": "object" }
},
"computed_at": {
"type": "string",
"format": "date-time"
},
"policy": { "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" }
}
}
}
}
¶
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.¶