- From: William Bartlett <notifications@github.com>
- Date: Fri, 10 Apr 2026 13:21:20 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1217/4226519044@github.com>
will-bartlett left a comment (w3ctag/design-reviews#1217) > DNSOP is likely the right place to talk about the possibility of using a domain name. > > With my well-known registry expert hat on - I've got a TODO to produce some documentation on considerations for well-known URIs. I'd be interested to hear more about why some operators find it difficult to modify a file on a HTTP server but presumably can easily change DNS. See my mail: https://mailarchive.ietf.org/arch/msg/dnsop/oGjGfsb-Gs6PMhLqKcQlXHpNi2E/. It's **not** that modifying the apex domain http server is difficult. It's a layering problem. This [image shamelessly stolen from geeksforgeeks.com](https://media.geeksforgeeks.org/wp-content/uploads/20221228112413/Cloud-Computing-Layers.png). DNS lives in the infrastructure layer. Identity lives in the platform layer. The http server for the apex domain lives at the application layer, like the http server for any other application. Platform layer components shouldn't depend on application layer components. Even putting layering aside, there's a simple "number of dependencies" argument. More dependencies means less reliability. Today's OAuth flows have two dependencies - IDP and DNS. If FedCM flows have three dependencies - IDP, DNS and APEX - that's a comparative technical disadvantage. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1217#issuecomment-4226519044 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1217/4226519044@github.com>
Received on Friday, 10 April 2026 20:21:25 UTC