Browser Login Plugin
brad at danga.com
Thu May 19 10:25:03 PDT 2005
Why not ditch the extra link tags, and just make the browser auto-fill the
first form element named 'openid_url' and submit the form? If done right,
The added advantage of everybody using one name like "openid_url" for that
field is that browsers will naturally prefill it as you type the first
letter in it.... I type "b" and browser says b[radfitz.com]. I heard
that's what the WHATWG is trying to standardize anyway... just little
On Thu, 19 May 2005, Martin Atkins wrote:
> (Longest proposal message yet... but you can ignore the bit between the
> dashed lines if you trust me that it'll work!)
> Brad and I talked about this a little back when he first proposed it.
> Now that I actually know how OpenID works, I'm in a better position to
> make a proposal.
> The idea here is that frequent OpenID users will install a browser
> plugin which will add a "Log in with OpenID!" button to their browser.
> The user will have preconfigured an identity to use. When clicking this
> button, the browser will do the client-side part of the process locally
> and just hand off the authorisation token to the consumer site.
> The plugin needs a clue on the consumer site about how to interface with
> its OpenID code. We add some discovery stuff to the head of the
> consumer's HTML document:
> <link rel="openid.returnurl"
> href="http://someconsumer.com/openidhelper" />
> This is equivilent to the return_url in the normal request and will be
> used as such when the plugin sends the authorisation request.
> For the sake of AJAX-like logins:
> <link rel="openid.returnhook" href="openid_login_hook" />
> (I know LINK is totally the wrong element for this, but for
> illustration's sake ignore that for the moment.)
> openid_login_hook is the name of a script function in the 'window'
> object which accepts the parameters (identity, timestamp, token) and
> does whatever is necessary to make the UI look like the user has logged in.
> Where a site specifies both, it'll be up to the plugin whether it does
> it the fancy scripting way or the classic way. I imagine a trust_root
> will need to be specified as well, so that the ID Server can use it to
> do the approval.
> This is a convention for the consumer to follow; it doesn't affect the
> ID server at all.
> On clicking the login toolbar button, the browser discovers and sends a
> request to the identity server. It'll get back a redirect whose query
> string it can parse to figure out what's happened. The response can be
> used to either open a window to do the authorisation or to trigger the
> hook to give the site the login token.
> The fancy mode requires that the browser extension API has some way to
> make a HTTP request with the right cookies and catch and parse the
> redirects rather than letting them happen. It also requires the ability
> to run a named function within a loaded document *with the priviledges
> of that loaded document*.
> A more simple plugin, though, can just make the ID server request in the
> browser view and let the redirects take their course so that the user
> eventually ends up at the redirect_url. The only complicated part is the
> request to the Identity URL to auto-discover the ID server, but that
> doesn't require any cookies or auth.
> If the user has permanently approved a given consumer and is logged in
> to the identity server, clicking the toolbar button on that consumer
> site will do a login in one click with no typing necessary, and that's
> the point of all this.
> A Firefox extension to do this shouldn't be too hard. However, I've
> never written a Firefox extension before, so if someone else fancies
> doing it then please speak up to save me having to learn it! :)
> Doing this as an Internet Explorer toolbar extension shouldn't be too
> hard, either.
> Please let me know if I've missed anything important! :)
> yadis mailing list
> yadis at lists.danga.com
More information about the yadis