“Earlier this year, I wrote a series of posts about discovery. I started with a fairly broad observation: discovery is bigger than just finding something.”

When a system needs to find an identity provider, a credential, an account, a service, a tool, or an AI agent, the interesting question is rarely just “where is it?” Which isn’t to say that isn’t an important problem; it is. But discovery also raises questions about what information is available, who gets to see it, how much confidence you should place in what you find, and what happens once discovery succeeds.

By the end of that series, I was arguing that choosing a discovery mechanism is often the wrong place to start. DNS, .well-known URIs, registries, catalogs, and other infrastructure can all be perfectly reasonable answers, but only after we have agreed on what kind of discovery problem we are solving.

AI agents are turning out to be a particularly useful test case for that argument.

There are now several standards and industry groups talking about agent discovery, identity, capabilities, communication, authorization, delegation, and related problems. I am not going to try to inventory all of them here. Instead, I want to look at two efforts that approach the discovery problem from noticeably different directions: the W3C AI Agent Protocol Community Group and the IETF’s proposed Discovery of Agents With Names (DAWN) Working Group.

They overlap, but they are very much not the same thing.

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

One problem, two very different scopes

The W3C AI Agent Protocol Community Group has an ambitious mission. It wants to develop protocols allowing agents to discover, identify, and collaborate with each other across the Web. Discovery is only part of that agenda.

The group’s scope also includes inter-agent communication; exchanging intent and capability information; negotiating roles, agent identity, authentication, and authorization; structured descriptions of agent capabilities and interfaces; security and privacy; verifiable credentials; encryption; and interoperability with existing Web standards.

There is a lot there. And, honestly, those are many of the reasons agentic AI is architecturally interesting.

It is not especially difficult to imagine software calling another piece of software. We have been doing that for a very long time. Things become much more interesting when the software needs to determine what other actors exist, what they can do, who operates them, what authority they have, whether they can be trusted for a particular purpose, and what they are permitted to do once an interaction begins.

The Agent Protocol work is attempting to take on a considerable portion of that problem space.

DAWN is taking almost the opposite approach.

Its proposed charter describes a much narrower question: how can a client discover public information about an AI resource so that some later interaction can take place?

That includes things such as the resource’s type, how it can be reached, what communication protocol it supports, and what services it exposes. Discovery may involve referrals, delegation, indirection, or movement across administrative boundaries. The group is also expected to consider different discovery environments, from local settings through organizations and out across cooperating organizations on the public Internet.

And then DAWN stops.

Its proposed charter explicitly puts broader capability catalogs, communication after discovery, Internet-wide search and indexing, AI agent identity management, and broader trust management outside its initial scope. That restraint may be the most important difference between the two efforts.

Where they overlap

The clearest overlap is the bootstrap problem. Imagine that I know something about the environment I am operating in—a domain, an organization, perhaps a local network—but I do not already know the endpoint for the agent or resource I need. How do I find it?

Both groups need an answer to that question.

The Agent Protocol work treats discovery as part of a larger agent architecture. Its current work includes descriptions of agents, their capabilities and interfaces, and mechanisms for locating them on the Web. The group’s overall model then continues from discovery into identification and interaction.

DAWN is concentrating on that first step. Its charter calls for an interoperable, generic discovery mechanism built where possible on existing protocols, established trust models, and existing delegation and federation architectures. It also asks the group to define the minimum information that needs to be available publicly for discovery to work.

This creates a potentially useful layering model.

DAWN could answer: Where is the resource, and how do I begin an interaction with it?

Something like Agent Protocol could then answer: What is this agent, what can it do, how does it identify itself, and how do we work together?

That would be a fairly clean separation of concerns, but whether that is where the work ends up remains to be seen.

Minimum information versus rich descriptions

One area I will be watching is how much information gets pulled into “discovery.”

DAWN’s charter tries to keep this constrained to minimum public discovery information, which is an important limitation. There is a substantial difference between saying:

Here is a resource and the protocol you can use to contact it.

and saying:

Here is a detailed machine-readable account of what this agent can do, its goals, interfaces, credentials, trust properties, operating state, and suitability for your particular task.

