Non-recoverable auth failure?

[Carl Howells]

Martin Atkins wrote:
> 
> The AJAX version is a little convulted, as you have to click a link to
> find out that you are denied. I think this is a quirk of the AJAX mode
> in general, though. Indeed, I was talking about fixing it in another
> thread recently:
>     <http://comments.gmane.org/gmane.comp.web.openid.general/569>

This actually strongly echoes my second remark, which you didn't respond 
to.  What's actually done with the user_setup_url seems needlessly 
painful in the current system.  I think that should be cleaned up, 
regardless of any other action taken.  I'll talk about this more in a 
minute.

My real motivation here is making the checkid_setup user interface 
simpler, though.  Here's the sequence I have in mind.

1. User goes to a new site, foo.com
2. User enters their openid url, http://me.livejournal.com/
3. The consumer attempts to verify the url in checkid_setup mode.
3. User is taken to livejournal.com, and presented with the "do you want 
to allow this site to know your identity?" dialog.

And suddenly, there are a bunch of user interface questions.  Does this 
page have a "no" button?

* If not, what are they supposed to do if they decide not to allow that 
trust root to know their identity?  There are a lot of users that will 
ignore whatever text is present, and wonder how they can say "no".

* If there is a "no" button in place to make those users happy, what 
should it do?  I think the action that would be least surprising to the 
user would be to be returned to the site that they were previously 
browsing.  But how does the consumer do that?

If there was any kind of "didn't authenticate, won't authenticate, don't 
bother" response the server could send to the consumer, this would be an 
ideal place to use it.  The server would just send that response via 
redirect to the consumer, and the hopefully the consumer would show a 
reasonable page, letting the user continue on in a manner that feels 
natural for them.

As it is, there's no reasonable behavior for a "no" button to have, yet 
the lack of a "no" button will greatly disturb many users.  That's the 
reason I believe there should be a way for the server to tell the 
consumer "They didn't authenticate.  They won't.  Continue on without 
authenticating them."

As for AJAX mode...  This is how I think the flow for it *should* work. 
  Making it work this way will require some minor changes to the spec, 
though.  (One of the guys in my office tells me some of the details 
might need to be finessed to work with the browser's security model for 
popups, but the overal effect would be as described here.)

success case:
1. User enters their openid url into a box and hits "log in"
2. Browser uses hidden iframe to begin openid transaction.
3. Server determines no user input is necessary to complete the 
authentication, return a redirect to a properly constructed return_to url.
4. The return_to url is loaded in the hidden iframe, verifies the 
signature is valid, and returns a page with a javascript onload handler 
that notifies the containing page that the authentication has succeeded, 
and the containing page continues however is appropriate.

"user input needed to authenticate, and is provided successfully" case:
1. User enters their openid url into a box and hits "log in"
2. Browser uses hidden iframe to begin openid transaction.
3. Server determines user input is necessary to complete the 
authentication, return a redirect to a properly constructed return_to url.
4. Consumer returns a page to the hidden iframe with javascript to 
create a popup going to the user_setup_url.
5. User enters whatever information is necessary in the popup, the 
server determines it is sufficient, and then sends a redirect (in the 
popup) back to an "openid.post_setup_url" which was included in the 
request to the user_setup_url.
6. The consumer verifies the signature, and then loads a page in the 
popup containing javascript to close the popup and notify its parent 
that the request was successful.

"user input needed to authenticate, and is not provided" case:
1. User enters their openid url into a box and hits "log in"
2. Browser uses hidden iframe to begin openid transaction.
3. Server determines user input is necessary to complete the 
authentication, return a redirect to a properly constructed return_to url.
4. Consumer returns a page to the hidden iframe with javascript to 
create a popup going to the user_setup_url.
5. User is unable to authenticate for the url, or simply decides not to. 
  The server sends back a redirect containing a "didn't authenticate" 
response to the openid.post_setup_url.
6. The consumer recognizes that the user didn't authenticate, and 
creates a page to close the popup and notifiy the parent that the 
authentication was unsuccesful, so the parent page can take whatever 
action is appropriate in that case. (Probably just along the lines of 
re-enabling widgets that it disabled during the authentication attempt.)

For the first case, the current spec is sufficient.

For the second case, changing the openid.post_grant field to an 
openid.post_setup_url field would be sufficient.  It results only in an 
increase in functionality, and has the side effect of not requiring the 
original return_to url to be encoded into the user_setup_url, which is a 
plus.

For the third case, an explicit "didn't authorize" message, as argued 
for above, would be necessary in addition to the changes for the second 
case.

I believe the minor changes described in this email would result in a 
large increase in ease of use for the end-user, with little or no 
downside.  Please put some thought into this from the perspective of how 
the user will interact with it.  With the current specs, I don't see how 
it's possible to create interactions as smooth as the ones I've 
described above.

Carl