Thanks Matthew. > Your link to the spec is a 404, so we can't review that document, so > we're trying to go by your description of the problem.
I appreciate you clicking the link and sharing this information with me. The proper link is https://w3c-fedid.github.io/FedCM/ - not sure how I messed that up in my initial mail. > HTTP 307 redirect We did discuss this option in the FedID WG. You can see brief notes in the 2026-02-10 minutes linked from the github issue. https://github.com/w3c-fedid/meetings/blob/main/2026/2026-02-10-FedCM-notes.md#use-of-apex-domain-is-hard-for-organizations-with-different-services-owning-different-subdomains-809. I mostly shyed away from this option for the reason you mention ("I can see why it would be desirable to have the indirection [...] in the DNS next to the indirection for auth"). When a company purchases authentication services from an external provider, it's more operationally convenient to do all of the delegation in one system (i.e. DNS - CNAME + TXT/SVCB/CNAME/TBD) vs in two systems (DNS - CNAME + APEX - 307). Additionally, it's a smaller number of runtime dependencies - a DNS or Auth outage will always bring down Auth - but - status quo - an apex application outage (e.g. microsoft.com) will not bring down auth (on login.microsoft.com) - which is a nice property to preserve. >> Option C: Fixed subdomain > If this fits into an established pattern then it > doesn't seem like a bad choice to me, other than the lack of > configurability It's not really an established pattern. From what I saw of well-known URIs, they are mostly origin preserving - the algorithms start with a URL like https://login.foo.example and locate a well-known file like https://login.foo.example/.well-known/oauth-authorization-server . FedCM is the only spec that I know of which switches the host from the URI that beings the algorithm to the apex domain. I think the major disadvantage here is defining a non-underscore-prefixed special purpose subdomain. I don't know of any non-underscore-prefixed special purpose subdomains other than "www" (which IIUC, is mostly made special by browsers, outside of any standard). I know that a number of domains make a pattern of allocating a subdomain per customers, and establishing special purpose subdomains requires systems with such patterns to forbid such domains, and potential evict customers who use the same name. It was my (possibly incorrect) impression that these considerations were the reason that underscore-prefixed special purpose subdomains became a common pattern - underscore prefixed labels, unlike domain labels, are unlikely to be in use. >> Option D: TXT record I don't have a lot of appetite for defining a new record type - but I'm open to it. It's really here that I'm seeking your guidance. In some sense, all of these options are just different DNS records. Using the example of microsoftonline.com (the registrable domain for Microsoft Entra), the domain current has a record like: login.microsoftonline.com. 9299 CNAME login.mso.msidentity.com. The options are like: web-identity.microsoftonline.com. 9299 CNAME login.mso.msidentity.com. _web-identity.microsoftonline.com. 9299 TXT webidentity;sub=login _web-identity.microsoftonline.com. 9299 TXT webidentity;sub=login;loginUrl=/login;accountsUrl=/accounts _web-identity.microsoftonline.com. 9299 SVBC login.microsoftonline.com _web-identity.microsoftonline.com. 9299 SVBC login.microsoftonline.com loginUrl=/login, accountsUrl=/accounts _web-identity.microsoftonline.com. 9299 WEBID login.microsoftonline.com loginUrl=/login, accountsUrl=/accounts _web-identity._https.microsoftonline.com. 9299 SVR login.microsoftonline.com I think the major dimensions are: * Underscore prefix or not => I think I prefer underscore, to avoid conflicts. * Just domain or domain+parameters => very weak preference, though using parameters can save one round trip * Record type: * TXT is impure, but widely supported * SVBC I don't understand that well, but is domain+params, less widely supported * SVR I don't undersatnd that well either, but iiuc, is pure domains, less widely supported * WEBID (new record type) can be whatever, and has zero support so far, because it doesn't exist it. I read your considerations - and they make sense - but could I push you to recommend one a bit more concretely? > Perhaps there's detail in the spec that clarifies this, but what are > the two paths? Yeah, the spec clarifies this, you can look now that the link works. But the two paths are the paths that are called by FedCM before the user has consented to disclose the relying party's (e.g. teams.microsoft.com) identity to the identity provider (e.g. login.microsoft.com). Specifically, 1) the accounts url, which returns the list of signed-in accounts 2) the login url, where a new account can be added. The user consents to disclose the relying party's identity to the identity provider after account selection, so these account-selected / account-addition URLs must be unique per registrable domain. If they were not unique, an identity provider could instruct each relying party to use a different configuration, disclosing the relying party identity pre-consent. One of the "considerations" sections in the FedCM spec should describe this in greater detail. And I'll just add - thanks for all your inputs here! Thanks, Will ________________________________ From: Matthew Pounsett <[email protected]> Sent: Wednesday, April 8, 2026 1:40 PM To: Will Bartlett <[email protected]> Cc: [email protected] <[email protected]> Subject: [EXTERNAL] [DNSOP] Re: Advice sought: DNS record type for FedCM well-known file delegation [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Will; Your link to the spec is a 404, so we can't review that document, so we're trying to go by your description of the problem. As Jim mentioned, it's missing some requirements details that might explain why you're looking at these specific solutions, but I'm going to do my best to infer, and guess what I would do in a similar situation. As I mentioned in another message in the thread, it seems like you could solve this problem with an HTTP 307 redirect from the auth client's well-known name (<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2F.well-known%2Fweb-identity&data=05%7C02%7Cwibartle%40microsoft.com%7Cf03b5ce41df148a835f408de95af14be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639112776526142764%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=HdAd9b06dIuhghpVPeQsrmtrCKhzdrIxAa4bbcmKh24%3D&reserved=0<https://example.com/.well-known/web-identity>>) to the location of that file on the auth provider's web site (HTTP 301 if they're optimistic about their long term relationship with the provider). I can see why it would be desirable to have the indirection for this file (configuration? attestation?) in the DNS next to the indirection for auth (login.example.com CNAME) though, so with that in mind... I'm mostly going to skip over the SVCB options. They seem like overkill to me, for your needs, but as I haven't dived into using them myself yet I don't want to get out over my skis. On Mon, Apr 6, 2026 at 8:04 PM Will Bartlett <[email protected]> wrote: > Option C: Fixed subdomain — No DNS lookup; always fetch from > web-identity.<registrable-domain>, which the IDP points (e.g., via CNAME) to > their infrastructure. I'm not sure how well this fits with other Wll-Known URIs. The ones I can think of specify the apex domain name, same as your original problem description. If this fits into an established pattern then it doesn't seem like a bad choice to me, other than the lack of configurability. Will there be a reason that you run in the the same problem later, at a different part of whatever system uses this, where you want the name to point to two places? > Option D: TXT record — Query _web-identity.<registrable-domain> for a TXT > record containing sub=login, then fetch the well-known file from > login.<registrable-domain>. > Our key questions: Although TXT records for formal systems like this are discouraged, putting it at a (registered) underscore name at least avoids the TXT crowding at the apex. This could be successful, and is unlikely to break anything, but you'll see push-back from some people for at least style reasons and probably also for reasons of technical implementation. If your RDATA is going to just be a domain name, then a dedicated RR type with NS-like record structure would provide you with better developer experience for anyone trying to implement it, as that would obviate a lot of the "does this look like a domain name or did somebody fat-finger the RDATA?" error-detection code that TXT would require. Anything that makes it into a zone would already have to go through the error detection at the authoritative server, where there's a better chance of it being handled properly. This isn't a very serious suggestion, but if SVCB is too much, and registering your own RR type seems like something you don't have the appetite for, then perhaps consider the SVC record. It's definitely overkill, because it includes priority, weight, and a port number that you (probably?) don't need, but it's certainly far simpler to work with than SVCB. > Naming convention. Is _web-identity.<domain> an appropriate underscore name? > Any conflicts or conventions we should be aware of? Should we register in the > Underscored and Globally Scoped DNS Node Names registry (RFC 8552)? If you choose to use an underscore name you should absolutely register it. > Embedding data in DNS vs delegation. Option A puts application data (URL > paths) directly in DNS records, avoiding an HTTP fetch. Is there precedent or > guidance for/against this pattern? We're aware of the 65535-byte practical > limit on DNS responses, but the data here is small (two short paths). Perhaps there's detail in the spec that clarifies this, but what are the two paths? From your description it seems like all you need is the domain name of the web server (or virtual host) where the file can be found. That would fit perfectly into a record of the form: example.com IN FCM authprovider.com _______________________________________________ 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]
