Discovery 2 - No means of discovery without web server for domain

[Michael Jones]

Currently, discovery is impossible when there is no web server for a domain, as the specifications perform discovery by doing a GET on an https /.well-known URL. Yet many hosted e-mail domains have no corresponding web server to respond to http and https requests.

We could choose to enable discovery for these domains, but it would require specifying a different backup discovery mechanism.

[Nat Sakimura]

Simple Web Finger with an A record with fixed host name "discovery", so that if the domain was foo.com, discovery.foo.com would be the fall-back name for the host to find the .well-known.

To be assigned to Pam.

[Pamela Dingle]

Hi all,

More details on the possible solution discussed on the May 24th working group call:

The first place for the host to find the .well-known is at the root of the target domain. If the .well-known is not found, the next action is to prepend some kind of well known subdomain to the front of the target domain and check there. We had discussed something like "disco" or "discovery". For example, if the user's target domain is identified as pingidentity.com, but the .well-known is not found at http://pingidentity.com, the next place to look would be http://discovery.pingidentity.com.

There are practical advantages to this plan. The hostname of "discovery.pingidentity.com" is represented by an A record, which means that an unsophisticated owner of a domain could be given simple instructions on how to add a new hostname to their DNS provider in order for an OpenID Connect service to host configuration files without impacting separate mail hosting or web hosting setups. An example of this might be that a user uses Dreamhost for web hosting and email, where Dreamhost will not yet support OpenID Connect. In this case the user can neither add the .well-known to the root of the domain, nor assume that the MX record will point to a .well-known file (another discussed alternative that was proposed). In this example, a service external to Dreamhost could take over the hosting of the .well-known, simply by having the domain administrator create a new A record called discovery.domain.com and point it to the hosting service.

Disadvantages discussed included possibly impinging on already-used domain real estate - however if the domain is serving a large enough organization for the hostname "discovery" to be used, it is likely that the primary domain is under enough control to host the original .well-known, making the use of the secondary domain unnecessary.

The group in general thought this idea was practical, however it was observed that it would not be a popular solution with the purists in the crowd. There is precedent for this kind of solution however, in that A records are commonly created for hosted mail and calendar services so that webmail and calendar interfaces can be hosted and managed separately from hosted websites.

[Michael Jones]

Mike suggested that, while it still won't make the purists happy, we'd be less likely to encounter naming conflicts if we used the name "discovery-fallback" in the domain, rather than "discovery".

[Michael Jones]

There's also the possibility of using dedicated hostname prefixes such as simple-web-discovery. or webfinger., as previously discussed on the calls. However Mike had earlier raised the issue of possible certificate difficulties when using such dedicated hosts.

[Michael Jones]

This is currently achieved with the "simple-web-discovery." domain prefix in draft-jones-simple-web-discovery-04. The domain prefix solution was also added to draft-ietf-appsawg-webfinger-04 but was removed from draft-ietf-appsawg-webfinger-05 after Google decided that they were withdrawing their requirement for support for disovery for hosted domains.

[Michael Jones]

Eric and Breno believe that Account Chooser will do discovery for hosted accounts, so this functionality won't be critical. However, this may not work in the first-time case unless the account issuer pushes the account into Account Chooser.

[Michael Jones]

Given demand for this feature seems to have evaporated, I am placing this one on hold for now.

[Michael Jones]

Account Chooser is a possible workaround to this