“A familiar thing happens in standards conversations.”

Someone describes a problem involving services, accounts, credentials, agents, tools, or capabilities. Within ten minutes, somebody has proposed DNS, somebody else has suggested .well-known, and a third person is designing a registry.

No one has yet agreed what is being discovered.

This is understandable. Infrastructure gives an abstract problem a concrete shape. Once there is a namespace, a record type, a URL, or a place to publish metadata, it feels as though progress is being made. Sometimes it is. Sometimes the group has simply chosen a respectable-looking place to store its unresolved assumptions.

This series began with the argument that discovery is bigger than search. Across identity providers, forgotten accounts, digital estates, service endpoints, tools, capabilities, and agents, the same broad pattern keeps recurring: something exists somewhere; someone or something needs to find it; the process of finding it has costs and risks; and finding it changes what can happen next.

That continuity matters. So do the differences.

Before deciding whether the answer is DNS, .well-known, a registry, a catalog, a manifest, a gateway, or one more layer named after an animal, we need to understand what is being discovered, who is looking, what they already know, what they are entitled to learn, and what can happen after discovery succeeds.

That work comes first. It does not, unfortunately, make the infrastructure choice easy.

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!

Infrastructure smuggles in a model

Every discovery mechanism carries assumptions about the world. DNS, for example, assumes that control of a domain is meaningful. A well-known URI assumes that the client already knows the relevant site or origin. A registry assumes that someone can govern names, admission, or uniqueness. An enterprise catalog assumes an organizational authority capable of deciding what belongs in it. A signed manifest assumes that the relying party knows which signatures matter and how to evaluate them.

Those assumptions may fit the problem. They may also quietly redefine it.

What are we actually trying to discover?

A mechanism that answers “Where is the server?” does not necessarily answer “What can it do?” A tool catalog may describe capabilities without saying who may invoke them. A directory may establish that an agent exists without telling us who operates it, whose authority it claims, or whether any of those claims should be believed.

The discovery object may be a location, a piece of data, a capability, an identity, or an authority relationship. Those categories overlap, but they should not be collapsed simply because one protocol can publish strings about all of them.

That is why the first useful question is not “Where should we put the record?” It is “What, exactly, are we trying to learn?”

What does the discoverer already know?

The second question is what the discoverer already knows. Discovery rarely starts from complete ignorance. The client may know a domain, an origin, an email address, a user identifier, an application, a network segment, or a previously established relationship.

That starting point constrains which mechanisms are plausible and which authority boundaries they imply.

A browser that already knows a Web origin has different options from one that knows only a person’s name. A device on a local network can use mechanisms that would be absurd at Internet scale. An enterprise system can rely on a curated catalog in ways that an unaffiliated public client cannot.

The starting point is not incidental. It is part of the architecture.

What well-known URIs are actually good at

Mark Nottingham’s recent post, “So You Want To Define a Well-Known URI”, is useful here because it is written by someone with every reason to like the mechanism and enough experience to be wary of using it everywhere.

Mark is one of the authors of the Well-Known URI specification and the current designated expert for the relevant IANA registry. His guidance is notably restrained: well-known locations work best when a client already knows the site and needs to discover something about that site as a whole.

A fixed place to look

That is a real and useful pattern. A crawler knows the site and needs its access policy. A client knows the site and needs a predictable password-change location. The well-known URI provides a fixed place to look.

What it does not do is tell the client which site it should ask.

That distinction becomes awkward surprisingly quickly. If the client starts with login.example.com, should it look there, at example.com, or somewhere else? Should it follow redirects? What if the authentication service is run by a different team from the corporate website? What if the apex domain is hosted by an external provider that has no interest in serving identity metadata?

Mark’s point is that “the site” is often fuzzier in practice than it looks in a diagram. A well-known URI may be the correct mechanism and still leave a difficult discovery problem around identifying the authoritative origin.

Registration is not legitimacy

Mark also warns against treating registration as legitimacy. A slot in the well-known registry is not a credential, an endorsement, or a magical adoption generator. It is a reservation of a name for a defined purpose.

Standards infrastructure can be valuable without conferring moral authority, operational competence, or market success. This is worth remembering whenever a registry entry begins to glow with more institutional significance than it has technically earned.

FedCM and the problem that stays difficult

