Non-recoverable auth failure?
brad at danga.com
Fri Jun 24 12:43:47 PDT 2005
On Fri, 24 Jun 2005, Paul Crowley wrote:
> Brad Fitzpatrick wrote:
> > We're absolutely not encouraging the use of OpenID server UIs in
> > consumer-initiated pop-up windows.
> OK, but what do you think on the broader point of abolishing
> user_setup_url in favour of checkid_setup?
I've been thinking about it all yesterday and this morning, and I can't
see how it simplifies things. It puts more state tracking work on the
consumer sends UA to:
server declines auth and redirects user to:
Now the consumer has to go re-fetch the identity URL (perhaps from
cache) and lookup the identity server URL again.
So I think user_setup_url eliminates some work. Even if we did accept
that the above step wasn't too much work, I'd guess that most servers
will implement the server interface and setup interface on two
seperate URLs, so sending a UA to server.app?mode=checkid_setup will
_more than likely_ just result in that user being redirected again to
that identity server's setup url.
I might yet be convinced, but I'm leaning towards keeping things as
I'm getting a little tired of changing the protocol for increasingly
smaller gains (and in this case, perhaps even no/negative gain?)
openid.mode=cancel I'm still liking, though. That's an easy addition.
Changing post_grant I'm still debating: perhaps it just needs to be
documented that post_grant=return is implied in checkid_setup mode,
which just leaves post_grant=close for closing new windows. And it
seems a little silly to redirect the UA to another URL whose sole
responsibliity is doing "window.close()" when that'll be such a common
request from consumers. HOWEVER-- I like the possibility of a
post_grant_url being able to complete the final click of an AJAX-style
login box without the login box having to do checkid_immediate
polling. But I think you can do that with postgrant=return anyway, so
I have to think about this more.
More information about the yadis