The core of the issue is that FedCM desires to mandate that implementations provide a single authoritative document for a "registrable domain" (also sometimes called an "eTLD+1").
So far so good, we all know about the PSL.
Today, the FedCM spec says that to locate the single authoritative document for an origin like idp.foo.example, the browser should query https://foo.example/.well-known/web-identity - note particularly - foo.example, not idp.foo.example. Foo Inc. uses a CNAME to point idp.foo.example to its identity service in (as you say) an ordinary virtual host transaction. However, Foo Inc. cannot use a CNAME to point foo.example to the same identity service for multiple reasons. First, foo.example isn't the identity service - it's a marketing or storefront page. Second, DNS does not support CNAME for foo.example, because foo.example is an apex domain.
Ah, OK. So your user goes to another department in the company and says "we need the web server the company is paying you to run handle this URL https://foo.example/.well-known/web-identity"; and they say some combination of "what?" and "no."
That still sounds like a business problem, not a technical one. R's, John _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