The Federated Credential Manager API (FedCM), a specification under development in the W3C, offers an unusually good example because the groups involved broadly agree about what must be discovered and why. The difficult part is still the mechanism.

FedCM needs a browser to find identity-provider metadata. It also needs a single discovery point at the registrable-domain level for an important privacy reason: the IdP must not be able to vary configuration paths in ways that reveal which relying party the user is visiting.

The appeal of the apex domain

The current design uses a well-known file at the apex of the registrable domain. Architecturally, that has an appealing logic. The organizational domain provides a single authoritative place from which the browser can discover the permitted IdP configurations.

Operationally, it can be painful.

An authentication service may run at login.example.com, while example.com belongs to another team, points to a separately managed website, or cannot easily host the required file. The service operator may control the IdP and still lack the ability to modify the apex-domain resource on which the discovery design depends.

Delegation changes where the complexity goes

A FedCM pull request proposes allowing the well-known file to live at a fixed web-identity subdomain, with fallback to the existing apex-domain location. The idea is that an organization could delegate that subdomain to the team or provider operating the identity service, using ordinary A, AAAA, or CNAME records. Another proposal explores delegation through a DNS TXT record.

All of these approaches are trying to discover the same thing. They disagree about where authority should begin, how delegation should work, who must coordinate a deployment, what browsers must implement, and how migration and fallback should behave.

The apex-domain model keeps the authority story relatively simple, but can make deployment difficult. A fixed HTTP subdomain improves delegation but adds another convention, another certificate, and another lookup path. A DNS-based delegation mechanism expresses the handoff differently but introduces its own operational and architectural questions.

There is no hidden option that preserves every desirable property and inconveniences no one. Standards work occasionally has to proceed without that luxury.

The TAG is still discussing it

The question is difficult enough that the FedID Working Group and Community Group have asked the W3C TAG for architectural guidance. The issue asks whether the Web has a preferred pattern for something that must have a cardinality of one at the registrable-domain level while avoiding a requirement that every IdP directly modify the apex. The alternatives under discussion include an underscored DNS name and a fixed HTTP subdomain.

That discussion is still open.

This matters because it prevents an overly tidy conclusion. Defining the discovery object, privacy requirement, scope, and authority boundary is necessary. It does not cause the correct mechanism to emerge from the mist, accompanied by a standards-track choir.

What it does is make the remaining disagreement legible.

Instead of vaguely arguing about “discovery,” the groups can argue about the real tradeoffs: registrable-domain authority, operational ownership, delegation, privacy, migration, compatibility, and the amount of complexity that browsers and IdPs should each absorb.

That is progress, even when it does not feel much like closure.

The mechanism is part of the governance model

Discovery infrastructure is rarely just plumbing. It determines who can publish, who can delegate, who can revoke, who bears operational costs, and whose view of the system becomes authoritative.

DNS privileges control of the relevant namespace. A well-known URI grants privileges over the relevant origin. A registry privileges its operator and admission rules. A catalog privileges the organization maintaining it. A vendor gateway may make discovery easier while quietly making that vendor’s ecosystem the default boundary of what can be found.

None of that makes those mechanisms bad. It makes them consequential.

Authoritative-looking is not the same as authoritative

One persistent mistake is to treat publication through a recognized infrastructure as evidence that the published thing is legitimate. A DNS record looks official, an entry under /.well-known/ looks standardized, and a registry entry carries just enough procedural polish to discourage awkward questions.

Sometimes that appearance reflects real governance. Sometimes it means only that someone had access to the domain or sufficient stamina to complete the registration template.

Infrastructure can establish useful facts. DNS can show that a domain operator published a value. A signature can show that a key signed a statement. A registry can show that an entry was admitted under particular rules.

Infrastructure cannot decide whether the service is appropriate for this user, whether the signer had the relevant authority, whether the information is still current, or whether the requester should be allowed to act on it.

Those are governance and policy questions. Moving them into a protocol field does not make them disappear. It makes them easier to overlook.

Discovery is usually a sequence

Another reason the mechanism debate remains difficult is that “discovery” is often treated as a single lookup. In practice, it is frequently a chain.

One mechanism may provide the starting point. Another retrieves descriptive metadata. Another establishes identity or provenance. Another applies policy. Another determines what the requester may see. Only then does the system decide whether an action should occur.

Four different jobs hiding under one word

