MIT Media Lab

75 Amherst Street Cambridge MA 02142 United States of America raskar@mit.edu

ProjectNanda

samuel.sharaf@gmail.com

MIT

pradyumna.chari4@gmail.com

Internet DAWN AI agents agent discovery resolution registry DNS Discovery mechanisms for AI resources increasingly use DNS and mDNS as interoperable publication and lookup substrates. These mechanisms work well when the publisher controls a usable DNS discovery anchor. They do not cover every deployment. An individual may control an email or platform account without controlling the provider's DNS namespace. A small organization may use managed infrastructure without operating an agent-specific DNS publication point. A workload may have a stable identity that is not itself DNS anchored. This document describes Registry-Assisted Resolution for the narrower case in which a discovering entity already knows the Subject Identity it wants to resolve, but no usable DNS Discovery Anchor is available or selected by local policy. A configured registry returns the minimum information needed to continue discovery, together with provenance, authority evidence, freshness, and revocation information. This mechanism is complementary to DNS-based discovery. A validated direct DNS-anchored discovery path remains direct and is normally preferred for a domain-controlled subject. This document does not define open-ended search, semantic matchmaking, ranking, capability search, a global registry, registry discovery, directory-to-directory routing, identity management, or trust evaluation. Multiple independently operated registries may implement the same resolution profile. Registry selection is a client or deployment policy decision; no universal NandaIndex or global root is assumed. NandaIndex is described as one reference implementation of this model.

Introduction The Discovery of Agents With Names (DAWN) Working Group is chartered to specify interoperable mechanisms for the initial discovery of public properties of AI resources. The DAWN charter explicitly excludes open-ended search, semantic matchmaking, ranking, selection based on capability or user intent, broad identity management, and trust evaluation beyond secure discovery exchange . DNS and mDNS are important candidate mechanisms for DAWN. They are especially effective when a publisher controls an appropriate DNS namespace and can publish discovery data there. However, not every Named Entity or AI Resource that a client needs to resolve has a usable DNS Discovery Anchor. This document addresses one bounded case: the discovering entity already knows a stable Subject Identity, and it wants to obtain the minimum public information needed to continue discovery for that subject. If a usable direct DNS-anchored path exists, the client uses that path. If it does not, a configured registry may provide an authority-bound resolution target. The model is deliberately narrower than earlier "global switchboard" proposals. It does not ask a registry to discover the best agent for a task. It does not define a global search engine. It does not require all clients to use the same registry. It does not define registry-to-registry routing.

Problem Statement The problem addressed by this document is: Given a Subject Identity already known to the discovering entity, and no usable DNS Discovery Anchor for that subject, how can the discovering entity obtain current, integrity-protected, authority- bound information that allows the initial discovery process to continue? Examples include:

• a person identified by a provider-managed email or account identifier who does not control the provider's DNS namespace;
• a small organization that has a stable identity but delegates its agent descriptor hosting and does not operate the relevant DNS discovery records;
• a workload identified by a stable non-DNS identifier;
• a community or project identity whose descriptor is hosted by a separate service.

This document does not address how the discovering entity initially learns which subject it wants. Search, recommendation, semantic matchmaking, capability ranking, and intent-to-agent selection are separate functions.

Alignment with the DAWN Charter This document is intended to fit within the initial-discovery boundary described by the DAWN charter and emerging DAWN requirements . In particular:

• Resolution starts from a name or Subject Identity already known to the discovering entity.
• The response contains only the minimum information needed to continue discovery, plus integrity, authority, provenance, and freshness information needed to evaluate that response.
• The protocol does not carry free-form user intent and does not perform semantic matchmaking, capability search, ranking, or selection.
• The protocol does not define the lifecycle, governance, or registration process of an identity system.
• The protocol does not define how a subject proves identity during enrollment. It only defines how the resulting Authority Evidence is represented to and evaluated by a resolver.
• The protocol does not require a central registry. Multiple independent registries may exist, and an organization may continue to publish discovery information independently.
• Existing DNS or mDNS discovery mechanisms remain direct where they are available.
• The registry is a discovery service that can further the initial discovery process. It is not a general Internet-wide index.

