Registry-Assisted Resolution for Known Subjects Without DNS Discovery Anchors

1.1. 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.¶

1.2. 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 [DAWN-CHARTER] [DAWN-REQS] .¶

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.¶

1.3. 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.¶

1.4. 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.¶

1.5. Relationship to DNS-Based Discovery

The DAWN charter states that DNS and mDNS are mechanisms to consider when building a discovery protocol [DAWN-CHARTER] . DAWN work also proposes common parameters for DNS-based agent discovery [DAWN-DNS-PARAMS] .¶

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.¶

1.6. 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.¶

3.1. 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.¶

3.2. 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.¶

3.3. 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.¶

3.4. 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.¶

3.5. 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.¶

4.1. 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.¶

4.2. 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.¶

4.3. 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.¶

4.4. 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.¶

4.5. 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.¶

4.6. 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.¶

5.1. 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.¶

5.2. 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 [RFC3339] timestamp.¶

expiresAt REQUIRED. An [RFC3339] 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.¶

5.3. 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 [RFC3986] .¶

URNs MUST follow [RFC8141] and namespace-specific rules.¶

DID, platform, and workload identifiers MUST follow their governing specifications.¶

Normalization MUST NOT change the identified subject.¶

5.4. 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.¶

5.5. 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.¶

5.6. 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.¶

6.1. 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 [RFC9457] .¶

6.2. 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.¶

6.3. 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.¶

6.4. Error Response

Protocol errors use [RFC9457] .¶

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.¶

6.5. 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.¶

6.6. 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.¶

7.1. 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.¶

7.2. 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.¶

7.3. 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.¶

8.1. 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.¶

8.2. 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.¶

8.3. 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.¶

8.4. 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.¶

9.1. Registration Is Out of Scope

DAWN's initial scope excludes entity registration and identity management [DAWN-CHARTER] [DAWN-REQS] .¶

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.¶

9.2. 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.¶

9.3. 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.¶

9.4. 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.¶

10.1. 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.¶

10.2. 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.¶

10.3. 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.¶

10.4. 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.¶

10.5. 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.¶

10.6. 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.¶

10.7. 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.¶

11.1. 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.¶

11.2. 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.¶

11.3. 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.¶

11.4. 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.¶