The first is discovery. The second begins to look like capability description, selection, matchmaking, and trust evaluation.

The Agent Protocol Community Group is explicitly interested in that richer world. Its scope includes structured descriptions of capabilities, interfaces, goals, and states intended to support automated reasoning, composition, and orchestration.

DAWN is explicitly trying not to take on semantic matchmaking or selecting an agent based on capabilities or user intent. That boundary sounds clean when written into a charter, but it may prove much harder to maintain in an actual protocol.

A discovery mechanism has to return enough information for the requester to know what to do next. The perennial standards question will be: how much is enough?

I have watched enough discovery work over the years to know that “just enough metadata” has a habit of growing. “Enough” isn’t a particularly precise term.

The appeal—and risk—of the bigger architecture

On first reading, Agent Protocol may look like the more interesting effort. It is talking about the problems that make agentic systems genuinely difficult: identity, capabilities, communication, negotiation, trust, security, authorization, and collaboration.

Those questions are tightly connected. Trying to discuss one without running into several of the others can feel artificial. But that is also what makes me cautious. There is a real risk that Agent Protocol is trying to solve too many problems at once.

Identity alone is not a small standards problem. Neither are authorization, capability description, protocol negotiation, agent discovery, or secure cross-domain communication. Combining all of those into an architecture does not make their individual complexity disappear. It also increases the chance that assumptions made in one part of the system become requirements for all the others.

One advantage of DAWN’s narrower scope is that it creates more pressure to define the boundary.

• What does discovery actually have to accomplish?
• What can be delegated to an existing identity system?
• What belongs in an authorization protocol?
• What information needs to be published publicly?
• What should only become available after some trust relationship has been established?
• And what belongs to an application protocol rather than the discovery infrastructure?

Those constraints may make DAWN less exciting to describe, and may also make the resulting work easier to compose with other standards.

Web architecture versus Internet infrastructure

There is another difference in architectural flavor. The W3C work naturally approaches the problem from the Web. The group’s stated goal is an “Agentic Web,” and its work is built around interoperating with existing Web protocols and Web-native formats. The DAWN discussion looks more like an Internet infrastructure problem.

The proposed DAWN charter talks about existing protocols, delegation, federation, organizational boundaries, secure exchange of discovery information, and coordination with work around DNS, identity, and AI. Several individual drafts are already exploring different architectural possibilities, including DNS-like discovery models. Those drafts are proposals, not adopted IETF consensus, but they illustrate the range of infrastructure questions being considered.

Neither perspective is inherently better. They do, however, encourage different questions. A Web architecture discussion is likely to ask how an agent is represented as a Web resource and how another Web actor interacts with it. An Internet discovery discussion is more likely to ask how a resource can be located across administrative boundaries, how publication and delegation work, and what infrastructure should be reused to get there.

Ideally, those layers meet rather than compete.

Do the communities overlap?

Honestly? I don’t know, but it doesn’t feel like a lot based on the discussions I’m watching.

The W3C Community Group is large. It currently lists hundreds of participants from dozens of organizations. DAWN, meanwhile, is in the IETF, which doesn’t have membership records like that. The visible Internet-Drafts, at least, show participation from people with long experience in IETF networking and infrastructure work, alongside contributors from organizations that also participate broadly in Web and telecommunications standards.

But organizational overlap is not the same thing as the same standards community solving the problem together. Two groups can agree perfectly well in prose that they should coordinate while still developing different terminology, architectural assumptions, metadata models, or definitions of where one layer stops and another starts.

Those differences become much harder to reconcile once implementations appear.

This is one of the things I would watch more closely than whether the groups have superficially similar deliverables: are the people doing the work actually talking to each other early enough for the boundaries to line up?

And there is an important process difference

The other distinction is procedural.

The AI Agent Protocol effort is a W3C Community Group. The group’s page says that it will publish specifications. It can. Community Groups are useful places to incubate ideas, develop specifications, build communities, and demonstrate implementation interest.

But a Community Group specification is not a W3C Recommendation.