This document does not claim Working Group adoption or consensus. It is an individual contribution describing one possible deployment mechanism.

Goals The goals of this revision are to:

• define a narrow resolution function for known subjects without a usable DNS Discovery Anchor;
• preserve direct DNS-based discovery where it works;
• define how a client selects one or more registries without assuming a global root;
• separate registry provenance from subject-specific authority;
• define freshness, expiry, revocation, and anti-replay behavior;
• reduce enumeration risk, especially for personal and provider-managed identities;
• support coexistence among independently operated registries without registry-to-registry recursive routing;
• return only the information needed to continue initial discovery.

Non-Goals This document does not define:

• open-ended Internet search;
• semantic matchmaking or natural-language intent matching;
• capability ranking or selection;
• a mandatory global registry or global NandaIndex root;
• a registry discovery protocol;
• registry-to-registry recursive forwarding or routing;
• a new naming system;
• identity enrollment or identity governance;
• trust or reputation scoring;
• agent invocation, task delegation, settlement, or execution;
• a public browse interface or capability marketplace.

Relationship to DNS-Based Discovery The DAWN charter states that DNS and mDNS are mechanisms to consider when building a discovery protocol . DAWN work also proposes common parameters for DNS-based agent discovery . Registry-Assisted Resolution is complementary to those mechanisms. A client that has a validated direct DNS-anchored discovery path SHOULD use it directly. A registry MUST NOT be inserted into that path merely because a registry also contains a record for the same subject. A temporary DNS challenge used to prove control of a domain during an out-of-scope enrollment process is not, by itself, a DNS Discovery Anchor. The distinction is between:

• DNS used as the operational discovery publication path; and
• DNS used only as one form of authority evidence.

Changes from -01 This revision makes the following major changes:

• Renames the mechanism from "Registry-Assisted Discovery" to "Registry-Assisted Resolution for Known Subjects" to make the search-versus-resolution boundary explicit.
• Aligns the scope directly with the approved DAWN charter and draft-king-dawn-requirements.
• Generalizes the normative protocol from "NandaIndex" to a generic registry-assisted resolution profile. NandaIndex is now a reference implementation rather than a required registry.
• Defines explicit resolver-selection rules and states that no universal registry or global root is assumed.
• Strengthens Authority Evidence by separating registry provenance from subject-to-target authority.
• Defines renewable bindings using sequence numbers, validity bounds, expiry, and revocation information.
• Requires support for exact-lookup operation without a public browse or enumeration interface.
• Makes personal and provider-managed identities non-enumerable by default within this profile.
• Defines coexistence of multiple registries without recursive registry-to-registry forwarding.
• Removes language implying permissionless global publication or global-switchboard behavior.
• Clarifies that registration and proof acquisition are outside the protocol scope, while verification of discovery information is in scope.

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 when, and only when, they appear in all capitals. This document uses DAWN terminology where applicable .

Subject Identity

A stable identifier for the Named Entity or AI Resource that the discovering entity already intends to resolve. Examples include a domain name, an agent name, an email or provider-managed account, URI, URN, DID, platform identifier, or workload identifier.

Known Subject

A subject whose Subject Identity is already known to the discovering entity before this resolution procedure begins. "Known" does not imply trusted, authenticated, or authorized.

DNS Discovery Anchor

A usable discovery publication path under a controlled DNS namespace, such as a DNS-based agent discovery record, a well-known discovery resource under an authoritative domain, or an organization-controlled gateway discoverable from that domain.

Registry-Assisted Resolution

Resolution of a Known Subject through a registry selected by client or deployment policy when no usable DNS Discovery Anchor is available or selected.

Resolution Registry

A service implementing the registry-assisted resolution profile defined by this document.

Resolution Target

A terminal discovery object or subject-authorized gateway returned by a Resolution Registry.

Authority Evidence

