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://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]
