Every secure connection starts with a trusted identifier. It sounds like the proposed trusted identifier here is a domain name (example.com). The contents of the DNS record are validated from the DNS (presumably via DNSSEC) and participate in a chain of trust that reaches the later protocol stages.
Instead, I would encourage you to use an HTTP URL as your initial trusted identifier. It can serve a static resource (likely a JSON object) containing information about the location and configuration of all the available protocols for this identifier. This arrangement offers many advantages: * Not limited to one configuration per domain name. * Significantly easier to set up and maintain. * Much easier to secure (vs. DNSSEC). * No 64KB size limit * Improved privacy. * Flexible content-type negotiation. * More flexible and extensible syntax. * It can be extended to a domain name identifier if needed (via .well-known/). The standards-development action in this case would be to define a format (e.g. JSON key names) for this HTTP resource. It is true that this requires you to trust the HTTP infrastructure. However, that is also a requirement for most of the application protocols to which you want to dispatch, and setting up a trustworthy DNS zone may be equally challenging. If you want to pursue DNS-rooted object security for untrusted HTTP infrastructure, I would recommend splitting that into a separate proposal, perhaps using a new HTTPS record SvcParam. --Ben Schwartz On Tue, Mar 24, 2026 at 3:50 AM Balazs Nemethi <[email protected]> wrote: > Ben, Why not .well-known? AID publishes an Ed25519 public key in the DNS > record (the pka field) and uses RFC 9421 HTTP Message Signatures for > endpoint proof, same idea as DKIM. The verification material lives in DNS, > the challenge-response happens > > Ben, > > Why not .well-known? > > AID publishes an Ed25519 public key in the DNS record (the pka field) and > uses RFC 9421 HTTP Message Signatures for endpoint proof, same idea as > DKIM. The verification material lives in DNS, the challenge-response > happens over the application channel. You can’t get that from a .well-known > document attesting to itself. > > .well-known also assumes an HTTP server. A domain that hosts no website > can still publish an AID TXT record and advertise an agent endpoint. Some > AID endpoints aren’t HTTP origins at all: the protocol covers docker:, > npx:, and other local execution schemes. > > And the domain owner controls DNS independently of who runs the HTTP > infrastructure. If a SaaS platform hosts your agent, they control what > /.well-known serves. DNS keeps the authoritative statement with the domain > owner. > We do include a .well-known fallback (Appendix E) for environments where > DNS TXT creation is restricted, but it can’t be the primary path. > > > What is your URI scheme? > > AID doesn’t define one. The record tells you which application protocol to > speak (p= field: mcp, a2a, openapi, grpc, ws) and gives you the endpoint > URI (u= field: https://, wss://, docker:, etc.). The scheme varies by > what’s being discovered. A client looks up _agent.example.com > <https://urldefense.com/v3/__http://agent.example.com__;!!Bt8RZUm9aw!8E0_W5fu6Jq-iWQmWi4YlTPoRD0bkZhsU4gRt3tJ0cYWUqXmqG0iNioVV-Nv_yJUTPjp5UzBX59hlRWesQ$>, > gets back “speak MCP at https://api.example.com/mcp > <https://urldefense.com/v3/__https://api.example.com/mcp__;!!Bt8RZUm9aw!8E0_W5fu6Jq-iWQmWi4YlTPoRD0bkZhsU4gRt3tJ0cYWUqXmqG0iNioVV-Nv_yJUTPjp5UzBX5_E3rcGHA$>”, > and connects. > > > > Does that address both, or worth going deeper on either? > > Balazs > > On Tue, Mar 24, 2026 at 4:13 AM Ben Schwartz <bemasc= > [email protected]> wrote: > >> With SVCB, there are two common questions that seem relevant here: >> >> 1. Why not .well-known? >> >> If you are using a protocol built on top of HTTP (like several of the one >> you mentioned), then you likely don't need a new DNS record. You can learn >> information about an HTTP origin by checking its .well-known resources. >> (Then we can ask the question: why not just provide a full HTTP URL?) >> >> 2. What is your URI scheme? >> >> SVCB is designed principally for use with URIs. The URI scheme provides >> the underscore prefix label. So I would start by asking: what is the URI >> scheme? If there is more than one, then they should each have a separate >> SVCB record. >> >> --Ben >> >> On Wed, Mar 18, 2026 at 2:21 AM Balazs Nemethi <balazs= >> [email protected]> wrote: >> >>> Jan, Fair point. AID doesn't define "agent" because the term means >>> different things depending on the protocol (MCP servers, A2A agents, >>> OpenAPI services etc. ). What AID discovers is an endpoint that speaks one >>> of those protocols >>> Jan, >>> >>> Fair point. AID doesn't define "agent" because the term means different >>> things depending on the protocol (MCP servers, A2A agents, OpenAPI services >>> etc.). >>> What AID discovers is an endpoint that speaks one of those protocols >>> (and future protocols that will come around). On the wire it's a server, >>> but the AI ecosystem loosely calls them "agents" regardless. I'll tighten >>> the glossary in -01. Dave flagged the same thing. >>> >>> >>> >>> On Wed, Mar 18, 2026 at 1:02 AM Jan Schaumann <jschauma= >>> [email protected]> wrote: >>> >>>> Balazs Nemethi <[email protected]> wrote: >>>> >>>> > We submitted an Internet-Draft for Agent Identity & Discovery (AID) >>>> last >>>> > weekend: >>>> > >>>> > >>>> https://datatracker.ietf.org/doc/draft-nemethi-aid-agent-identity-discovery/ >>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-nemethi-aid-agent-identity-discovery/__;!!Bt8RZUm9aw!-IoNnGcJFtyGHGfRT0DIDUOgzlKl0HFpbqCS6-pbHuMuuy4cXa7EttCuU8vYBgOSmSYYTip3ocXTRNuiZxCttPJqGks$> >>>> > >>>> > AID does one thing: given a domain, find the agent endpoint and >>>> figure out >>>> > which protocol to speak. One TXT record at _agent.<domain>: >>>> >>>> I think the document could benefit from a very quick >>>> definition of "agent", "agent endpoint", and "agent >>>> service" (or a reference to where these are clearly >>>> defined). >>>> >>>> Not knowing what exact definition they might have, I >>>> can only interpret this to mean "special endpoints >>>> that AI driven bots could (should?) access", but it's >>>> not clear to me how those differ from other endpoints, >>>> or whether the "agent" acts as a client or a server >>>> (it sounds like "agents" are servers, but that >>>> conflicts with my current image of what an "agent" >>>> is or does). >>>> >>>> -Jan >>>> >>>> _______________________________________________ >>>> DNSOP mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>> >>> >>> -- >>> *Balazs Nemethi* >>> Founder, Agent Community >>> <https://urldefense.com/v3/__http://agentcommunity.org__;!!Bt8RZUm9aw!-IoNnGcJFtyGHGfRT0DIDUOgzlKl0HFpbqCS6-pbHuMuuy4cXa7EttCuU8vYBgOSmSYYTip3ocXTRNuiZxCtDnzC5Bo$> >>> >>> >>> _______________________________________________ >>> DNSOP mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