Evidence allowing a resolver to determine that an issuer was authorized to bind a Subject Identity to a Resolution Target.

Registry Provenance

Information establishing which registry supplied a response and the integrity of the response. Registry Provenance is not, by itself, proof that the subject authorized the target.

Renewable Binding

A time-bounded subject-to-target binding with a sequence number, validity interval, and revocation information.

Architecture Registry-Assisted Resolution is one possible mechanism within a larger discovery architecture. It is not intended to replace direct publication.

Direct DNS-Anchored Path For a subject with a validated DNS Discovery Anchor: Known Subject | v DNS / mDNS / well-known discovery | v Minimum Discovery Information or descriptor | v Subsequent protocol-specific interaction A Resolution Registry is not required in this path.

Registry-Assisted Path For a Known Subject without a usable DNS Discovery Anchor: Known Subject | v Client-selected Resolution Registry | v Authority-bound Resolution Target | v Minimum Discovery Information or descriptor | v Subsequent protocol-specific interaction Registry selection is not performed by the registry itself.

Mixed Deployments A deployment MAY combine direct DNS-based discovery and Registry-Assisted Resolution. For example, an enterprise policy may use DNS for organization-controlled subjects and a configured registry for provider-managed account identities. A registry MAY be reached through ordinary service configuration or through a deployment-specific bootstrap mechanism. This document does not standardize a registry-discovery protocol. A registry response MUST NOT recursively refer the client to another generic Resolution Registry.

Resolver Selection A client MUST select a Resolution Registry using local configuration, enterprise policy, application profile, identifier-method policy, or another explicitly configured mechanism. This document defines no universal default registry. A client configuration for a registry SHOULD include:

• the registry base URI;
• the registry's expected identity or trust anchor;
• the Subject Identity types for which it may be queried;
• local policy governing acceptable Authority Evidence;
• privacy policy, including whether query fan-out is permitted.

A client MAY be configured with an ordered set of registries. A client MAY query more than one configured registry if local policy permits, but it MUST NOT perform unbounded registry fan-out. Registry selection is a local policy decision and MUST NOT be inferred solely from a display name.

Multiple Registries Multiple independently operated registries MAY contain bindings for the same Subject Identity. No registry is authoritative merely because it is first in a global list, because it uses a particular brand name, or because it contains a record. A registry MUST identify itself in its response. A resolver MUST evaluate each returned binding using subject-specific Authority Evidence and freshness information. A registry MUST NOT claim exclusive control of a Subject Identity unless the underlying identity system provides such exclusivity and the claim is verifiable. This document does not define communication, synchronization, or routing among registries.

Resolution Model

Resolution Input A resolution request contains exactly one Subject Identity and its type. A request MAY include:

• accepted target types;
• maximum result count;
• a required freshness bound;
• an audience or deployment scope;
• policy hints that do not disclose sensitive information.

A request MUST NOT include free-form user intent for the purpose of semantic matching. A display name MUST NOT be the sole lookup key for an authority-sensitive resolution operation.

Resolution Output A successful response returns zero or more Resolution Target Objects. Each target MUST carry:

• the Subject Identity;
• the target type and target URI;
• Authority Evidence or a verifiable reference to it;
• Registry Provenance;
• a sequence number;
• an issuance time;
• an expiry time.

A response MAY include a revocation URI and a target digest. The response MUST NOT include another generic registry as the terminal resolution target.

Minimum Discovery Information The response is intended to carry only the minimum information needed to continue the DAWN initial-discovery process. This document does not define a capability taxonomy. A registry SHOULD return a reference to a terminal discovery object rather than duplicating rich capability metadata. Rich business metadata, reputation, user profiles, private capabilities, transaction history, credentials, and task-specific context are outside this profile. As DAWN converges on a common Minimum Discoverable Information (MDI) model, this profile SHOULD reuse that model rather than define a competing set of capability fields.

Terminal Target Classes A target is one of:

artifact

A terminal discovery representation reachable by URI, such as an Agent Card, MCP server descriptor, workload descriptor, or a subject-owned discovery catalog.