It helps to separate at least four stages:

• Bootstrap: Where do I begin?
• Description: What exists here, and what does it claim to do?
• Trust and authority: Why should I believe it, and who stands behind it?
• Permission and action: May this requester use it for this purpose?

A well-known URI may be an excellent bootstrap or metadata retrieval mechanism. It does not automatically establish trust, authorization, or fitness for use. DNS may locate or delegate a service without describing its capabilities. A signed manifest may provide integrity without resolving whether the signer is an acceptable authority.

What the earlier posts taught us

The previous posts in this series all reached versions of the same conclusion.

Identity-provider discovery was not just about finding a login button; it was governed by matching under the right context and rules. Personal account and digital-estate discovery showed that completeness is both valuable and dangerous. Tool and agent discovery showed that the distance between finding something and invoking it can become very short indeed.

Taken together, those cases suggest that discovery mechanisms should be judged not only by whether they return an answer, but by what kind of answer they return, what confidence it supports, who can obtain it, and what it enables them to do.

Visibility, freshness, and failure

The infrastructure choice also determines how discovery fails.

A public record may make legitimate integration easy while making enumeration equally convenient. A curated catalog can reduce exposure but create a bottleneck and a new authority. A static file may be simple to deploy but difficult to revoke quickly. A dynamic API may provide current, policy-sensitive answers while becoming a high-value availability dependency.

Yesterday’s answer may no longer be safe

Freshness matters more as discovery approaches action. A stale endpoint may cause a retry. A stale trust relationship may expose information. A stale tool description may lead software to invoke something whose behavior or authority has changed.

An agent whose delegated authority expired yesterday should not remain discoverable as though nothing happened, although computers have demonstrated a remarkable ability to preserve yesterday’s confidence well into tomorrow.

More complete is not always better

Visibility needs equal care. More complete discovery is not always better. A public inventory of services, accounts, agents, or internal capabilities may be extremely useful to the intended user and equally useful to an attacker.

Before choosing the mechanism, designers need to know whether everyone should receive the same answer, whether authentication must precede discovery, whether some objects should remain invisible, and whether the system may reveal existence without revealing details.

These are not secondary features to be bolted on after the lookup works. They affect whether the lookup should be public, authenticated, filtered, cached, delegated, or centralized in the first place.

Better questions do not produce a perfect mechanism

The practical framework remains straightforward, even when the answers are not.

Before selecting infrastructure, ask:

• What is being discovered?
• What does the discoverer already know?
• Which party is authoritative for the answer?
• Who can publish, delegate, update, and revoke it?
• Who is allowed to ask, and what should remain hidden?
• How fresh must the answer be?
• What does the mechanism actually prove?
• What happens if the answer is wrong, stale, incomplete, or malicious?
• What can happen after discovery succeeds?

Those questions will not produce a universal architecture. They may not even produce consensus.

What they should produce is a clearer disagreement.

The tradeoff is the architecture

The FedCM example is a good reminder that a hard discovery problem can remain hard even when the participants agree on the object, privacy goal, and desired cardinality. At that point, choosing between mechanisms is a judgment about which tradeoffs the ecosystem can live with and where the complexity should go.

That is real architecture work. It is also less satisfying than drawing a box labeled “Discovery Service,” which may explain some of its limited popularity.

The mechanism is often the most visible part of a discovery design, but it is rarely the whole design. By the time a system is ready for DNS, .well-known, a registry, a catalog, or a manifest, many of its hardest decisions should already have been made.

When they have not, the infrastructure will make some of those decisions anyway—quietly, inconsistently, and with the reassuring appearance of authority.

Discovery starts before infrastructure.

It just does not end there.

📩 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

Throughout this series on discovery, one theme has appeared repeatedly.

Something exists somewhere.

Someone—or something—needs to find it.

And what happens after discovery often matters just as much as the discovery itself.

However, before deciding whether the answer is DNS, a well-known URI, a registry, a catalog, a manifest, or some entirely new approach, there is a more important question to answer:

What problem are we actually trying to solve?

That sounds obvious.

Yet many standards discussions jump directly to infrastructure before fully understanding the discovery requirements.

---

The Familiar Pattern in Standards Discussions

Many discovery conversations follow a predictable path.

Someone describes a challenge involving:

