Internet-Draft R. Raskar Intended status: Informational MIT Expires: 20 January 2027 S. Sharaf ProjectNanda P. Chari MIT 19 July 2026 Federated Resolution for AI Agent Discovery Using AI Catalog and NandaIndex draft-raskar-agentic-web-federated-resolution-00 Abstract Autonomous and semi-autonomous AI agents are published through multiple discovery mechanisms, including AI Catalog, DNS-based discovery, enterprise gateways, Agentic Resource Discovery (ARD) services, platform registries, A2A Agent Cards, MCP server descriptors, telecom directories, sovereign registries, and vertical-specific systems. This diversity is useful, but it creates discovery islands when a requester knows an identity but does not know which discovery mechanism is authoritative for that identity. This document defines a Federated Resolution Architecture that separates identity resolution from capability discovery. Resolution maps a stable subject identity to one or more discovery entry points. Discovery then retrieves resources through the selected mechanism. The architecture uses a conforming AI Catalog document as the response envelope and defines an agent-resolution-target JSON object for typed pointers to catalogs, DNS-AID organization indexes, ARD services, gateways, registries, hosted descriptors, and other resolution services. NandaIndex is described as a federated implementation of this architecture: a global switchboard of lightweight, authority-bound pointers. Direct enterprise discovery remains direct when an authoritative endpoint is already known. NandaIndex is used when the discovery mechanism is unknown, when multiple mechanisms coexist, or when small businesses, individuals, and emerging directories require a stable identity-to-discovery mapping without operating a unified enterprise stack. 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 20 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 the Pre-Submission Proposal 2. Conventions and Terminology 3. Architecture 3.1. Architectural Layers 3.2. Operational Flow 3.3. Direct and Federated Paths 3.4. Permissionless and Split Deployment 4. Federated 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. Loop Prevention and Failure 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. DNS-AID Method Object 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. Federation Context 7. Resolver Procedure 7.1. Domain Identities 7.2. Email Identities 7.3. DIDs, Platform Identities, and Registry 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 8.4. Individual Email Identity 8.5. ARD and AGNTCY-backed Discovery 8.6. Telecom, IoT, Sovereign, and Vertical Registries 9. Operational and Governance Considerations 9.1. Publishing a Binding 9.2. Node Behavior 9.3. Federation 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. Loops and Resource Exhaustion 10.6. Malicious Metadata and Prompt Injection 10.7. Authentication and Authorization 10.8. Compromise and Revocation 10.9. Federation Trust 11. Privacy Considerations 11.1. Identity Enumeration 11.2. Query Privacy 11.3. Data Minimization 11.4. Personal Agents and Consent 11.5. Cross-Jurisdiction Federation 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 is emerging as an Internet layer in which autonomous and semi-autonomous software agents discover, compose, and invoke capabilities across organizational and technical boundaries. Enterprises expose agents, tools, skills, data services, and gateways. Platforms and open-source communities operate registries and discovery APIs. Small businesses and individuals increasingly publish agents whose identity, descriptor, runtime, and hosting arrangements are controlled by different providers. Innovation naturally produces multiple discovery systems. Enterprises may prefer governed AI Catalogs or policy-aware gateways. Domain owners may use DNS-AID. Developer ecosystems may use platform registries. Telecom operators, IoT systems, national governments, and regulated sectors may operate their own directories. A2A [A2A] and MCP [MCP] define descriptors and invocation behavior for individual resources. Identity systems, including DIDs [DID-CORE], provide provenance and authentication. The existence of multiple mechanisms is not a coordination failure. The interoperability problem arises when a requester has a stable identity but cannot determine where discovery should begin. A client may know a domain, an email account, a URI, or another identifier but not whether it should fetch a well-known AI Catalog, query a DNS-AID organization index, call an ARD service, contact an enterprise gateway, consult a platform registry, or retrieve a hosted Agent Card. This document defines a bridge rather than a replacement. It introduces a resolution layer that maps subject identities to discovery systems. It profiles AI Catalog as the response envelope and defines a typed resolution-target object carried by a catalog entry. NandaIndex is one federated implementation of that layer. 1.1. Problem Statement Existing mechanisms answer different questions. AI Catalog represents heterogeneous AI resources. ARD searches those resources. Federated directories provide storage, routing, integrity, and governance. DNS-AID provides domain-rooted discovery. Gateways enforce authentication and policy. Agent Cards and server descriptors describe invocation. None of these, by itself, universally answers the prior question: given this subject identity, which discovery mechanism is authoritative or useful? Without a resolution layer, implementations hardcode endpoints, assume a single registry, enumerate proprietary connectors, or exclude actors who do not control enterprise infrastructure. These choices create fragile integrations and prevent capabilities from being composed across discovery islands. 1.2. Goals * Preserve direct, domain-controlled discovery where it already works. * Map stable subject identities to heterogeneous discovery mechanisms without requiring those mechanisms to adopt a common internal architecture. * Use a valid AI Catalog document and valid AI Catalog entries as the interoperable response envelope. * Keep the subject identity being resolved distinct from the identifier of the catalog entry that carries a resolution result. * Support enterprises, small and medium businesses, individuals, platform registries, telecom directories, IoT and EdgeAI systems, sovereign directories, and vertical registries. * Allow the runtime, Agent Card, brand domain, catalog, gateway, and resolution service to be operated by different parties. * Define an experimental HTTPS binding, resolver behavior, loop prevention, authority handling, caching, and security requirements for interoperable implementation. 1.3. Non-Goals * This document does not define a new agent invocation protocol. * This document does not replace AI Catalog, ARD, DNS-AID, A2A, MCP, AGNTCY ADS, enterprise gateways, or platform registries. * This document does not require a single global registry or root authority. * This document does not require target systems to use AI Catalog internally. Only the resolution response uses the AI Catalog envelope. * This document does not make intent-based capability search part of identity resolution. Intent is supplied to ARD or another discovery service after 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 that can be carried in an otherwise conforming entry. ARD [ARD] defines search and federation for agentic resources and uses the AI Catalog entry model. ARD answers capability and intent queries. This document answers the earlier identity-routing question and can return an ARD service as the selected discovery mechanism. DNS-AID [DNS-AID] defines DNS-based discovery using SVCB records. For a known organization, _index._agents. identifies an organization-specific agent index. A resolution target can direct a client to perform that DNS-AID query without representing DNS-AID as a JSON artifact format. A2A Agent Cards [A2A] and MCP server descriptors [MCP] are terminal artifacts that may be reached after resolution. AGNTCY ADS [ADS] and other directory systems may provide the infrastructure behind a resolution or discovery service. The NANDA Index and AgentFacts work [NANDA] and the joint NANDA-AGNTCY switchboard work [SWITCHBOARD] motivate the federated pointer architecture described here. 1.5. Changes from the Pre-Submission Proposal * Replaced mediaType with the AI Catalog type member and added a complete AI Catalog response envelope. * Required exactly one of url or data in every catalog entry. * Separated the lookup subject identity from the catalog-entry identifier. * Replaced the invented DNS-AID JSON media type with a generic agent-resolution-target object whose method can be dns-aid. * Aligned DNS-AID examples with _index._agents. and SVCB. * Separated architectural layers from the operational request flow. * Removed intent from identity resolution and placed intent-based queries in the downstream discovery step. * Added an experimental HTTPS binding and RFC 9457 problem details. * Replaced non-reserved example names with example domains. * Added current boilerplate, IANA registration text, precise references, and corrected end-matter order. 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, or other resource intended for machine discovery or invocation. Subject Identity The stable identity supplied to a Resolution Service, such as a domain, a local-name@domain agent identity, an email account, a URI, or a URN. It is not the identifier of the returned AI Catalog entry. Resolution The process of selecting where and how discovery should begin for a Subject Identity. Discovery The process of finding resources or capabilities through a selected mechanism, potentially using intent, filters, or search. Resolution Catalog A conforming AI Catalog document returned by a Resolution Service. 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 target method, target location, authority evidence, and lifecycle metadata. Resolution Service A service that accepts a Subject Identity and returns a Resolution Catalog. NandaIndex Node A federated Resolution Service implementing the NandaIndex profile described by this document. Direct Resolution Resolution using an already known authoritative catalog, DNS record, or gateway without consulting a NandaIndex node. Federated Resolution Resolution through one or more independently operated Resolution Services. Terminal Target A target that identifies a final descriptor, such as an A2A Agent Card or MCP server descriptor. Indirect Target A target that identifies another discovery or resolution mechanism, such as DNS-AID, ARD, a gateway, or another Resolution Service. Authority Evidence Evidence that an issuer is authorized to bind a Subject Identity to a target. Resolution Hop One transition from a Resolution Target Object to another resolution or discovery object. 3. Architecture 3.1. Architectural Layers The architecture contains four separable layers. These are architectural responsibilities, not a sequential request diagram. +----------------+ Describes resources and pointer artifacts | Representation | AI Catalog, Agent Cards, MCP descriptors +----------------+ +----------------+ Maps identity to a discovery entry point | Resolution | Direct methods, NandaIndex, other resolvers +----------------+ +----------------+ Finds capabilities within the selected system | Discovery | ARD, catalogs, gateways, registries +----------------+ +----------------+ Stores, routes, federates, validates, and governs | Infrastructure | ADS [ADS], DHTs, databases, logs +----------------+ 3.2. Operational Flow A request proceeds through a different, sequential flow: Subject Identity | v Resolution | v Discovery | v Verification and Authorization | v Invocation Resolution selects the discovery entry point. Discovery may then use an exact lookup, an ARD intent query, a catalog traversal, or a policy-filtered gateway request. Invocation occurs only after protocol-specific verification and authorization. 3.3. Direct and Federated 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. Federated resolution is useful when the mechanism is unknown, when a client begins from a non-domain identity, when multiple discovery systems coexist, or when a participant delegates descriptor hosting and runtime operation to other providers. 3.4. Permissionless and Split Deployment A Subject Identity, website, catalog, descriptor, runtime, and resolution 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 separate runtime. A sovereign or telecom registry may expose a single pointer into its native system without changing that system internally. 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. Federated Resolution Model 4.1. Resolution Input A resolution request contains one Subject Identity. The request MAY also constrain acceptable target methods, trust policy, locality, 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 resolution inputs in this profile. After a resolver obtains an ARD endpoint, catalog, or registry, it may submit an intent query to that downstream discovery service. 4.2. Resolution Output A successful Resolution Service response is a conforming AI Catalog document [AICATALOG]. The catalog host identifies the Resolution Service. Each returned entry is either a Resolution Entry as defined here or, when local policy explicitly permits, a terminal AI Catalog entry such as an A2A Agent Card entry. For uniform processing and authority binding, NandaIndex nodes SHOULD return Resolution Entries even for terminal targets. 4.3. NandaIndex Profile NandaIndex is a federated set of lightweight Resolution Services. Each node maps a Subject Identity to one or more authority-bound Resolution Target Objects. The target system remains authoritative for its own resources. Multiple nodes and multiple valid paths MAY coexist. NandaIndex(subject identity) -> AI Catalog response -> agent-resolution-target entry -> target discovery mechanism -> resource descriptor -> invocation 4.4. Target Classes artifact A terminal or nested artifact reachable by URL, including an AI Catalog, A2A Agent Card, or MCP server descriptor. dns-aid A DNS-AID SVCB query, normally an organization index at _index._agents.. ard An ARD-compatible search service. gateway An enterprise or policy gateway that performs controlled discovery. registry A platform, telecom, IoT, sovereign, or vertical registry using its native protocol. resolution-service Another Resolution Service, producing another Resolution Catalog. 4.5. Precedence and Multiple Results No universal precedence order is safe for every environment. A domain-controlled and cryptographically verified path is normally stronger for an organization-controlled domain identity than an unsigned third-party index entry. An email identity, however, cannot be authorized merely by the email provider's DNS. A resolver MUST evaluate the authority model appropriate to the identity type. When multiple valid targets exist, a resolver MAY return all, select one according to policy, or query several. 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 target to a weaker fallback. 4.6. Loop Prevention and Failure Resolvers and Resolution Services MUST prevent unbounded recursion. Each operation maintains a request identifier, hop limit, deadline, visited-service set, visited-target set, and maximum response size. The default maximum number of resolution hops is 8. Implementations SHOULD distinguish not-found, unauthorized, unverifiable, stale, unsupported-target, loop-detected, hop-limit, and policy-rejected outcomes. 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 Resolution Service. The following example is abbreviated: { "specVersion": "1.0", "host": { "displayName": "NandaIndex Example Node", "identifier": "did:web:nandaindex.example" }, "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 current AI Catalog and ARD specifications. The registration status of the air URN namespace is outside the scope of this document. { "identifier": "urn:air:nandaindex.example:resolution:moon-bakery-orders", "displayName": "Moon Bakery Orders Resolution", "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, registry, or another documented type. method REQUIRED. One of artifact, dns-aid, ard, gateway, registry, or resolution-service. targetType REQUIRED for artifact, ard, gateway, registry, and resolution-service methods. An IANA media type or documented protocol identifier describing the target. targetUrl REQUIRED for URL-based methods unless method-specific data supplies the target. It MUST be an absolute URI. dnsAid REQUIRED when method is dns-aid. Contains the SVCB query name and optional selection hints. 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 machine-readable or human-readable 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. DNS-AID Method Object When method is dns-aid, dnsAid MUST be an object containing queryName and rrtype. rrtype MUST be SVCB [RFC9460] for this version. A selector MAY identify a local agent name or service sought within the returned organization index. The query name for the known organization case is _index._agents. as defined by [DNS-AID]. "dnsAid": { "queryName": "_index._agents.skyblue-air.example", "rrtype": "SVCB", "selector": { "localName": "refunds" } } 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": "dns", "issuer": "did:web:moon-bakery.example", "evidenceUrl": "https://moon-bakery.example/.well-known/agent-binding.json", "evidenceDigest": "sha256:BASE64URLVALUE", "expiresAt": "2026-12-31T23:59:59Z" } A registry entry is not authoritative merely because a NandaIndex node 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 node 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 Resolution Service 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, acceptedMethods, and resolutionContext. It deliberately contains no intent field. A requester sends intent to the selected discovery service after resolution. POST /resolve HTTP/1.1 Host: resolver.nandaindex.example Content-Type: application/json Accept: application/ai-catalog+json { "identity": "orders@moon-bakery.example", "identityType": "agent-name", "maxResults": 10, "acceptedMethods": ["artifact", "ard", "gateway"], "resolutionContext": { "requestId": "01J2EXAMPLE9APQ", "hopLimit": 8, "deadline": "2026-07-17T18:00:10Z", "visitedServices": [] } } 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 methods the client can follow. resolutionContext is used for service-to-service federation and MUST NOT be trusted without local validation. 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 service MAY allow unauthenticated lookup of public bindings. Private, enterprise, sovereign, and regulated services MAY require HTTP authentication and authorization. Resolution authorization controls visibility of pointers; it does not authorize invocation of the resolved agent or service. 6.6. Federation Context A federating service decrements hopLimit before forwarding and adds its canonical service identifier to visitedServices. A service MUST reject a request if its own identifier is already present, hopLimit is zero, the deadline has expired, or local resource limits are exceeded. A service MAY omit or pseudonymize visitedServices when privacy policy forbids disclosure, provided equivalent local loop prevention remains in force. 7. Resolver Procedure 1. Accept one Subject Identity and local policy. 2. Normalize the identity without changing its semantics. 3. For a domain-based identity, attempt configured direct methods, including the well-known AI Catalog and DNS-AID, when policy permits. 4. If direct resolution produces an acceptable authoritative result, use it without requiring NandaIndex. 5. Otherwise query one or more Resolution Services. 6. Validate the AI Catalog envelope and every selected entry according to AI Catalog. 7. Validate the Resolution Target Object, Authority Evidence, freshness, and policy constraints. 8. Rank acceptable targets by authority strength, target method, locality, freshness, explicit priority, and local trust policy. 9. Follow the selected target. For an indirect target, repeat validation at the next hop. 10. Stop on a loop, hop limit, deadline, revocation, policy rejection, or unsupported method. 11. Return validated descriptors or discovery entry points. Perform intent-based discovery only after resolution. 12. Invoke only after protocol-specific authentication, authorization, consent, and safety checks. 7.1. Domain Identities For a domain identity or an agent-name identity rooted in an organizational domain, a resolver SHOULD prefer a validated domain-controlled source. It may first retrieve /.well-known/ai-catalog.json. It may also query the DNS-AID organization index at _index._agents.. A NandaIndex target can advertise either path but MUST NOT override a stronger authoritative domain binding without explicit policy. 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 alice@example.net. The proof SHOULD be time-bounded and revocable. 7.3. DIDs, Platform Identities, and Registry Identities For a DID, wallet, SPIFFE identity, platform account, telecom identity, sovereign identity, or vertical-registry 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. A fallback Resolution Entry MAY exist for visibility, migration, or clients that did not begin from the domain. 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 NandaIndex pointer makes that path visible to a client that begins from refunds@skyblue-air.example. { "identifier": "urn:air:nandaindex.example:resolution:skyblue-refunds", "displayName": "SkyBlue Refunds DNS-AID Resolution", "type": "application/agent-resolution-target+json", "data": { "subject": "refunds@skyblue-air.example", "subjectType": "agent-name", "method": "dns-aid", "dnsAid": { "queryName": "_index._agents.skyblue-air.example", "rrtype": "SVCB", "selector": { "localName": "refunds" } }, "authority": { "type": "dns", "issuer": "did:web:skyblue-air.example", "evidenceUrl": "https://skyblue-air.example/.well-known/agent-binding.json" } } } NandaIndex -> SVCB query for _index._agents.skyblue-air.example -> organization index or gateway -> select refunds resource -> verify, authorize, invoke 8.3. SMB with Split Hosting Moon Bakery owns moon-bakery.example but does not operate a public catalog or gateway. Its Agent Card is hosted by agenthost.example and its runtime is operated by a cloud provider. The domain owner issues a revocable binding to the hosted card. { "identifier": "urn:air:nandaindex.example:resolution:moon-bakery-orders", "displayName": "Moon Bakery Orders Resolution", "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": "dns", "issuer": "did:web:moon-bakery.example", "evidenceUrl": "https://moon-bakery.example/.well-known/agent-binding.json" }, "revocationUrl": "https://moon-bakery.example/agent-revocations.json" } } The switchboard record does not duplicate the runtime URL. The signed Agent Card remains authoritative for invocation metadata, avoiding inconsistent endpoint declarations. 8.4. Individual Email Identity Alice does not control example.net as a domain owner. A mailbox identity service verifies alice@example.net and issues a time-bounded credential authorizing a hosted personal Agent Card. { "identifier": "urn:air:nandaindex.example:resolution:alice-personal-agent", "displayName": "Alice Personal Agent Resolution", "type": "application/agent-resolution-target+json", "data": { "subject": "alice@example.net", "subjectType": "email", "method": "artifact", "targetType": "application/a2a-agent-card+json", "targetUrl": "https://cards.agenthost.example/personal/alice/card.json", "authority": { "type": "email-account", "issuer": "https://identity.example.net", "evidenceUrl": "https://identity.example.net/credentials/EXAMPLE", "expiresAt": "2026-10-17T00: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 Alice's consent or a valid delegated policy. 8.5. ARD and AGNTCY-backed Discovery A NandaIndex target can identify an ARD search service [ARD] backed by AGNTCY [AGNTCY] ADS [ADS] or another federated directory. Resolution finds the ARD endpoint. The requester then submits intent or capability filters to ARD. ADS provides storage, routing, integrity, and federation behind the service. Subject Identity -> NandaIndex -> ARD endpoint backed by ADS -> POST /search with intent or filters -> AI Catalog results -> descriptor -> invocation 8.6. Telecom, IoT, Sovereign, and Vertical Registries A target registry can remain native. It becomes reachable by publishing an authorized Resolution Entry that identifies its access method. The targetType and scope MUST be documented, and the authority object MUST identify the governing operator and jurisdiction. The switchboard does not require the target registry to adopt AI Catalog internally. 9. Operational and Governance Considerations 9.1. Publishing a Binding 1. Choose and normalize the Subject Identity. 2. Identify the 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 one or more NandaIndex nodes or publish it through an authorized federation path. 7. Publish validity, update, and revocation information. 8. Renew, migrate, or revoke the binding when authority or infrastructure changes. 9.2. Node Behavior A NandaIndex node 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 node MUST NOT represent a record as authoritative solely because the node accepted it. 9.3. Federation Nodes MAY exchange signed entries, referrals, or queries. Federation does not imply uniform governance. Each node may apply its own validation and publication policy. A resolver SHOULD know which node supplied an entry and what validation it performed. Transitive trust MUST be bounded. 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 Nodes 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 node or descriptor host. 10.2. Registry Poisoning and Squatting A malicious or compromised node can insert false targets, reserve brand-like names, or suppress legitimate records. Nodes 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 fallback. Resolvers must not silently downgrade from a validated source to an unsigned or lower-assurance target. 10.5. Loops and Resource Exhaustion Federation can create recursive loops, fan-out, oversized responses, and denial of service. Implementations must enforce hop limits, deadlines, visited sets, response limits, rate limits, 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 discovery path. 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 node can redirect traffic. Deployments should support rapid revocation, key rotation, short validity windows for high-risk bindings, and auditable change history. 10.9. Federation Trust A trusted node referral does not automatically make every downstream node trusted. A resolver should retain the full provenance chain and apply policy at each hop. 11. Privacy Considerations 11.1. Identity Enumeration Email identities, personal-agent names, and organizational roles can reveal sensitive information. Services 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. The POST binding avoids placing identities in URLs, but services still see request bodies. Implementations should minimize logs, retention, forwarding, and federation fan-out. 11.3. Data Minimization A switchboard entry should contain only what is needed to select a discovery path. Profiles, credentials, transaction history, and private capabilities should remain behind access-controlled services. 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. Cross-Jurisdiction Federation Sovereign and sector-specific directories may impose residency, retention, and disclosure requirements. Targets should identify jurisdictional constraints, and resolvers may reject paths that conflict 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 resolution services, catalogs, gateways, and federated indexes 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 and ARD specifications; 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. Target systems may remain native. ARD can be used after resolution for capability and intent search. DNS-AID is followed using SVCB semantics and the organization index name from the DNS-AID specification. A2A and MCP remain responsible for their own descriptors and invocation behavior. AGNTCY ADS [ADS] and other directory systems can provide federation infrastructure without becoming the sole global root. Implementers should expect referenced specifications to evolve. A Resolution Service SHOULD advertise supported versions and media types, preserve unknown AI Catalog extension fields, and reject unknown resolution-target methods unless explicit policy defines their behavior. 14. Conclusion The agentic web will continue to produce multiple discovery systems, formats, and governance models. The objective of this architecture is not to consolidate them into one system, but to prevent useful innovation from becoming permanently isolated. Federated resolution fills the gap between a stable identity and the discovery mechanism appropriate for that identity. AI Catalog provides the interoperable envelope, ARD can provide search, DNS-AID provides domain-rooted discovery, gateways and registries provide governed access, and NandaIndex provides a switchboard of authority-bound pointers. For enterprises with known authoritative endpoints, the direct path remains direct. For SMBs, individuals, and heterogeneous or emerging registries, a lightweight resolution binding provides global reachability while preserving local authority. The standardization goal is connectivity rather than uniformity. 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 [ARD] Bu, J., Guha, R.V., and S. Smith, "Agentic Resource Discovery Specification", Version 0.9, work in progress, 28 May 2026, . [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. [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS", RFC 9460, November 2023. [DID-CORE] W3C, "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022. [AGNTCY] AGNTCY Project, "AGNTCY: Internet of Agents", Linux Foundation, . [ADS] AGNTCY Project, "Agent Directory Service", open-source project, . [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. [SWITCHBOARD] Cisco Outshift and MIT, "Building a Switchboard for the Internet of Agents: Integrating AGNTCY Directory and NANDA Index", work in progress. Appendix A. Complete Resolution Catalog Example { "specVersion": "1.0", "host": { "displayName": "NandaIndex Example Node", "identifier": "did:web:nandaindex.example" }, "entries": [ { "identifier": "urn:air:nandaindex.example:resolution:moon-bakery-orders", "displayName": "Moon Bakery Orders Resolution", "type": "application/agent-resolution-target+json", "data": { "subject": "orders@moon-bakery.example", "method": "artifact", "targetType": "application/a2a-agent-card+json", "targetUrl": "https://cards.agenthost.example/moon-bakery/orders.json", "authority": { "type": "dns", "issuer": "did:web:moon-bakery.example", "evidenceUrl": "https://moon-bakery.example/agent-binding.json" }, "revocationUrl": "https://moon-bakery.example/agent-revocations.json" }, "updatedAt": "2026-07-17T18:00:00Z", "trustManifest": { "identity": "did:web:nandaindex.example", "identityType": "did" } } ] } Appendix B. Resolution Flow Summary Direct enterprise: domain -> well-known AI Catalog -> descriptor -> invocation DNS-AID enterprise: identity -> Resolution Entry -> _index._agents. SVCB -> organization index -> descriptor -> invocation SMB: identity -> Resolution Entry -> hosted Agent Card -> runtime Individual: account identity -> account-specific Authority Evidence -> Resolution Entry -> hosted Agent Card -> runtime ARD/ADS: identity -> Resolution Entry -> ARD service -> intent search -> AI Catalog result -> descriptor -> invocation Appendix C. Open Questions for Further Work * Whether the HTTP binding should become a separate Standards Track document. * A common credential format for domain, mailbox, platform, and sovereign Authority Evidence. * Privacy-preserving resolution and federation techniques. * Transparency logs and auditable recovery procedures. * Neutral extension names and version negotiation across AI Catalog revisions. * Operational governance for independently run NandaIndex nodes. * Conformance tests for Resolution Catalogs and target objects. Authors' Addresses Ramesh Raskar MIT Email: raskar@media.mit.edu Samuel Sharaf ProjectNanda Email: samuel.sharaf@gmail.com Pradyumna Chari MIT Email: pradyumna.chari4@gmail.com Acknowledgements This document is based on the NandaIndex Federated Resolution Architecture proposal and the earlier composable-discovery Internet-Draft structure. It recognizes the NANDA and AGNTCY collaboration, including work by Cisco Outshift and MIT Media Lab, as an early implementation of the global-switchboard concept. Additional contributors and co-authors are TBD.