gateway

A subject-authorized gateway that returns minimum discovery information or a subject-specific descriptor under its own access policy.

A target MUST NOT be another generic Resolution Registry.

Precedence A validated direct DNS-anchored path SHOULD normally be preferred for a domain-controlled subject. That preference does not apply mechanically to provider-managed account identities. Control of the DNS zone for example.net does not prove control of alice@example.net. A resolver MUST evaluate authority according to the Subject Identity type. A resolver MUST NOT silently replace a currently valid, stronger direct binding with a weaker registry result. If multiple registry results are valid, local policy MAY select one or retain several. The resolver SHOULD expose the provenance and selection reason.

Failure Handling Implementations SHOULD distinguish:

• no-binding;
• unverifiable;
• stale;
• revoked;
• unsupported-target;
• policy-rejected;
• malformed-response.

Public exact-lookup endpoints SHOULD avoid creating unnecessarily different externally observable responses for "unknown identity" and "not publicly resolvable" when doing so would increase enumeration risk. Requests and responses MUST be bounded by timeouts, response-size limits, and resource policy.

Data Model

Resolution Response The experimental JSON response contains: { "registry": { ... Registry Provenance ... }, "subject": "alice@example.net", "subjectType": "email", "targets": [ ... Resolution Target Objects ... ] } An empty targets array indicates that the registry returns no public acceptable binding for the requested subject.

Resolution Target Object A Resolution Target Object has the following members: subject REQUIRED. The normalized Subject Identity. subjectType REQUIRED. A documented Subject Identity type. method REQUIRED. One of "artifact" or "gateway". targetType REQUIRED. A media type or documented protocol identifier. targetUrl REQUIRED. An absolute HTTPS URI. targetDigest OPTIONAL. An integrity digest for the referenced target. authority REQUIRED. Authority Evidence as described in Section 5.4. sequence REQUIRED. A non-negative integer monotonically increasing within the subject-authority scope for updates to the binding. issuedAt REQUIRED. An timestamp. expiresAt REQUIRED. An timestamp after which the binding MUST be treated as stale unless refreshed. revocationUrl OPTIONAL. A URI at which revocation status may be checked. scope OPTIONAL. A bounded audience, role, service, or deployment scope. fallback OPTIONAL boolean. True if the target is intended only as a fallback under local policy.

Subject Identity Normalization Domain names MUST be processed using applicable DNS and IDNA rules. For email identities, the domain part follows DNS canonicalization. The local-part MUST NOT be case-folded unless an applicable identity-provider profile defines that behavior. URIs MUST be normalized only as permitted by . URNs MUST follow and namespace-specific rules. DID, platform, and workload identifiers MUST follow their governing specifications. Normalization MUST NOT change the identified subject.

Authority Evidence The Authority Evidence object separates subject authority from registry provenance. The object SHOULD contain: type REQUIRED. The authority mechanism or credential type. issuer REQUIRED. The issuer or validating authority. evidenceUrl or evidence RECOMMENDED. A verifiable reference or embedded evidence. subject RECOMMENDED. The subject covered by the evidence when not implicit. targetUrl or targetDigest RECOMMENDED. A binding to the target or publisher when supported by the evidence format. validFrom OPTIONAL. expiresAt REQUIRED for time-bounded evidence unless the underlying evidence format has an equivalent validity rule. revocationUrl OPTIONAL. A registry signature proves Registry Provenance. It does not by itself establish that the subject authorized the target. Examples of subject-specific evidence include:

• DNS or WebPKI-backed domain control for domain identities;
• an account-provider assertion, mailbox challenge, or other account-specific proof for an email identity;
• a DID or wallet signature for a cryptographic identity;
• a platform-issued assertion for a platform account;
• an applicable workload identity credential.

The mechanism by which the publisher originally obtains the proof is outside the scope of this document. The resolution protocol is concerned with carrying enough information for the discovering entity to validate the discovery binding.