• Services
• Accounts
• Credentials
• Identity providers
• Agents
• Tools
• Capabilities

Soon afterward, proposed solutions emerge.

Common suggestions include:

• DNS records
• Well-known URIs
• Registries
• Catalogs
• Gateway services

The discussion often moves quickly toward implementation.

However, agreement on the infrastructure does not necessarily mean agreement on the underlying question.

---

Discovery Questions Are Not Interchangeable

Discovery can mean many different things.

For example, a system may need to discover:

• A network location
• A configuration document
• A service endpoint
• A capability
• An identity
• Evidence of authority
• Trust information

These requirements may appear related.

However, they are not identical.

And they do not automatically point to the same discovery mechanism.

That distinction is critical.

---

Why Infrastructure Feels Like Progress

Infrastructure provides something tangible.

Once a group defines:

• A namespace
• A record type
• A URL structure
• A metadata location

The problem feels more concrete.

Sometimes that genuinely represents progress.

Other times, however, infrastructure merely becomes a place to store unresolved assumptions.

The appearance of certainty can be misleading.

---

Discovery Starts Before Infrastructure

Earlier discussions in this series explored discovery across many contexts:

• Identity providers
• Forgotten accounts
• Digital estates
• Service endpoints
• Tools
• Capabilities
• Software agents

Across all of these examples, the same pattern emerges.

Something exists.

Someone needs to find it.

The process creates both opportunities and risks.

And discovery changes what can happen next.

Before selecting a mechanism, organizations need to understand:

• What is being discovered
• Who is performing discovery
• What information is already known
• What information may be revealed
• What actions become possible afterward

Only then can infrastructure choices be evaluated properly.

---

Every Discovery Mechanism Has Assumptions

No discovery mechanism is neutral.

Each comes with built-in assumptions about authority and control.

For example:

• DNS depends on domain ownership
• Well-known URIs depend on control of a website
• Registries depend on governance and admission rules
• Catalogs depend on organizational maintenance

These assumptions may fit a problem well.

Or they may introduce unnecessary constraints.

The right choice depends entirely on the discovery requirements.

---

Location Is Not Capability

One of the most common mistakes is assuming that finding something tells us everything we need to know about it.

It does not.

For example:

• A mechanism may answer where a server exists
• A catalog may describe capabilities
• A directory may identify an agent

Yet none of those automatically answer:

• Who operates it
• Who can use it
• Whether it is trustworthy
• Whether it is appropriate for a specific purpose

Discovery and trust are related.

They are not the same thing.

---

What Does the Discoverer Already Know

Discovery rarely begins from complete ignorance.

Most systems start with some information already available.

That information might include:

• A domain name
• An origin
• An email address
• A user identifier
• A network location
• An established relationship

This starting point matters.

In fact, it often determines which discovery mechanisms are practical.

For example:

• A browser that knows an origin has different options than one that only knows a person’s name
• A local network device can use methods that would never work at internet scale
• An enterprise can rely on curated catalogs that public clients cannot

The starting point is not incidental.

It is part of the architecture.

---

Understanding Well Known URIs

A useful example comes from well-known URIs.

These locations work best when a client already knows the relevant site and needs a predictable place to retrieve information.

They answer a specific question:

Where can I find information about this site?

They do not answer:

Which site should I trust in the first place?

That distinction creates challenges surprisingly quickly.

For example:

• Which domain should be considered authoritative?
• Should redirects be followed?
• What happens when identity services and corporate websites are managed separately?
• What if different teams control different parts of the infrastructure?

These questions cannot be solved by a URL pattern alone.

---

Registration Is Not Legitimacy

Another common misconception involves registries.

A registry entry may provide:

• A reserved name
• A defined purpose
• Administrative structure

However, it does not automatically provide:

• Trust
• Authority
• Operational quality
• Market adoption

Being listed somewhere does not make a service legitimate.

It simply means the service was registered according to specific rules.

That distinction is easy to forget.

---

FedCM and the Reality of Discovery Design

The evolution of FedCM provides a useful case study.

FedCM requires browsers to discover identity provider information in a privacy-preserving way.

The current model uses:

• A well-known file
• Located on the organization’s primary domain

The goal is straightforward.

Identity providers should not be able to leak information about which relying party a user is visiting.

However, operational reality introduces challenges.

The identity provider may be managed by:

• A separate team
• A separate system
• A separate domain

