Make it easier to deploy this at the eTLD+1 for registered IdPs

[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.

There are currently two separate issues tracking alternatives to this requirement:

• DNS option instead of well-known URI #9 create the linking in DNS
• Skip the .well-known check for Registered IdPs #4 skip the check for registered IdPs

This issue is just to track the higher level problem of the difficulty of deploying this as describe in the current spec. Either of the above issues can resolve this issue.

[samuelgoto]

Just to give a small update on what we've discussed so far with chrome's privacy reviewers:

https://github.com/fedidcg/FedCM/issues/613 skip the check for registered IdPs

So far, we haven't found anything massively incorrect about #4 , so we are going to try to build a prototype and see where that takes us. Will report back.

https://github.com/fedidcg/FedCM/issues/580 create the linking in DNS

#9 would also likely require us to check for APEX / root domains rather than subdomains, because DNS entries for subdomains would have - i think - the same attack vector as .well-known in subdomains: entropy.

[aaronpk]

https://github.com/fedidcg/FedCM/issues/580 would also likely require us to check for APEX / root domains rather than subdomains

That's fine, for these types of deployments DNS is all managed at the root domain anyway

[samuelgoto]

That's fine, for these types of deployments DNS is all managed at the root domain anyway

Ah, interesting! Well, that's great to hear, because I think #9 would be substantially easier for us to implement compared to #4 !

@anderspitman do you think that #9 would be a reasonable resolution to #4 ? Would #9 allow you to deploy FedCM-As-A-Service to your users without asking too much from your users?

[anderspitman]

@samuelgoto it might be workable but it's definitely not ideal. The use case I'm working toward involves the user delegating control of the subdomain idp.example.com to LastLogin. That creates a very clear permission boundary for what LastLogin can do. I believe #9 would require the user to delegate control over idp.example.com, and the ability for LastLogin to create a TXT record on the apex domain example.com. This opens up a whole bunch of other potential vulnerabilities. LastLogin could create tons of TXT records, delete records that are already there, modify them, etc. This would require a lot of intricate scoping that simply isn't necessary if you can restrict the blast zone to a specific subdomain.

[aaronpk]

@anderspitman can you ask the user to configure the DNS entry themselves?

[anderspitman]

@aaronpk unfortunately that defeats the entire purpose of what I'm trying to do. The vision of TakingNames is to make domain names as easy (or easier) to have/use as phone numbers. That's going to require a dramatic reduction in complexity for the end-user. The average person simply should not be expected to have to manage their own DNS records, when apps (LastLogin in this case) know exactly what records they need to set and it would be quite straight forward for domain registrars to delegate access over OAuth2. This concept is already in the wild with the Domain Connect protocol, but in practice that has turned into a rather closed ecosystem.

More background here: https://takingnames.io/blog/introducing-takingnames-io

[aaronpk]

If you really want it to be as easy as phone numbers then it's fine to delegate the entire domain to the service, just like what happens with phone numbers. I trust my cell provider enough to port my number to them, and I trust that I will be able to port the number away to a different provider when I want. It's even better with domains because I can move the domain to another provider without the cooperation of the current service providing DNS and web services, and it's equivalent if they are also the domain registrar.

[anderspitman]

In this case the service that would need the entire domain delegated is LastLogin, which wouldn't work because LastLogin only supports operating as an IdP. Presumably users would also have other services, such as email, blogging, cloud storage, etc that they would want to dedicate subdomains to. Only a select few apps (maybe a blogging service if you want your website hosted at your apex) should require access to an apex domain.

[aaronpk]

Remember that the only thing required at the top level domain is the DNS verification record, the IdP can still be running at a subdomain.

Something somewhere has to manage DNS for the domain. If you want it to be easy to use without understanding DNS, then somewhere the user will be delegating control over management of the DNS records to the various software they use. So there are two scenarios:

• Nameservers are pointed at LastLogin, and LastLogin controls all the DNS records, making it easy to set the eTLD+1 record for FedCM (example.com), and creating the subdomain for the LastLogin service (e.g. id.example.com). Any other software the user uses at the domain would need to be configured with DNS entries at LastLogin, which theoretically could be done with an OAuth system like Domain Connect.
• Nameservers are pointed at some other service, and LastLogin needs to go configure the CNAME for the LastLogin subdomain. Assuming you don't want users to have to understand this, you do some OAuth Domain Connect thing to configure the DNS record for them, at which point you can also create the DNS entry at the eTLD+1.

[anderspitman]

My system falls under the second case. TakingNames is the service that has control over all the user's domains (it also operates as a domain seller, which creates many other opportunities to improve UX), and operates as an OAuth2 server. LastLogin is just a client.

The problem is when you consider the actual UX. Here's what I'm hoping for:

1. User is on LastLogin and is presented with a button that says "Add a Domain with TakingNames"
2. They click the button and are redirected
3. TakingNames presents a page that says "https://lastlogin.io wants control over a subdomain. Select a domain from the dropdown and enter a host to create a subdomain"
4. They're redirected back with a token LastLogin can use to set up the CNAME

If it's required to use an apex domain, I haven't been able to come up with a UX that wouldn't be super confusing for someone who doesn't understand DNS. It would also be difficult to implement at the protocol level. The client would have to request a subdomain for the IdP, but also permission to set a TXT record on an apex domain. If a user has 2-3+ domains, it further complicates the possible valid combinations. How do you express the how and why of this to the average person?

If FedCM can be made to work on a subdomain like most other services, all this complexity goes away.