Freshness and Renewable Bindings A registry binding is a renewable lease, not a permanent claim. Every returned target MUST contain sequence, issuedAt, and expiresAt. A registry MUST NOT return a binding as current after expiresAt. A registry SHOULD require renewed Authority Evidence before extending a binding beyond the validity of that evidence. When a target, ownership state, authority evidence, or publisher changes, the sequence number MUST increase. A resolver that has multiple bindings from the same authority scope MUST reject an older sequence when it has already observed a newer valid sequence. A revoked binding MUST NOT remain usable solely because an HTTP cache lifetime has not expired. Negative caching SHOULD be short and policy bounded. Implementations SHOULD preserve sufficient audit information to diagnose replacement, recovery, and revocation events without exposing sensitive history through the public resolution API.

Provenance Registry Provenance SHOULD include:

• registry identifier;
• registry base URI;
• response issuance time;
• response signature or authenticated-transport identity;
• profile version.

Provenance allows a client to identify which configured registry supplied the result. It MUST NOT be interpreted as subject authority unless the authority model explicitly says so.

Experimental HTTPS Binding

Endpoint and Transport A Resolution Registry implementing this experimental binding exposes: POST /resolve relative to its configured base URI. HTTPS is REQUIRED for public deployments. Requests and responses use application/json. Errors use application/problem+json .

Request Example: POST /resolve HTTP/1.1 Host: registry.example Content-Type: application/json Accept: application/json { "identity": "alice@example.net", "identityType": "email", "maxResults": 3, "acceptedMethods": ["artifact", "gateway"] } identity and identityType are REQUIRED. maxResults defaults to 3 and MUST be between 1 and 100. acceptedMethods MAY constrain the target classes. The request MUST NOT contain an "intent", "capabilityQuery", "nextRegistry", or recursive forwarding field in this profile.

Successful Response A registry returns HTTP 200 for a syntactically valid lookup, including a lookup for which no public binding is returned. Example: { "registry": { "id": "https://registry.example", "profile": "known-subject-resolution-02", "issuedAt": "2026-10-28T20:00:00Z" }, "subject": "alice@example.net", "subjectType": "email", "targets": [] } Using the same status code for an empty public result and a populated result does not eliminate enumeration attacks, but it avoids one unnecessary distinction.

Error Response Protocol errors use . Example: HTTP/1.1 422 Unprocessable Content Content-Type: application/problem+json { "type": "https://registry.example/problems/unverifiable", "title": "Resolution binding is unverifiable", "status": 422, "code": "unverifiable" } Error responses MUST NOT expose secret credentials, private identity attributes, or internal policy details.

No Public Enumeration Requirement Conformance to this profile MUST NOT require a registry to expose:

• a list-all endpoint;
• keyword search;
• natural-language search;
• browse-by-category;
• prefix enumeration;
• downloadable identity catalogs.

A registry MUST support exact lookup without requiring any of those interfaces. Provider-managed personal identities SHOULD NOT be included in public browse or search interfaces by default. If a deployment separately offers public search or browsing, that function is outside this profile and MUST be clearly separable from the resolution endpoint.

No Inter-Registry Forwarding A Resolution Registry MUST NOT recursively query another Resolution Registry on behalf of the client under this profile. A response MUST NOT return another generic Resolution Registry as its Resolution Target. A client MAY independently query another registry from its configured registry set, subject to local privacy policy. This rule prevents a client-selected registry model from silently becoming a global registry-routing system.

Resolver Procedure A resolver performs the following procedure:

1. Accept one Known Subject and local policy.
2. Normalize the Subject Identity without changing its semantics.
3. Determine whether local policy has a validated, direct DNS-anchored discovery procedure for this Subject Identity type.
4. If such a direct path exists and is selected, use it directly.
5. Otherwise select a Resolution Registry from local configuration or policy.
6. Send an exact resolution request.
7. Validate Registry Provenance.
8. Validate each candidate's Subject Identity, Authority Evidence, target binding, sequence, expiry, revocation status, and local policy.
9. Reject unknown target methods and expired or revoked bindings.
10. Retrieve the terminal discovery object over an authenticated transport.
11. Continue any subsequent authentication, authorization, capability exchange, or invocation under the specification governing that target. Those actions are outside this profile.

