immediate mode consumers

[Brian Ellin]

A couple of days ago I started working on an immediate mode OpenID
consumer.  I noticed a couple of things that I'd like to get some
feedback on, especially as the OpenID 2.0 spec gets rounded out.

1) The spec 1.x spec doesn't clearly state what the action at
openid.setup_url should do.  Most live openid servers simply generate
a setup_url that switches the openid.mode from checkid_immediate to
checkid_setup, but the behavior of the setup_url isn't described very
clearly in the spec.  As a consumer author I'd like to know what is
going to happen when I send the user off to the setup_url in a new
window.  Will they get redirected back to my site?  Should I display a
message telling them to come back and click "login" again once they
have logged into the server?  It totally depends on what happens at
the setup_url.

2) Since immediate mode requests are usually made from a hidden iframe
in the user's browser, the openid response handler must generate some
javascript which then updates the DOM of the page, or opens a new
window with the setup_url. Since the setup_url uses the return_to of
the immediate mode request, the checkid_setup response (in the new
window, not the hidden iframe) renders the javascript response
intended for the immediate mode response.

It is possible to write javascript which can determine if the response
is from an immediate or setup checkid request, but it involves doing
something which checks for an element that won't exist on the setup
response page.  I don't like this solution:

var div = document.getElementById("immediate_mode_message");
if (div) div.innerHTML = "Logged In";
else window.location = 'http://example.com/logged_in';

The feeling I get after implementing an immediate mode consumer is
that the setup_url is weird and has the potential to introduce
inconsistency.  If all of the servers are just going to generate a
setup_url which is a checkid_setup request, then why not just let the
consumer do it?  When the immediate mode response says that the user
can't be logged in, the consumer could just generate it's own
checkid_setup request using a return_to designed to properly handle
those kinds of requests.  No javscript hacks required.

So, I'd like to see the setup_url described in more detail in the
spec, or tossed out for OpenID 2.0.  Thoughts?

Brian Ellin
JanRain, Inc.