design-reviews#1243: Service discovery

#1243: Service discovery

Opened

Jul 1, 2026

We have seen a number of proposals that relate to facilitating service discovery. Due to the not exactly 1:1 mapping between a (sub-)domain, and what the user may see as a self-contained website or app, approaches that use the .well-known namespace have to come up with their own approach to routing. We're tracking various proposals here, in the hopes of creating a more harmonized approach in future.

#1217 (Tag Bot for #1217)
Discoverable Destinations (formerly used well-known URLs, but moved away from that, to <link>s and rel attributes)
A Well-Known URL for Changing Passwords (could this benefit from being able to also target distinct sites hosted deeper in the URL tree?)
Well-Known URI for Accessibility Issue Reporting

Please edit this comment to keep it as the point of truth for linking to related proposals. Please don't delete any proposals, but rather, if they are considered unrelated later, group them separately in this comment, and explain why.

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1243

Discussions

Comment by @matatk Jul 2, 2026 (See Github)

I'll leave the first comment as the place where we focus on keeping track of the related proposals. Here are some thoughts about next steps, and goals.

Collecting more related proposals.
Classifying the use cases.
Figuring out if there's a design principle that needs adding about when to use well-known URIs, when to use link relations, etc.
- Both well-known URIs and link relations are mentioned as examples of registries in the Design Principles (they aren't mentioned directly in other principles).
For cases where a well-known URI is appropriate, but the site (tree) structure may be organic/multi-tenanted: looking at the problem of routing/mapping from 'a website - (sub-)domain' to 'a website - organic site structure in the URL tree' to see if we can harmonize it.