Domain-Controlled Subjects For a domain-controlled subject, a currently valid direct DNS-based discovery record is normally stronger than a registry binding because it is published under the subject's authoritative namespace. A registry binding MAY be useful when the subject does not publish the relevant discovery data in DNS or delegates descriptor hosting. If a direct path later becomes available, policy SHOULD normally prefer it.

Email and Provider-Managed Accounts The operator of a provider domain does not automatically speak for every individual account in that namespace. For example, DNS control of example.net does not alone prove that a particular agent is authorized for alice@example.net. Authority Evidence for a provider-managed identity MUST be account-specific or be issued under an identity-provider delegation model that explicitly covers the account. Such evidence SHOULD be time bounded and revocable.

DIDs, Platform Identities, and Workload Identities For a DID, wallet, platform account, SPIFFE identity, or other workload identity, the resolver follows the verification and lifecycle rules of the governing identity system. The registry MUST NOT redefine the identity system's authority model.

Deployment Examples

Enterprise with Direct DNS Discovery Example Corp controls example.com and publishes a DAWN-compatible DNS discovery record. example.com | v authoritative DNS discovery | v descriptor / MDI The registry-assisted mechanism is not used.

SMB Without a Usable DNS Discovery Anchor Moon Bakery uses moon-bakery.example as its public identity but relies on managed hosting and does not operate the relevant discovery records. Its Agent Card is hosted by agenthost.example. A configured registry returns: { "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", "sequence": 8, "issuedAt": "2026-10-28T19:00:00Z", "expiresAt": "2026-10-29T19:00:00Z", "authority": { "type": "domain-control", "issuer": "https://registry.example", "evidenceUrl": "https://moon-bakery.example/.well-known/example-proof" } } The registry proves the binding; it does not become the runtime.

Individual Personal Agent Alice controls alice@example.net but does not control example.net DNS. A provider-specific or mailbox-specific proof authorizes her personal agent descriptor. alice@example.net | v configured registry | v account-specific Authority Evidence | v Agent Card | v local or cloud runtime Alice's identity is resolved by exact lookup. It need not appear in a public browse interface.

Multiple Independent Registries A client is configured with Registry A and Registry B. Both contain a binding for the same Subject Identity. The client verifies both independently. It does not assume that one registry is a global root, and neither registry forwards the request to the other. Local policy may select the result with acceptable Authority Evidence and freshness, retain both for resilience, or reject both.

Operational Considerations

Registration Is Out of Scope DAWN's initial scope excludes entity registration and identity management . Accordingly, this document does not standardize account creation, challenge issuance, proof acquisition, registrant recovery, or governance of an identity namespace. A registry implementation necessarily performs enrollment and lifecycle operations, but those operations are outside the resolution protocol defined here. What is in scope is that the resolution response carry enough integrity, provenance, authority, and freshness information for the discovering entity to evaluate the discovery result.

Anti-Squatting A registry MUST NOT treat first registration as sufficient authority. A pending or unverified registration MUST NOT block a later registrant that presents valid authority evidence under the registry's policy. Resolver clients MUST NOT treat registry presence alone as proof of ownership.

Migration and Recovery A subject may migrate its descriptor or runtime without changing its Subject Identity. The binding sequence MUST increase when the resolution target changes. Recovery of a subject binding SHOULD require evidence at least as strong as the evidence used for the previous valid binding, subject to the governing identity system. A registry MAY retain non-public audit history or tombstones to prevent immediate reassignment after withdrawal, subject to privacy and retention policy.

Registry Independence Registries are independently operated. A registry MAY apply its own enrollment, evidence, jurisdiction, retention, and abuse policies. Interoperability depends on the common resolution representation and resolver behavior, not on shared registry governance.

Security Considerations

Authority Confusion The most important security property is distinguishing:

• the identity of the registry;
• the Subject Identity;
• the authority that validates the subject;
• the host of the descriptor;
• the runtime operator.

These may all be different parties. Implementations MUST NOT infer subject authority from descriptor hosting or registry hosting alone.

Registry Poisoning and Squatting A malicious registrant may attempt to bind another subject to an attacker-controlled descriptor. Registries MUST validate authority before publishing a current binding. Resolvers MUST evaluate the Authority Evidence rather than trusting registry presence alone.

Target Substitution An attacker may replace a target after authority was verified. Authority Evidence SHOULD bind the subject to the target URI, target digest, authorized publisher, or another object from which the target is securely derived.

Downgrade Attacks An attacker may try to suppress a stronger direct DNS path and force a client onto a weaker registry result. A resolver MUST NOT silently downgrade from a validated direct path to a weaker registry result.

Replay and Stale Bindings An attacker may replay a previously valid binding. Sequence numbers, validity bounds, expiry, and revocation checks are therefore required. HTTP cache freshness MUST NOT override subject-level revocation or expiry.

Resource Exhaustion Exact lookup endpoints are attractive denial-of-service and scraping targets. Registries SHOULD use rate limiting, request-size limits, deadlines, abuse detection, and bounded result sets. Clients MUST NOT perform unbounded registry fan-out.

Registry Trust A configured registry is trusted to operate the protocol correctly and to preserve response integrity. It is not automatically trusted to make arbitrary claims about a subject. Subject-specific Authority Evidence remains necessary.

Privacy Considerations

Exact Lookup and Enumeration A major difference between resolution and search is that resolution can operate without exposing the entire set of registered subjects. This profile therefore requires support for exact lookup and does not require listing or browsing. Personal and provider-managed account identities SHOULD be hidden from public enumeration by default. Public search or browsing, if provided by the same implementation, is a separate function outside this profile. Rate limiting and uniform response behavior can reduce simple enumeration but do not eliminate it. Privacy-preserving exact-lookup mechanisms are an area for future work.

Query Privacy Resolution queries can reveal relationships, planned interactions, or sensitive identities. Clients SHOULD avoid unnecessary query fan-out. Registries SHOULD minimize logs, document retention policy, protect transport confidentiality, and avoid logging secrets.

Data Minimization A resolution record SHOULD contain only the information needed to find and validate the terminal discovery target. Rich profiles, personal attributes, transaction history, private capability descriptions, and credentials SHOULD NOT be included.

Personal Agents Verification that a person controls an account does not imply consent for all actions by or toward the person's agent. Resolution identifies a discovery target. It does not authorize invocation, disclosure of private capabilities, or transactions.

IANA Considerations This revision requests no new DNS label, well-known URI, registry root, or URN namespace. The media type application/agent-resolution-target+json proposed in -01 remains experimental in this revision. A future Standards Track version may request formal registration if the DAWN architecture adopts a dedicated representation rather than a common MDI object.

Interoperability Considerations The registry-assisted path SHOULD converge on the same DAWN minimum discovery semantics as direct DNS-based mechanisms. This document deliberately avoids defining a parallel capability model. As common DAWN discovery parameters and MDI definitions stabilize, implementations SHOULD map registry outputs to those common fields. Terminal Agent Card, MCP, workload, or other descriptors remain governed by their own specifications. This document does not define interoperability among registries beyond the fact that multiple registries may expose the same resolution profile to clients.

NandaIndex as a Reference Implementation Project NANDA operates NandaIndex as an experimental implementation of agent resolution and discovery concepts . For the model in this revision, NandaIndex is best understood as one possible Resolution Registry, not as a mandatory global root. To implement this profile, a NandaIndex deployment should:

• expose exact resolution independently of public search or browse;
• keep direct DNS-anchored discovery outside the NandaIndex critical path where possible;
• require subject-specific authority evidence;
• publish expiry, sequence, provenance, and revocation information;
• make personal records non-enumerable by default;
• avoid recursive registry-to-registry forwarding;
• permit clients to choose other compatible registries.