For work from the Agent Protocol Community Group to move onto the W3C Recommendation track, it would need to be taken up through the W3C standards process—for example, as work chartered into an appropriate Working Group. W3C hosting a Community Group also does not mean that the W3C Membership or W3C itself has endorsed the group’s work. (You’ve seen my Field Guide to standards bodies, right?)

DAWN is currently a proposed IETF Working Group, so it also should not be treated as finished standards work either. Its charter was still undergoing IETF review in September 2026. That said, the proposed charter already identifies Standards Track protocol documents among its intended deliverables. If DAWN is chartered and the work progresses successfully through the IETF process, that creates a defined route from the current discussion to Internet standards-track specifications.

That difference is worth remembering when evaluating apparently parallel standards efforts.

A specification can be technically interesting long before it has a clear path to becoming a standard.

So which should you follow?

For now, I don’t think this is an either/or choice.

If you are interested specifically in discovery as Internet infrastructure, DAWN is the more focused conversation. It is asking about the minimum public information needed to locate AI resources, how discovery works across different administrative scopes, and how existing infrastructure and trust models can be reused.

If you are interested in the broader question of agent interoperability on the Web, Agent Protocol is taking on far more of the problem: discovery, identity, capability description, communication, authorization, security, and collaboration.

That makes Agent Protocol potentially more compelling. It also gives it many more ways to become stuck.

I would track the two groups partly for different reasons, but I would pay particular attention to where they touch.

• Does DAWN remain a discovery layer that richer agent protocols can build upon?
• Does Agent Protocol rely on existing discovery infrastructure or develop its own competing mechanisms?
• Does “minimum discovery information” gradually become a capability description?
• Do either of the groups accidentally use discovery as a proxy for identity or trust?
• And perhaps most importantly: do their ideas about delegation, organizational affiliation, and authority line up?

Because finding an agent associated with example.com does not by itself tell me whether the organization operates that agent, endorses it, delegated authority to it, or merely published information about it.

That takes us straight back to the argument I started making earlier this year. The interesting part of discovery is rarely just finding the thing. It’s more about understanding what finding it tells you, and what it does not.

There are several other groups working around agent identity, communication, authorization, delegation, and interaction models, and I expect to come back to those.

For now, discovery is enough of a problem on its own.

📩 If you’d like to be notified of new posts rather than hoping you catch it on social media, I have an option for you! Subscribe to get a notification when new posts go live. No spam, just announcements of new posts. [Subscribe here]

Transcript

Welcome to the Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting. I’m Heather Flanagan, and every week I break down interesting topics in the field of digital identity, from credentials and standards to browser weirdness and policy twists.

If you work with digital identity but don’t have time to follow every specification or hype cycle, you’re in the right place.

Let’s get into it.

Earlier this year, I did a series of posts about discovery. It’s a really interesting and big problem space.

The basic argument was that discovery is so much more than just search.

When a system needs to find anything — an identity provider, a credential, a service, a tool, or now an AI agent — the interesting question is really, “Where is it?”

To be fair, that’s part of it. But it’s only part of it.

Discovery also raises questions about:

• What information is available
• Who gets to see it
• What you can infer from what you find
• What happens next

One of the conclusions I came to in that earlier series was that we have a habit of jumping too quickly into mechanisms.

We need to find something, so should we use DNS? What about a well-known URI, a registry, or a catalog?

All of those can be perfectly reasonable answers.

However, if that’s where you start, it’s easy to lose sight of what you’re actually trying to accomplish.

What does the requester need to learn?

What information should discovery reveal? What decisions should it enable? And what should happen after something has already been found?

Until you have some clarity on those questions, choosing the mechanism is getting ahead of yourself.

And AI agents are turning out to be a very good example of why that matters.

There are now several standards and industry groups talking about agent discovery, identity, authorization, capabilities, delegation, communication, and other related problems. I’m not going to cover them all here.

For now, I want to focus on discovery by comparing two efforts: the W3C’s AI Agent Protocol Community Group and the proposed IETF Discovery of Agents with Names Working Group, better known as DAWN.

---

Where AI Agent Discovery Begins

At the highest level, these two efforts do appear to overlap.

Both are asking some version of the same question:

I know something about the environment I’m operating in, but I do not already know exactly where the agent or resource I need is located. How do I find it?

That’s the common ground.

After that, their scopes start to look very different.

The W3C’s AI Agent Protocol Group has a very ambitious mission. It is interested not only in discovery, but also in how agents:

• Identify themselves
• Communicate
• Describe their capabilities
• Negotiate roles
• Authenticate and authorize interactions
• Protect security and privacy
• Collaborate with one another across the web

That’s a lot.

And frankly, those are many of the reasons that agentic AI is interesting as a standards problem.

It’s not especially novel for one piece of software to call another piece of software. We’ve been doing that for a very, very long time.

Things get harder when software needs to determine:

• What other actors exist
• What they can do
• Who can operate them
• What authority they have
• Whether they are appropriate for a particular task

The Agent Protocol Group is attempting to address a substantial portion of that larger architecture.

---

DAWN Takes a Narrower Approach

DAWN, however, is taking a much narrower approach.

Its proposed charter asks how a client can discover enough public information about an AI resource to begin some later interaction.

That information might include:

• What kind of resource it is
• How it can be reached
• What communication protocol it supports
• What service it exposes

The discovery process may involve referrals, delegation, indirection, or crossing organizational boundaries.

And then DAWN mostly stops there.

Its proposed charter explicitly puts broader capability catalogs, communication after discovery, Internet-wide search and indexing, agent identity management, and broader trust management outside of that initial scope.

That restraint may be the most important difference between these two efforts.

You can imagine a fairly clean layering between them.

DAWN could answer:

Where is the resource, and how do I start talking to it?

Boom. You’re done.

Whereas something like the Agent Protocol Group would answer:

What is this agent? What can it do? How does it identify itself, and how do we interact?

That sounds like a perfectly sensible set of questions.

Whether the standards work actually stays that neatly separated is an entirely different question.

---

How Much Information Belongs in Discovery?

One area I’m watching closely is how much information gets pulled into the definition of discovery.

DAWN is trying to describe the minimum public information necessary to find a resource and proceed.

That’s quite different from publishing a rich, machine-readable description of an agent’s:

• Capabilities
• Goals
• Interfaces
• Credentials
• State
• Suitability for a particular purpose

The first part is clearly discovery.

The second part starts to move into capability description, matchmaking, selection, and trust evaluation.

The W3C Agent Protocol work is explicitly interested in that richer description.

DAWN is explicitly trying not to be.

However, standards boundaries that look very clear in a charter are often harder to preserve once people start designing protocols.

A discovery mechanism has to return enough information for someone or something to decide what to do next.

And just enough metadata has a tendency to grow.

---

The Risks of Solving Too Much at Once

This is also where the broad scope of the Agent Protocol becomes attractive and potentially problematic.

On first reading, Agent Protocol may look like the more interesting effort precisely because it is taking on all of those interconnected questions.

It is addressing:

• Identity
• Authorization
• Capabilities
• Communication
• Negotiation
• Security
• Collaboration

Those problems do connect to each other.

But there is a real risk that the group is trying to solve too many hard standards problems at one time.

Identity by itself is not a small problem.

Neither is authorization. Neither is capability description or any of the other things on that list.

Putting all of them into one architecture does not make their individual complexity disappear.

It can also mean that assumptions made in one part of the architecture start constraining everything else.

And that’s one reason I find DAWN’s narrower charter interesting.

A smaller scope forces harder questions about boundaries.

---

What Should Discovery Actually Reveal?

What does discovery actually need to accomplish?

What information needs to be public?

What should only become available after some trust relationship exists?

There’s a whole list of questions like this.

These constraints may make DAWN sound less exciting.

They may also make whatever it produces easier to reuse.

That’s an important tradeoff in standards development.

A narrower protocol may not attempt to answer every question about an AI agent. Instead, it can focus on doing one thing well and provide a foundation for other layers to build upon.

---

Web Architecture Versus Internet Infrastructure

There’s another difference in the architectural flavor of all of this.

The W3C effort naturally starts from the World Wide Web. Its goal is an agentic Web, whatever that means, and its discussions are oriented toward web protocols, web resources, and web-native formats.

