Internet-Draft R. Raskar Intended status: Informational MIT Expires: 21 January 2027 S. Sharaf ProjectNanda P. Chari MIT 20 July 2026 Registry-Assisted Discovery for AI Agents and Workloads Without DNS Discovery Anchors draft-raskar-agentic-web-federated-resolution-01 Abstract Many agent-discovery mechanisms assume that an organization controls a DNS domain and can publish a DNS record, a well-known catalog, or an organization gateway. That model works well for enterprises with operational DNS infrastructure, but it does not cover every agent or workload. Small businesses may own a domain yet lack the expertise or infrastructure to publish agent-specific DNS records. Individuals may have a globally scoped account identifier, such as an email address, while not controlling the provider domain. Personal agents and other workloads may run on a cloud service or local device while their public descriptor is hosted elsewhere. This document describes registry-assisted discovery for these cases. A NandaIndex registry binds a stable Subject Identity to a subject-authorized terminal object, such as an A2A Agent Card, an MCP server descriptor, a workload descriptor, a subject-owned AI Catalog, or a subject-authorized gateway. The binding includes authority, freshness, and revocation information. The identity owner, descriptor host, and runtime operator may be different parties. This document does not define a directory of discovery servers, directory federation, or a global switchboard. A NandaIndex response does not direct a client to another generic resolution or discovery service. DNS-anchored systems remain direct: when an authoritative AI Catalog, DNS-AID record, or organization gateway is already known, NandaIndex is not in the critical path. The focus is permissionless publication and discovery for agents and workloads that do not have a usable DNS Discovery Anchor. Status of This Memo 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 21 January 2027. Copyright Notice 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. Table of Contents 1. Introduction 1.1. Problem Statement 1.2. Goals 1.3. Non-Goals 1.4. Relationship to Other Work 1.5. Changes from -00 2. Conventions and Terminology 3. Architecture 3.1. Architectural Layers 3.2. Operational Flow 3.3. Direct and Registry-Assisted Paths 3.4. Permissionless and Split Deployment 4. Registry-Assisted Resolution Model 4.1. Resolution Input 4.2. Resolution Output 4.3. NandaIndex Profile 4.4. Target Classes 4.5. Precedence and Multiple Results 4.6. Failure Handling 5. Data Model 5.1. AI Catalog Response Envelope 5.2. Resolution Entry 5.3. Resolution Target Object 5.4. Subject Identity Normalization 5.5. Allowed Method Values 5.6. Authority Evidence 5.7. Freshness, Caching, and Revocation 6. Experimental HTTPS Binding 6.1. Endpoint and Transport 6.2. Request 6.3. Successful Response 6.4. Error Response 6.5. Authentication and Authorization 6.6. No Inter-Registry Forwarding 7. Resolver Procedure 7.1. Domain-Associated Subjects Without DNS Publication 7.2. Email Identities 7.3. DIDs, Platform Identities, and Workload Identities 8. Deployment Contexts and Examples 8.1. Enterprise with a Well-Known AI Catalog 8.2. Enterprise Using DNS-AID 8.3. SMB with Split Hosting: Moon Bakery 8.4. Individual Personal Agent: John 8.5. Community and Project Workloads 8.6. Scope Boundary 9. Operational and Governance Considerations 9.1. Publishing a Binding 9.2. Registry Behavior 9.3. Registry Independence 9.4. Conflicts, Migration, and Recovery 9.5. Anti-Squatting 10. Security Considerations 10.1. Authority Confusion 10.2. Registry Poisoning and Squatting 10.3. Target Substitution 10.4. Downgrade Attacks 10.5. Resource Exhaustion 10.6. Malicious Metadata and Prompt Injection 10.7. Authentication and Authorization 10.8. Compromise and Revocation 10.9. Registry Trust 11. Privacy Considerations 11.1. Identity Enumeration 11.2. Query Privacy 11.3. Data Minimization 11.4. Personal Agents and Consent 11.5. Registry Jurisdiction 12. IANA Considerations 12.1. Media Type Registration 12.2. Other Names 13. Interoperability Considerations 14. Conclusion 15. References 15.1. Normative References 15.2. Informative References Appendix A. Complete Resolution Catalog Example Appendix B. Resolution Flow Summary Appendix C. Open Questions for Further Work 1. Introduction The agentic web includes software agents, tools, MCP servers, personal automations, and other machine-invocable workloads. Many discovery mechanisms are domain anchored: an organization controls a DNS domain and publishes a DNS record, a well-known catalog, or a gateway under that domain. These approaches are appropriate when the publisher operates the required domain infrastructure. Another class of publishers does not have a usable DNS Discovery Anchor. An SMB may own a brand domain but use managed hosting and have no practical means to publish DNS-AID records or an agent gateway. An individual may control a provider-managed email account but not the provider domain. A personal agent may run on a local Mac mini, a cloud service, or another runtime while its Agent Card is hosted by a third-party listing service. Community projects and temporary workloads may also have stable identifiers without dedicated DNS publication. Starting at Project NANDA, authors and implementers from multiple organizations have explored this problem for approximately 18 months [PROJECT-NANDA]. The work has produced papers and open-source prototypes, and a working NandaIndex implementation [NANDAINDEX] [NANDA-GITHUB]. Earlier work also explored a broader global-switchboard model [NANDA-SWITCHBOARD]. That directory-to-directory function is not specified by this revision. This document defines a narrower registry-assisted model. A publisher proves authority over a Subject Identity and registers a binding from that identity to a terminal descriptor, a subject-owned catalog, or a subject-authorized gateway. A resolver without a usable DNS-anchored path can query a configured registry and continue directly toward the subject's resource. 1.1. Problem Statement DNS-anchored discovery is not universally available. Requiring every publisher to control and operate DNS records, a well-known endpoint, or a gateway would exclude many legitimate agents and workloads. It would also unnecessarily couple public identity, descriptor hosting, and runtime deployment. The problem addressed here is: given a stable Subject Identity for an agent or workload without a usable DNS Discovery Anchor, how can a client obtain a current, authority-bound pointer to the subject's descriptor or gateway? The problem is not how one directory discovers another directory. It is also not global capability search. Those are separate questions with different operational and governance requirements. 1.2. Goals * Preserve direct, domain-controlled discovery where it already works, with NandaIndex outside the critical path. * Support small and medium businesses, individuals, community projects, and workloads that cannot or do not publish a DNS-anchored discovery record. * Use a valid AI Catalog document and valid AI Catalog entries as the interoperable response envelope. * Keep the Subject Identity distinct from the identifier of the catalog entry carrying the resolution result. * Allow the runtime, Agent Card, public identity, descriptor host, and registry to be operated by different parties. * Bind the Subject Identity to a terminal descriptor, subject-owned catalog, or subject-authorized gateway using verifiable Authority Evidence. * Define an experimental HTTPS binding, resolver behavior, authority handling, caching, revocation, and security requirements. 1.3. Non-Goals * This document does not define a directory of discovery servers, a global switchboard, or directory-to-directory routing. * This document does not define a new agent invocation protocol. * This document does not replace AI Catalog, DNS-AID, A2A, MCP, enterprise gateways, or platform registries. * This document does not require a single global registry or root authority. A client selects a registry using local configuration or deployment policy. * This document does not make intent-based or semantic capability search part of identity resolution. * This document does not define billing, settlement, agent reputation, task delegation, or execution authorization. 1.4. Relationship to Other Work AI Catalog [AICATALOG] defines a typed and nestable JSON catalog. A catalog contains specVersion, optional host information, and an entries array. Each entry has an identifier, displayName, type, and exactly one of url or data. This document does not change that structure. It defines a new artifact type carried in an otherwise conforming entry. DNS-AID [DNS-AID] defines DNS-based discovery using SVCB records. For a known organization, _index._agents. identifies an organization-specific agent index. This document does not alter or interpose on that path. When DNS-AID or another authoritative DNS-anchored path is known, a client uses it directly. A2A Agent Cards [A2A] and MCP server descriptors [MCP] are terminal objects that may be returned through a registry binding. The NANDA Index and AgentFacts work [NANDA] motivate identity-first publication for agents that cannot publish through DNS. Project NANDA materials, the NandaIndex implementation, and source code are available at [PROJECT-NANDA], [NANDAINDEX], and [NANDA-GITHUB]. The broader switchboard paper [NANDA-SWITCHBOARD] is informative background and is outside the protocol scope of this revision. 1.5. Changes from -00 * Changed the title and abstract to focus on agents and workloads without usable DNS Discovery Anchors. * Clarified that known AI Catalog, DNS-AID, and organization-gateway paths remain direct and do not require NandaIndex. * Removed directory federation, global-switchboard behavior, generic directory referrals, and directory-to-directory routing. * Limited registry results to terminal descriptors, subject-owned catalogs, and subject-authorized gateways. * Centered the examples on an SMB with split hosting, an individual personal agent, and community or project workloads. * Retained the AI Catalog envelope, typed target object, Authority Evidence, HTTPS binding, caching, revocation, security, and privacy mechanisms from -00. 2. Conventions and 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. Agentic Resource An agent, tool, skill, dataset, gateway, catalog, server, model, workload, or other resource intended for machine discovery or invocation. Subject Identity The stable identity supplied to a NandaIndex registry, such as a domain, a local-name@domain agent identity, an email account, a URI, a URN, a DID, or a platform identifier. It is not the identifier of the returned AI Catalog entry. DNS Discovery Anchor A usable discovery publication path operated under a controlled domain, such as DNS-AID, a well-known AI Catalog, or an organization gateway. A temporary domain-control challenge used only to authorize a registry binding is not itself a DNS Discovery Anchor. Registry-Assisted Resolution Resolution of a Subject Identity through a configured registry when a usable DNS Discovery Anchor is unavailable or not selected by policy. Resolution Catalog A conforming AI Catalog document returned by a registry. Resolution Entry An AI Catalog entry whose type is application/agent-resolution-target+json and whose data or referenced document is a Resolution Target Object. Resolution Target Object A JSON object that binds a Subject Identity to a terminal object or subject-authorized gateway, together with Authority Evidence and lifecycle metadata. NandaIndex Registry A registry implementing the profile defined by this document. Terminal Target An A2A Agent Card, MCP server descriptor, other documented workload descriptor, subject-owned AI Catalog, or subject-authorized gateway. Authority Evidence Evidence that an issuer is authorized to bind a Subject Identity to a target. 3. Architecture 3.1. Architectural Layers The architecture contains four separable responsibilities. These are architectural roles, not a sequential request diagram. +----------------+ Describes resources and binding artifacts | Representation | AI Catalog, Agent Cards, MCP descriptors +----------------+ +----------------+ Maps a Subject Identity to a terminal target | Resolution | Direct DNS paths or a configured registry +----------------+ +----------------+ Retrieves the selected descriptor or catalog | Discovery | Descriptors, subject-owned catalogs, gateways +----------------+ +----------------+ Stores, validates, updates, and revokes bindings | Infrastructure | NandaIndex registries, databases, audit logs +----------------+ 3.2. Operational Flow A request proceeds through the following sequential flow: Subject Identity | v Direct or Registry-Assisted Resolution | v Terminal Descriptor, Subject-Owned Catalog, or Gateway | v Verification and Authorization | v Invocation Resolution locates a subject-authorized object. Invocation occurs only after protocol-specific verification and authorization. 3.3. Direct and Registry-Assisted Paths When a requester already knows an authoritative discovery endpoint, it SHOULD use that endpoint directly. For example, a domain owner can publish an AI Catalog at https://example.com/.well-known/ai-catalog.json [RFC8615] or publish a DNS-AID organization index. NandaIndex is not required in that critical path. Registry-assisted resolution is used when the Subject Identity lacks a usable DNS Discovery Anchor, when a small publisher delegates descriptor hosting, or when an individual controls an account identifier but not the provider domain. 3.4. Permissionless and Split Deployment A Subject Identity, website, descriptor, runtime, and registry record need not be operated by the same party. An SMB may own a brand domain, delegate Agent Card hosting, and run its agent on a cloud provider. An individual may prove control of an email account while using a hosted descriptor and a separate local or cloud runtime. A community project may use a platform identity and a hosted workload descriptor. Resolvers MUST NOT equate the host of a target with the owner of the Subject Identity. Authority Evidence MUST bind the Subject Identity to the target or to an authorized publisher. 4. Registry-Assisted Resolution Model 4.1. Resolution Input A resolution request contains one Subject Identity. The request MAY constrain acceptable terminal target methods, trust policy, jurisdiction, and maximum results. It MUST NOT use a display name as the sole identity for an authority-sensitive lookup. Intent and capability search are not inputs in this profile. 4.2. Resolution Output A successful registry response is a conforming AI Catalog document [AICATALOG]. The catalog host identifies the registry. Each returned entry is a Resolution Entry as defined here or, when local policy explicitly permits, a terminal AI Catalog entry such as an A2A Agent Card entry. NandaIndex registries SHOULD return Resolution Entries so that the Subject Identity, target, Authority Evidence, freshness, and revocation information are carried together. 4.3. NandaIndex Profile A NandaIndex registry maps a Subject Identity to one or more authority-bound Resolution Target Objects. The registry is not a capability-search engine and does not recursively select another directory. Multiple independently operated registries MAY exist, but this document does not define communication among them. NandaIndex(subject identity) -> AI Catalog response -> agent-resolution-target entry -> terminal descriptor, subject-owned catalog, or gateway -> verification and invocation 4.4. Target Classes artifact A terminal object reachable by URL, including an A2A Agent Card, MCP server descriptor, other documented workload descriptor, or an AI Catalog controlled or explicitly authorized by the Subject Identity. gateway A gateway controlled or explicitly authorized by the Subject Identity that returns descriptors or performs policy-controlled access to subject resources. The method value MUST be artifact or gateway. A response MUST NOT use a DNS-AID referral, another registry, a generic discovery service, or another directory-server referral. Known DNS-AID and AI Catalog paths are followed directly under Section 3.3. 4.5. Precedence and Multiple Results No universal precedence order is safe for every environment. A validated direct DNS-anchored path is normally stronger for an organization-controlled identity than a registry binding. An email identity, however, cannot be authorized merely by the provider's DNS. A resolver MUST evaluate the authority model appropriate to the identity type. When multiple valid targets exist within a selected registry, a resolver MAY return all or select one according to policy. It SHOULD expose the selection reason and preserve provenance. Migration and fallback metadata are hints, not proof of authority. A resolver MUST NOT silently downgrade from a validated direct target to a weaker registry result. 4.6. Failure Handling Implementations SHOULD distinguish not-found, unauthorized, unverifiable, stale, unsupported-target, revoked, and policy-rejected outcomes. Requests and responses MUST be bounded by deadlines, maximum response sizes, rate limits, and local resource policy. 5. Data Model 5.1. AI Catalog Response Envelope A Resolution Catalog MUST conform to AI Catalog [AICATALOG]. It MUST contain specVersion and entries. The host object SHOULD identify the registry. The following example is abbreviated: { "specVersion": "1.0", "host": { "displayName": "NandaIndex Example Registry", "identifier": "urn:air:registry.example:host" }, "entries": [ ... ] } 5.2. Resolution Entry A Resolution Entry is an AI Catalog entry. It MUST contain identifier, displayName, type, and exactly one of url or data. Its type MUST be application/agent-resolution-target+json. If url is used, the referenced representation MUST be a Resolution Target Object. If data is used, data MUST contain the complete object. The entry identifier identifies the resolution artifact, not the Subject Identity. Examples follow the domain-anchored urn:air convention used by the current AI Catalog specification. The registration status of the air URN namespace is outside the scope of this document. { "identifier": "urn:air:registry.example:binding:moon-bakery-orders", "displayName": "Moon Bakery Orders Agent Binding", "type": "application/agent-resolution-target+json", "data": { ... }, "updatedAt": "2026-07-17T18:00:00Z" } 5.3. Resolution Target Object A Resolution Target Object is a JSON object with the following members: subject REQUIRED. The Subject Identity being resolved. subjectType REQUIRED. One of domain, agent-name, email, uri, urn, did, platform, workload, or another documented type. method REQUIRED. One of artifact or gateway. targetType REQUIRED. An IANA media type or documented protocol identifier describing the terminal object or gateway response. targetUrl REQUIRED. An absolute HTTPS URI for the descriptor, subject-owned catalog, or subject-authorized gateway. authority REQUIRED. Authority Evidence binding the subject to the target or publisher. priority OPTIONAL. An integer where lower values are preferred among targets with equivalent authority. scope OPTIONAL. A statement limiting the target to a service, role, jurisdiction, or audience. validFrom OPTIONAL. Timestamp in the format defined by [RFC3339] at which the binding becomes valid. expiresAt OPTIONAL. Timestamp in the format defined by [RFC3339] after which the binding is stale. revocationUrl OPTIONAL. URI at which revocation status can be checked. fallback OPTIONAL boolean. True identifies a fallback rather than the preferred binding. 5.4. Subject Identity Normalization * Domain names MUST be processed using applicable DNS and IDNA2008 rules and compared in canonical DNS form [RFC5890]. * For agent-name identities of the form local-name@authority-domain, the domain follows DNS canonicalization. The local-name is compared exactly unless an applicable profile defines another rule. * For email identities, the domain part follows DNS canonicalization. The local-part MUST NOT be case-folded unless the identity provider or an applicable profile defines that behavior. * URIs MUST be parsed and normalized only as permitted by [RFC3986]. Transformations that change the identified resource are prohibited. * URN comparison and normalization MUST follow [RFC8141] and namespace-specific rules. * A display name is not a Subject Identity and MUST NOT be used as the sole lookup key for an authority-sensitive operation. 5.5. Allowed Method Values The artifact method identifies a terminal descriptor or a catalog controlled or explicitly authorized by the Subject Identity. The gateway method identifies a subject-authorized gateway. Both methods use targetType and targetUrl. A registry response MUST NOT identify another registry, a generic discovery service, a DNS-AID referral, or another directory server. Such directory-to-directory behavior is outside scope of this document. 5.6. Authority Evidence The authority object MUST identify the authority type and issuer. It SHOULD provide an evidence URI or embedded evidence, an integrity digest when available, validity bounds, and revocation information. This document does not mandate one credential format. "authority": { "type": "https-domain-challenge", "issuer": "https://registry.example", "evidenceUrl": "https://moon-bakery.example/.well-known/proof.json", "evidenceDigest": "sha256:BASE64URLVALUE", "expiresAt": "2026-12-31T23:59:59Z" } A registry entry is not authoritative merely because a NandaIndex registry serves it. For domain identities, evidence can include DNS control, DNSSEC-backed records, a WebPKI-protected well-known resource, or another domain-authorized proof. For email identities, evidence must establish control of the account or authorization by an identity provider. Control of the provider domain does not establish control of an individual mailbox. The AI Catalog trustManifest MAY bind the Resolution Entry to the registry or publisher that issued it. That publication signature does not replace subject-specific Authority Evidence unless the trust manifest itself proves the subject binding. 5.7. Freshness, Caching, and Revocation Resolution Entries SHOULD include updatedAt and version fields. The Resolution Target Object SHOULD include validity and revocation metadata. HTTP responses SHOULD include cache-control information. Publishers SHOULD issue an updated binding when target, ownership, authority evidence, access policy, or lifecycle state changes. Resolvers MAY cache successful and negative results but MUST honor stricter revocation policy. Negative caching SHOULD be bounded because SMB and personal registrations may appear after an initial miss. A revoked or compromised target MUST NOT remain usable solely because a cache has not expired. 6. Experimental HTTPS Binding 6.1. Endpoint and Transport A NandaIndex registry implementing this binding uses HTTP semantics [RFC9110] and exposes POST /resolve relative to its configured base URI. HTTPS is REQUIRED for public deployments. The request uses application/json. A successful response uses application/ai-catalog+json. Errors use application/problem+json [RFC9457]. 6.2. Request The request object contains identity and identityType and MAY contain maxResults and acceptedMethods. It deliberately contains no intent field and no next-directory or forwarding context. POST /resolve HTTP/1.1 Host: registry.nandaindex.example Content-Type: application/json Accept: application/ai-catalog+json { "identity": "orders@moon-bakery.example", "identityType": "agent-name", "maxResults": 10, "acceptedMethods": ["artifact", "gateway"] } identity and identityType are REQUIRED. identityType disambiguates agent-name identities from email identities. maxResults defaults to 10 and MUST be between 1 and 100. acceptedMethods limits the terminal methods the client can follow. 6.3. Successful Response A successful response has status 200 and contains a Resolution Catalog. An empty entries array means that no acceptable binding is known. Status 404 is reserved for an unknown HTTP resource and MUST NOT be used to represent an unsuccessful identity lookup. 6.4. Error Response HTTP/1.1 422 Unprocessable Content Content-Type: application/problem+json { "type": "https://nandaindex.example/problems/unverifiable", "title": "Resolution binding is unverifiable", "status": 422, "detail": "Acceptable authority evidence was not provided.", "code": "unverifiable" } The code member SHOULD use one of the outcomes in Section 4.6. Services MUST NOT place secret credentials, full private identities, or sensitive policy details in an error response. 6.5. Authentication and Authorization A public registry MAY allow unauthenticated lookup of public bindings. Registration, update, suspension, recovery, and deletion endpoints MUST authenticate the registrant and validate Authority Evidence. Private deployments MAY require lookup authorization. Resolution identifies a target; it does not authorize invocation. 6.6. No Inter-Registry Forwarding This HTTPS binding does not define service-to-service forwarding, referrals, recursive lookup, harvesting, registry federation, or directory-to-directory queries. A client selects the registry it queries through local configuration or deployment policy. 7. Resolver Procedure 1. Accept one Subject Identity and local policy. 2. Normalize the identity without changing its semantics. 3. If a known authoritative DNS-anchored path is available and local policy selects it, use that path directly and do not query NandaIndex. 4. Otherwise query a configured NandaIndex registry. 5. Validate the AI Catalog envelope and every selected entry. 6. Validate the Resolution Target Object, Authority Evidence, freshness, revocation status, and policy constraints. 7. Reject any target method other than artifact or gateway. 8. Retrieve the terminal descriptor, subject-owned catalog, or subject-authorized gateway over an authenticated transport. 9. Invoke only after protocol-specific authentication, authorization, consent, and safety checks. 7.1. Domain-Associated Subjects Without DNS Publication A small business may control a domain but not operate DNS-AID, a well-known AI Catalog, or an organization gateway. A registry MAY validate domain association using an HTTPS challenge on the existing website, an ACME-like challenge, a registrar-backed assertion, or another policy-approved mechanism. A domain-associated registry binding is not stronger than a currently valid direct domain-authoritative record. If the subject later publishes a direct DNS-anchored path, local policy SHOULD prefer the direct path and MAY retain the registry binding only for migration or recovery. 7.2. Email Identities A mailbox identity is not controlled by the operator of the domain in the same sense as an organizational subdomain. The resolver MUST verify an account-specific proof or delegated identity-provider claim. DNS control of example.net does not by itself authorize an agent for john@example.net. The proof SHOULD be time-bounded and revocable. 7.3. DIDs, Platform Identities, and Workload Identities For a DID, wallet, SPIFFE identity, platform account, or workload identity, the resolver follows the lifecycle and verification rules of the governing identity system. The Resolution Target Object MUST identify the governing issuer and scope of authority. 8. Deployment Contexts and Examples 8.1. Enterprise with a Well-Known AI Catalog An enterprise publishes a conforming AI Catalog at https://acme.example/.well-known/ai-catalog.json. A requester that knows the domain retrieves it directly. NandaIndex is not in the critical path. Subject: acme.example Direct path: https://acme.example/.well-known/ai-catalog.json -> select resource -> verify descriptor -> authorize and invoke 8.2. Enterprise Using DNS-AID SkyBlue Air publishes an organization index through DNS-AID. A client that knows skyblue-air.example uses the DNS-AID path directly: skyblue-air.example -> _index._agents.skyblue-air.example SVCB -> organization index or gateway -> select resource -> verify, authorize, invoke NandaIndex is optional and is not in the critical path between known DNS-anchored systems. This document does not define a NandaIndex referral to DNS-AID. 8.3. SMB with Split Hosting: Moon Bakery Moon Bakery controls moon-bakery.example but uses managed hosting and does not deploy DNS-AID, a well-known AI Catalog, or an agent gateway. Its Agent Card is hosted by agenthost.example and its runtime is operated by a cloud provider. A registry validates the business's association with the domain and records a revocable binding to the Agent Card. { "identifier": "urn:air:registry.example:binding:moon-bakery-orders", "displayName": "Moon Bakery Orders Agent Binding", "type": "application/agent-resolution-target+json", "data": { "subject": "orders@moon-bakery.example", "subjectType": "agent-name", "method": "artifact", "targetType": "application/a2a-agent-card+json", "targetUrl": "https://cards.agenthost.example/moon-bakery/orders.json", "authority": { "type": "https-domain-challenge", "issuer": "https://registry.example", "evidenceUrl": "https://moon-bakery.example/.well-known/proof.json" }, "revocationUrl": "https://registry.example/revocations/moon-orders" } } The registry binding does not duplicate the runtime URL. The signed Agent Card remains authoritative for invocation metadata. 8.4. Individual Personal Agent: John John controls the mailbox john@example.net but does not control the provider-operated example.net domain. His personal agent may run on a cloud service or on a local computer, including an OpenClaw-style personal-agent runtime. A mailbox identity service verifies the account and authorizes a hosted Agent Card. { "identifier": "urn:air:registry.example:binding:john-personal-agent", "displayName": "John Personal Agent Binding", "type": "application/agent-resolution-target+json", "data": { "subject": "john@example.net", "subjectType": "email", "method": "artifact", "targetType": "application/a2a-agent-card+json", "targetUrl": "https://cards.agenthost.example/personal/john/card.json", "authority": { "type": "email-account", "issuer": "https://identity.example.net", "evidenceUrl": "https://identity.example.net/credentials/EXAMPLE", "expiresAt": "2026-10-20T00:00:00Z" } } } The resolver distinguishes account control, authorization to publish an agent under the account, control of the descriptor, and control of the runtime. Private actions still require John's consent or a valid delegated policy. 8.5. Community and Project Workloads A community project, hackathon team, or temporary workload may have a stable project or platform identifier but no dedicated domain. A registry can bind that identifier to a hosted MCP descriptor or workload card after verifying the project account or platform identity. The binding can expire automatically when the project ends. 8.6. Scope Boundary A registry response in this document terminates at a subject-owned or subject-authorized object. It does not point to another discovery service, telecom directory, sovereign registry, another NandaIndex registry, or a generic directory server. Those systems may exist independently, but directory-to-directory interoperability is outside this document. 9. Operational and Governance Considerations 9.1. Publishing a Binding 1. Choose and normalize the Subject Identity. 2. Identify the terminal target method and target location. 3. Obtain Authority Evidence appropriate to the identity. 4. Create a Resolution Target Object. 5. Wrap it in a conforming AI Catalog entry with a distinct entry identifier. 6. Submit it to a chosen NandaIndex registry. 7. Publish validity, update, and revocation information. 8. Renew, migrate, or revoke the binding when authority or infrastructure changes. 9.2. Registry Behavior A NandaIndex registry SHOULD validate schema, normalize the subject, verify Authority Evidence, record provenance, apply anti-abuse controls, expose update and revocation state, and disclose its validation policy. A registry MUST NOT represent a record as authoritative solely because it accepted the registration. 9.3. Registry Independence A client MAY select different registries through configuration or deployment policy. This document does not define query forwarding, record exchange, referrals, harvesting, or federation among registries. 9.4. Conflicts, Migration, and Recovery Multiple valid bindings may exist during migration or multi-provider operation. Bindings SHOULD include priority, validity windows, and fallback state. A recovery procedure SHOULD require evidence at least as strong as the evidence used for the existing authoritative binding. A registry administrator MUST NOT transfer a binding based only on a display name, brand claim, or unauthenticated support request. 9.5. Anti-Squatting Registries SHOULD reserve or quarantine names when authority is not yet proved, detect visually confusable identities, provide dispute mechanisms, and avoid first-come-first-served treatment of organization or account identities. A non-authoritative discovery hint MUST be clearly distinguished from an authoritative binding. 10. Security Considerations 10.1. Authority Confusion An attacker can publish a validly signed entry while lacking authority over the Subject Identity. Implementations must validate subject-specific Authority Evidence, not only the signature of the registry or descriptor host. 10.2. Registry Poisoning and Squatting A malicious or compromised registry can insert false targets, reserve brand-like names, or suppress legitimate records. Registries require anti-abuse controls, provenance, transparency, dispute handling, and independent verification. 10.3. Target Substitution A hosted descriptor or gateway can be replaced after registration. Authority Evidence should bind the target URI and, when possible, a digest or verification key. Resolvers must re-check revocation and freshness. 10.4. Downgrade Attacks An attacker can block an authoritative direct path and induce use of a weaker registry fallback. Resolvers must not silently downgrade from a validated source to an unsigned or lower-assurance target. 10.5. Resource Exhaustion Public lookup and registration endpoints can be abused for bulk enumeration, oversized requests, and denial of service. Registries must enforce deadlines, request and response limits, rate limits, authentication policy, and concurrency limits. 10.6. Malicious Metadata and Prompt Injection Descriptions and target documents are untrusted data. Clients must not treat catalog text as executable instructions, must isolate parsing from model prompts, and must validate all protocol-specific descriptors. 10.7. Authentication and Authorization Resolution identifies a target. It does not authorize access to metadata, execution, payment, data disclosure, or delegation. Every downstream protocol must perform its own authentication and authorization. 10.8. Compromise and Revocation A compromised authority, descriptor host, resolver, or registry can redirect traffic. Deployments should support rapid revocation, key rotation, short validity windows for high-risk bindings, and auditable change history. 10.9. Registry Trust Registry presence alone does not make a binding authoritative. A resolver should know which registry supplied an entry, which validation it performed, and which Subject Identity evidence supports the binding. 11. Privacy Considerations 11.1. Identity Enumeration Email identities, personal-agent names, and organizational roles can reveal sensitive information. Registries should limit bulk enumeration, apply rate limits, and avoid publishing more metadata than needed. 11.2. Query Privacy Resolution queries reveal relationships and planned actions. Resolvers should minimize query data, avoid unnecessary logging, use encrypted transport, and document retention policy. This profile does not require query fan-out. 11.3. Data Minimization A registry binding should contain only what is needed to locate and validate the terminal target. Rich profiles, personal attributes, transaction history, credentials, and private capabilities should remain behind access-controlled descriptors or gateways. 11.4. Personal Agents and Consent Account verification does not imply consent for every action. Public personal-agent records should be minimal, and private capabilities must require subject authorization or a valid delegated policy. 11.5. Registry Jurisdiction Registries may impose residency, retention, and disclosure requirements. A binding should identify jurisdictional constraints when relevant, and a resolver may reject a registry result that conflicts with local privacy policy. 12. IANA Considerations 12.1. Media Type Registration In accordance with [RFC6838], this document requests registration of the following media type in the "Media Types" registry: Type name: application Subtype name: agent-resolution-target+json Required parameters: none Optional parameters: none Encoding considerations: binary; the representation is UTF-8 JSON Security considerations: See Section 10 of this document Interoperability considerations: The representation follows [RFC8259], uses the +json suffix rules in [RFC6839], and follows the object model in Section 5.3 Published specification: This document Applications that use this media type: AI agent and workload registries, resolvers, gateways, and descriptor-hosting services Fragment identifier considerations: none Additional information: none Person and email address to contact: Ramesh Raskar, raskar@media.mit.edu Intended usage: COMMON Restrictions on usage: none Author: Ramesh Raskar Change controller: IETF 12.2. Other Names This document requests no well-known URI, HTTP field, DNS label, or URN namespace registration. The example urn:air identifiers follow the current AI Catalog convention; registration of that URN namespace is outside the scope of this document. 13. Interoperability Considerations AI Catalog conformance is mandatory for Resolution Catalogs and Resolution Entries. Terminal target systems remain governed by their own specifications. DNS-AID and known well-known AI Catalog paths are followed directly and are not mediated by this profile. A2A and MCP remain responsible for their own descriptors and invocation behavior. Implementers should expect referenced specifications to evolve. A registry SHOULD advertise supported versions and media types, preserve unknown AI Catalog extension fields, and reject unknown resolution-target method values. This profile does not define interoperability among registries. A client chooses a registry through local configuration, deployment policy, or an application-specific profile. 14. Conclusion DNS-anchored discovery is effective for organizations that control and operate the necessary domain infrastructure. It should remain direct. NandaIndex is not a required intermediary between a known AI Catalog, DNS-AID service, or organization gateway and its client. The remaining practical gap concerns agents and workloads without a usable DNS Discovery Anchor: small businesses with managed infrastructure, individuals with provider-managed account identifiers, personal agents running on local or cloud systems, and projects that delegate descriptor hosting. Registry-assisted discovery lets these publishers bind a stable identity to a terminal descriptor, subject-owned catalog, or subject-authorized gateway without requiring them to operate DNS discovery infrastructure. This revision deliberately does not specify a global switchboard or a directory of directory servers. Its narrower contribution is an authority-bound, revocable, and portable identity-to-object binding for permissionless participation in the agentic web. 15. References 15.1. Normative References [AICATALOG] Agent Card Working Group, "AI Catalog Specification", work in progress, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013. [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, January 2013. [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, April 2017. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017. [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", STD 97, RFC 9110, June 2022. [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, July 2023. 15.2. Informative References [DNS-AID] Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J. Damick, "DNS for AI Discovery", draft-mozleywilliams-dnsop-dnsaid-02, work in progress, May 2026. [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019. [DID-CORE] W3C, "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022. [A2A] Linux Foundation, "Agent2Agent Protocol", work in progress. [MCP] Model Context Protocol community, "Model Context Protocol", work in progress. [NANDA] Raskar, R., et al., "Beyond DNS: Unlocking the Internet of AI Agents via the NANDA Index and Verified AgentFacts", arXiv:2507.14263. [PROJECT-NANDA] Project NANDA, "Open Infrastructure for the Internet of AI Agents", . [NANDAINDEX] Project NANDA, "NandaIndex Working Implementation", . [NANDA-GITHUB] Project NANDA, "NandaIndex Version 2 Source Code", . [NANDA-SWITCHBOARD] Raskar, R., et al., "A Global Switchboard for the Agentic Web: Connecting Discovery Islands Across Enterprises, SMBs, and Individuals", MIT Media Lab, 2026. This reference describes broader experimental work outside the protocol scope of this revision. Appendix A. Complete Resolution Catalog Example { "specVersion": "1.0", "host": { "displayName": "NandaIndex Example Registry", "identifier": "urn:air:registry.example:host" }, "entries": [ { "identifier": "urn:air:registry.example:binding:moon-bakery-orders", "displayName": "Moon Bakery Orders Agent Binding", "type": "application/agent-resolution-target+json", "data": { "subject": "orders@moon-bakery.example", "subjectType": "agent-name", "method": "artifact", "targetType": "application/a2a-agent-card+json", "targetUrl": "https://cards.agenthost.example/moon-bakery/orders.json", "authority": { "type": "https-domain-challenge", "issuer": "https://registry.example", "evidenceUrl": "https://moon-bakery.example/.well-known/proof.json" }, "revocationUrl": "https://registry.example/revocations/moon-orders" }, "updatedAt": "2026-07-20T18:00:00Z", "trustManifest": { "identity": "https://registry.example", "identityType": "uri" } } ] } Appendix B. Resolution Flow Summary Direct enterprise: domain -> well-known AI Catalog -> descriptor -> invocation NandaIndex is not used. DNS-AID enterprise: domain -> _index._agents. SVCB -> organization index -> descriptor -> invocation NandaIndex is not used. SMB without DNS publication infrastructure: agent identity -> configured NandaIndex -> hosted Agent Card -> cloud or managed runtime Individual personal agent: email identity -> account-specific Authority Evidence -> configured NandaIndex -> hosted Agent Card -> local or cloud runtime Community workload: project identity -> configured NandaIndex -> MCP descriptor -> project workload Appendix C. Open Questions for Further Work * Whether the HTTP binding should become a separate Standards Track document. * A common credential format for domain-associated, mailbox, DID, platform, and workload Authority Evidence. * Privacy-preserving exact lookup and anti-enumeration techniques. * Transparency logs and auditable recovery procedures. * Neutral extension names and version negotiation across AI Catalog revisions. * Operational governance for independently selected registries. * Whether a future document should define registry interoperability. Such work is explicitly outside this revision. * Conformance tests for Resolution Catalogs and target objects. Acknowledgements This document draws on approximately 18 months of work by the Project NANDA community and contributors from multiple companies and institutions. It also benefits from work on AI Catalog, DNS-AID, A2A, MCP, identity systems, and workload security. Earlier NANDA and partner work explored a broader switchboard architecture; this revision intentionally narrows the protocol scope to agents and workloads without usable DNS Discovery Anchors. Authors' Addresses Ramesh Raskar MIT Media Lab 75 Amherst Street Cambridge, MA 02142 United States of America Email: raskar@media.mit.edu Samuel Sharaf ProjectNanda Email: samuel.sharaf@gmail.com Pradyumna Chari MIT Email: pradyumna.chari4@gmail.com