Natural-language discovery, public browsing, capability search, and marketplace functions may exist as separate Project NANDA experimentation, but they are not part of the registry-assisted resolution profile described here.

Conclusion DNS and mDNS are strong foundations for AI-resource discovery when the subject controls a usable discovery publication point. A narrower gap remains for a Known Subject whose identity is stable but whose discovery information cannot be published through a usable DNS Discovery Anchor. Registry-Assisted Resolution fills that gap without requiring a global index. The client starts with a Known Subject, selects a registry by local policy, validates subject-specific authority and freshness, and receives only the minimum information needed to continue discovery. The design preserves four important boundaries:

• DNS remains direct where it works;
• resolution is distinct from open-ended search;
• registry provenance is distinct from subject authority;
• multiple registries coexist without registry-to-registry routing.

This makes registry-assisted resolution a complementary discovery mechanism rather than an alternative global naming or search system.

Normative References Informative References

Example Resolution Response POST /resolve { "identity": "alice@example.net", "identityType": "email", "maxResults": 2, "acceptedMethods": ["artifact"] } 200 OK { "registry": { "id": "https://registry.example", "profile": "known-subject-resolution-02", "issuedAt": "2026-10-28T20:00:00Z" }, "subject": "alice@example.net", "subjectType": "email", "targets": [ { "subject": "alice@example.net", "subjectType": "email", "method": "artifact", "targetType": "application/a2a-agent-card+json", "targetUrl": "https://cards.agenthost.example/alice/card.json", "targetDigest": "sha256:BASE64URLVALUE", "sequence": 14, "issuedAt": "2026-10-28T19:00:00Z", "expiresAt": "2026-10-29T19:00:00Z", "authority": { "type": "account-provider-assertion", "issuer": "https://identity.example.net", "evidenceUrl": "https://identity.example.net/evidence/EXAMPLE", "expiresAt": "2026-10-29T19:00:00Z" }, "revocationUrl": "https://registry.example/revocations/alice-14" } ] }

DAWN Requirements Mapping The following non-normative mapping explains how this mechanism is intended to relate to current DAWN requirements. Known starting point: The Subject Identity is already known before resolution. Referral / directory: The configured registry is a bounded discovery service that furthers discovery for the known subject. Minimum information: The response carries a target pointer and the security/lifecycle information needed to validate it, rather than a capability catalog. Decentralization: No single registry is required. Clients select registries by configuration or policy. Independent publication: Subjects with direct DNS publication remain independent of registries and are resolved directly. Existing protocols: DNS/mDNS are reused where applicable. HTTPS is used for the registry-assisted gap. Integrity: Registry Provenance protects the response, while Authority Evidence binds the subject to the target. Privacy: Exact lookup is supported without public enumeration. Scope boundary: Search, ranking, semantic matchmaking, identity management, and trust evaluation are not part of this profile.

Open Questions

• Whether the generic registry-assisted mechanism belongs in a DAWN Architecture document, a use-case document, or a separate protocol specification.
• Whether DAWN MDI can directly represent all fields needed for the Resolution Target Object, eliminating a dedicated target media type.
• Which authority-evidence formats should be standardized or profiled for email, platform, DID, and workload identities.
• Whether privacy-preserving exact lookup techniques such as OPRF- or PIR-based designs are warranted for personal-agent deployments.
• How registry selection should be profiled for specific identity methods without creating a universal registry-discovery system.
• Whether a transparency mechanism is useful for detecting conflicting or malicious bindings without creating a public enumeration surface.
• How conformance tests should verify non-enumerability, freshness, and no-forwarding behavior.

Acknowledgements This document draws on work by the Project NANDA community and on discussions in the IETF DAWN community concerning discovery scope, DNS-based discovery, referrals, identity boundaries, authority, freshness, privacy, and enumeration. Earlier Project NANDA work explored a broader global-switchboard model. This revision intentionally narrows the protocol contribution to resolution of Known Subjects without usable DNS Discovery Anchors.