As a result, organizations often face deployment difficulties even when the discovery goal is clear.

---

Authority and Delegation Create Tradeoffs

Several alternative approaches have been proposed.

These include:

• Fixed identity subdomains
• DNS TXT record delegation
• Alternative discovery paths

All attempt to solve the same discovery problem.

Yet each distributes authority differently.

The tradeoffs involve:

• Delegation models
• Operational ownership
• Browser complexity
• Migration paths
• Privacy protections

This demonstrates an important reality.

Even when everyone agrees on what needs to be discovered, choosing the mechanism remains difficult.

---

Discovery Is Also Governance

Discovery is not purely technical.

Every mechanism embeds governance decisions.

It determines:

• Who can publish information
• Who can delegate authority
• Who can revoke access
• Who bears operational responsibility
• Whose perspective becomes authoritative

Consider the differences:

• DNS emphasizes namespace ownership
• Well-known URIs emphasize origin control
• Registries emphasize governance processes
• Catalogs emphasize organizational management

Each model places authority somewhere different.

---

Infrastructure Can Look More Authoritative Than It Is

Discovery infrastructure often appears more trustworthy than it actually is.

For example:

• DNS records look official
• Registry entries appear legitimate
• Signed statements feel authoritative

These mechanisms can establish useful facts.

They can demonstrate:

• Domain ownership
• Signed assertions
• Registry admission

However, they cannot determine:

• Whether information is current
• Whether authority is appropriate
• Whether trust is justified
• Whether a requester should act on the information

Those remain governance and policy decisions.

---

Discovery Is Usually a Chain

Many discussions treat discovery as a single lookup.

In reality, discovery often involves multiple stages.

For example:

1. Bootstrap discovery
2. Metadata retrieval
3. Trust evaluation
4. Policy assessment
5. Authorization decisions
6. Action execution

Each stage answers a different question.

Treating them as one problem creates confusion.

---

Four Types of Discovery Questions

It can be helpful to separate discovery into four categories.

Bootstrap

The first question is simple:

• Where do I begin?

Description

Next comes understanding:

• What exists here?
• What capabilities are available?

Trust and Authority

Then we ask:

• Why should I believe this?
• Who stands behind it?

Permission and Action

Finally:

• May this requester use it?
• Should action occur?

These questions often appear together.

However, they require different mechanisms and controls.

---

Discovery Mechanisms Should Be Judged Carefully

The most important question is not whether a mechanism returns an answer.

Instead, ask:

• What answer does it return?
• Who receives that answer?
• How much confidence should it inspire?
• What actions does it enable?

These questions often matter more than the mechanism itself.

---

Every Design Has Failure Modes

Discovery infrastructure also determines how systems fail.

For example:

• Public records improve accessibility but may enable enumeration
• Catalogs improve governance but create bottlenecks
• Static files simplify deployment but complicate revocation
• Dynamic APIs improve freshness but increase dependencies

Each design introduces tradeoffs.

There is no universally correct answer.

---

Freshness Matters More Than Ever

As discovery moves closer to action, stale information becomes increasingly dangerous.

A stale endpoint may simply cause a retry.

A stale trust relationship may cause:

• Unauthorized access
• Data exposure
• Invalid decisions
• Incorrect automation

That difference matters.

Especially as automated systems become more capable.

---

Discovery Design Begins With Questions

Before selecting any discovery mechanism, organizations should ask:

• Should everyone receive the same answer?
• Should authentication occur first?
• Should some objects remain hidden?
• Can existence be revealed without revealing details?
• What happens when discovery succeeds?

These questions shape the architecture itself.

They are not optional additions.

---

Final Thoughts

Discovery infrastructure is often the most visible part of a system.

However, it is rarely the most important part.

By the time teams are debating:

• DNS
• Well-known URIs
• Registries
• Catalogs
• Manifests

Many of the hardest architectural decisions should already be complete.

When they are not, the infrastructure often makes those decisions implicitly.

And not always in the way designers intended.

---

Conclusion

Choosing a discovery mechanism is difficult because discovery is never just about finding something.

It is about authority, trust, governance, visibility, and action.

The infrastructure matters.

But understanding the discovery problem comes first.

Because once the wrong assumptions are embedded into the discovery layer, even the most elegant infrastructure can produce the wrong outcomes.