Clients MUST start by making a GET or HEAD request to [Fetch] the user's profile URL to discover the necessary values. Clients MUST follow HTTP redirects (up to a self-imposed limit). If one or more successive HTTP permanent redirects (HTTP 301 or 308) are encountered starting with the very first request, the client MUST use the final permanent redirection's target URL as the canonical profile URL. If any other redirection (such as HTTP 302, 303, or 307) is encountered, it must still be resolved for endpoint discovery, but this redirection does not modify the canonical profile URL, nor do subsequent permanent redirects.
This always refers to the URL provided by the user who is trying to log in as "the user's profile URL". This could be confused with a User Profile URL as defined in section 3.1. But Discovery is not meant to be limited to take such a strict URL as a starting point.
See simonw/datasette-indieauth#21 for one example of such confusion in the wild.
Giving this starting point a better definition in the specification may also be a good moment to document the example use-case where you just provide the domain of the service you wish to identify with. There is nothing stopping Twitter to advertise IndieAuth endpoints on twitter.com. That would allow anyone to just write twitter.com in an IndieAuth login field and be directed to authorise with their Twitter account. Something that is supported by the IndieAuth protocol but often overlooked.
One question that remains is: because Discovery tries to establish a canonical profile URL (after redirects), what happens if the non-valid provided URL (e.g. http://aaron@parecki.com/) does not redirect at all? At this point the Client might have been able to discover correct endpoints, but still does not have a canonical profile URL that fulfills the criteria of section 3.1.
A possible solution could be provided by #56. Because that goes and validates the final me value it would not technically need to establish a profile URL at the start of the flow at all.
From 4.1. Discovery by Clients:
This always refers to the URL provided by the user who is trying to log in as "the user's profile URL". This could be confused with a User Profile URL as defined in section 3.1. But Discovery is not meant to be limited to take such a strict URL as a starting point.
See simonw/datasette-indieauth#21 for one example of such confusion in the wild.
Giving this starting point a better definition in the specification may also be a good moment to document the example use-case where you just provide the domain of the service you wish to identify with. There is nothing stopping Twitter to advertise IndieAuth endpoints on
twitter.com. That would allow anyone to just writetwitter.comin an IndieAuth login field and be directed to authorise with their Twitter account. Something that is supported by the IndieAuth protocol but often overlooked.One question that remains is: because Discovery tries to establish a canonical profile URL (after redirects), what happens if the non-valid provided URL (e.g.
http://aaron@parecki.com/) does not redirect at all? At this point the Client might have been able to discover correct endpoints, but still does not have a canonical profile URL that fulfills the criteria of section 3.1.A possible solution could be provided by #56. Because that goes and validates the final
mevalue it would not technically need to establish a profile URL at the start of the flow at all.h/t @simonw for pointing this one out!