DAWN looks more like an Internet infrastructure problem.

Its proposed charter talks about:

• Existing protocols
• Delegation
• Federation
• Administrative boundaries
• Local discovery environments
• Organizational environments
• The public Internet

I’m not saying either approach is inherently better or worse.

However, they do lead people to ask different questions.

And that distinction may become increasingly important as AI agents operate across different environments and organizational boundaries.

---

How Much Overlap Is There Between the Communities?

That brings me to something I don’t know enough about yet.

How much overlap is there between the people and communities doing this work?

The W3C community does publish a participant list.

The IETF does not work that way. There will never be a DAWN working group membership roster to put beside the W3C list.

So you can’t answer the question simply by comparing membership databases.

Instead, you have to look at:

• Who is writing drafts
• Who is participating in meetings
• Who is participating in mailing list discussions
• Who is carrying ideas between the two communities

This matters a lot.

Two groups can say they intend to coordinate while still developing different terminology, different architectural assumptions, and different ideas about where one layer ends and the other begins.

It usually looks something like, “Well, we told them what we were going to do, but we’re doing it anyway.”

Those differences get much harder to reconcile after implementations appear.

---

Standards Status Matters

There’s also an important process distinction to remember.

The AI Agent Protocol effort is a W3C Community Group.

Community Groups can do very useful incubation work. They can:

• Develop specifications
• Test ideas
• Build implementation experience
• Attract a community around a problem

But a Community Group specification is not a W3C Recommendation.

It is not a standard.

If the work is going to move into the W3C Recommendation track, it will eventually need to be taken up through the formal W3C standards process, such as by an appropriately chartered Working Group.

DAWN is not finished standards work either.

It is currently in the IETF chartering process, but its proposed charter already describes standards-track deliverables.

So when looking at these efforts, it is worth distinguishing technical ambition from standards status.

---

Which AI Agent Discovery Effort Should You Follow?

For right now, I would not treat this as a question of which group to follow instead of the other.

If you’re interested in discovery as an Internet infrastructure problem, DAWN is the more focused conversation for you.

If you’re interested in the broader architecture of interoperable agents on the web, Agent Protocol is taking on much more of that problem.

That may make it more compelling.

It might also give it more ways to get stuck.

So what I’m going to be watching for is more the boundary between the two.

Does DAWN remain a discovery layer that richer agent protocols can build on?

Does Agent Protocol consume existing discovery infrastructure, or does it create competing mechanisms?

Does minimum discovery metadata turn into some kind of capability description?

And do either of these groups accidentally treat discovery as evidence of identity, affiliation, or authority?

---

Discovery Is Not Evidence of Identity

This last question is particularly important.

Finding an agent associated with example.com does not, by itself, tell me whether that organization:

• Operates the agent
• Endorses it
• Delegated authority to it
• Simply published information about it

That’s a critical distinction.

Discovery tells you that you found something.

It does not necessarily tell you what that thing is authorized to do, who trusts it, or what relationship it has to the organization associated with the information.

And that brings me back to the larger point from my earlier discovery series.

The interesting part of discovery is rarely just finding the thing.

The interesting part is understanding what finding it tells you and what it does not tell you.

---

The Bigger Question for AI Agent Discovery

There are several other groups having related discussions around agent identity, authorization, delegation, and interaction models. I expect I’m going to talk about those in a future episode.

But for now, discovery is enough of a problem to think about on its own.

As AI agents become more capable and more interconnected, the standards community has to decide not only how agents find one another, but also what information discovery should expose and where the boundaries between discovery, identity, capability, and trust should sit.

Those boundaries may ultimately matter just as much as the discovery mechanisms themselves.

---

About the Digital Identity Digest

And that’s it for this week’s episode of the Digital Identity Digest.

If it helps make things a little clearer, or at least a little more interesting, share it with a friend or colleague and connect with me on LinkedIn @hlflanagan.

If you enjoyed the show, be sure to subscribe and leave me a rating and review on Apple Podcasts or wherever you listen to podcasts.

You can also find the full written post at Spherical Cow Consulting.

Stay curious, stay engaged, and let’s get these conversations going.