Will Norris wrote:
The document you mention all but actually recommends that approach:
There are two locations where the host-meta document might be found:
(1) http://example.com/host-meta
(2) https://www.google.com/accounts/o8/host-meta?hd=example.com
Google's endpoint will return a 400 on endpoint (2) if the domain
provided has not outsourced OpenID IdP funcionality to Google. So one
possible strategy for an RP could be to first try endpoint (2), and if
that returns a 400, try endpoint (1), and if that doesn't yield
anything, give up. Other strategies (fetching both endpoints in
parallel, for example), are possible.
The idea of trying endpoint #2 first, and then failing back to #1 should
NEVER be proposed or encouraged. Quite the opposite, it should be
strongly discouraged. It's language like this that make this feel like
a vendor-specific approach that the OpenID Foundation should have
nothing to do with. RPs should be instructed to ALWAYS attempt #1
first, otherwise the domain owner is no longer in control.
This is also a pretty good argument for why "magic" paths under a domain
are bad, and is a good example of the issue I brought up months ago with
relying on HTTP for discovery: a domain's website is very often hosted
by a completely different organisation than the one that hosts
everything else.
I even used Google Apps as an example in my original blog post about
this back in October:
http://www.apparently.me.uk/19059.html
_______________________________________________
board mailing list
[email protected]
http://openid.net/mailman/listinfo/board
