DNS option instead of well-known URI

[aaronpk]

Right now, for a configURL of https://accounts.idp.example/config.json it requires the IdP host a file at https://idp.example/.well-known/web-identity. As mentioned in other discussions, this can be somewhat of a burden in certain cases, which was the motivation for moving all the dynamic data to the config file in the first place.

It seems that an analogous version of this verification could be done in DNS instead. So for a configURL of https://accounts.idp.example/config.json, the browser would look for a TXT DNS entry:

idp.example TXT "v=fedcm1 config:https://accounts.idp.example/config.json"

(I don't care about the format, I was just basing this off of SPF records.)

You could even use the same redirect model used for SPF records:

idp.example TXT "v=fedcm1 redirect=_spf.idp.example
_spf.idp.example TXT "v=fedcm1 config:https://accounts.idp.example/config.json"

In many cases it's much easier to roll out DNS entries than it is to host a file at the top-level domain of a website.

[wparad]

Wow, that's a great idea. I haven't thought this all the way through, but something something, might also help avoid part of the tracking the problem entirely if switched to using DNS in the first place rather than the potentially the double request that is currently happening at this moment.

However, on the same token, I'm also concerned with this. Using the same argument one could easily say, gosh if we own the configuration for the accounts.idp.example it is so much easier for us just to having support for deploying a file at the .well-known location, than it is to get approval to roll out a DNS change at the top level.

If we think about certificate validation and dmarc as two examples. cert validation supports both DNS and HTTP, while lots of services make support for DNS easy, very few support HTTP, and with HTTP, it's arguably easier since it avoids the HTTPS circular dependency on resolution.

For DMARC, there is a defined _dmarc subdomain prefix that is canonical and allows separating out the resolution so that there isn't Yet One More Thing in the top level TXT record. So if we go down this path, that feels like a possible improved optimization, e.g. having _fedcm.idp.example with the necessary configuration.

In the end however, honestly, I hate that this only exists to prevent tracking, and that it can potentially be defeated via a timing attack to correlate requests. I wonder if there really isn't any other way. e.g. Would a registery like the HSTS preload one work here? Then only one request would ever need to be available. I feel like there are way less Federated Identity Providers than the current list supported for HSTS so the list would be even easier to manage, often this list is very closely related, and this would both default tracking as well as not having to make multiple requests, and also defeat timing requests.

[aaronpk]

Forgot to add, it's not just making a file available at /.well-known/web-identity, it's also serving it with the application/json content type, which is an extra barrier as well. Even on my relatively simple nginx+PHP VPS setup, I had to edit the nginx config file to add the content type header. This process will vary wildly depending on the hosting platform as well, since any home page served as a static site would require customizing the header in the hosting provider if it's even possible to do so. (I'm thinking about for example large organizations who have their marketing department host the home page, or even outsource that to an external agency, then provide subdomains for actual applications.)

[wparad]

Yeah, if the Content-Type set correctly is requirement, this is definitely a non-starter for many deployments. By default there will be so many out there that will run into problems because they accidentally set the content type to binary/octet-stream. I would assume the content-type should be ignored by browsers at least, but having the alternative to use DNS....

Hmmm, in order to support both mechanisms, that would require three calls on init, the DNS, config.json, and the .well-known, in order to not be blocked and execute in parallel. The more options we have the more, it seems like validating the config.json doesn't contain tracking is fundamentally wrong.

[obfuscoder]

I like the idea of employing DNS. I wonder if it would even be possible to - instead of setting the configURL in the client - just provide the eTLD+1 of the IdP in the client and the browser fetches the configUrl from the DNS entry. That said, there should always be the option to default to configURL - /.well-known/web-identity if adding/changing arbitrary TXT entries to DNS is not possible for some IdPs.

[aaronpk]

The client is going to always have to start from the configURL in order to support IdPs that need to use multiple configURLs for whatever reason.

[samuelgoto]

I like this idea too, and, back of the envelope, it feels to me like it would fly through privacy and security considerations, so purely an ergonomic benefit.

Would it be fair to say that this is a "nice to have" but that we should get some of the bigger boulders, such as #2, out of the way first?

it's also serving it with the application/json content type, which is an extra barrier as well

Yeah, I hear you.

I'm a github pages user myself hosting https://code.sgo.to, so my personal goal is to find a way expose a github page as a FedCM IdP. For example, I love the type of deployments where you can delegate the dynamic parts to another server, such as webmention <link rel="webmention" href="https://webmention.io/username/webmention" /> and <rel rel="me" href="https://github.com/samuelgoto">, which can fundamentally change the deployment costs for IdPs.

[aaronpk]

Yep that's exactly the road I was going down with this, trying to make it as easy as possible to set up a new FedCM IdP where all the dynamic parts are provided by an external service. But yeah I'd say this is lower priority than IdP registration.