Seemless Single Signon

[Brad Fitzpatrick]

Sam, Mart,

What Sam wants is (kinda) this, starting with a similar method that won't
work:

-- he wants to enter http://www.intertwingly.net/ as his identity

-- the helper on the target site he's visiting will fetch that
   and look for a <link> tag.  it finds:

     <link rel='openid.server' href='http://localhost:2341/' />

-- The MyPersonalIdentityServer.exe running in his system tray
   then gets an HTTP request on port 2341 and pops up an
   identity validation grant request dialog.  He clicks "okay",
   and his personal webserver running in MyPersonalIdentityServer.exe
   then sends the DSA signature to the browser's redirect, and
   all happens as normal.  EXCEPT.....

   The validating service can't connect to that guy's localhost
   to get his public key.

And he wants it to run inside Mozilla/IE, which means it can't
really listen on a port (easily?), so he'd want something more like:

     <meta name='openid.public_key' value='base64(public_key)/' />

And then the DSA signature is sent (from JavaScript) using the
in-Mozilla-stored/managed private key.

Could work.  The idea of a local identity server is appealing at least.

- Brad



On Fri, 20 May 2005, Sam Ruby wrote:

> I've seen greasemonkey and bookmarklets mentioned in this mailing list,
> but only in the context of pre-filling in fields and the like.
>
> So much more is possible.  Much more.
>
> If you recognize that the desired end result is a specific DSA
> signature, and that many of the clients are able to perform logic and
> via the user at the keyboard potentially have access to all the same
> secrets that the server has, you can streamline everything.
>
>   - - -
>
> Brief outline, from a user's perspective.  I'll pick greasemonkey, but I
> imagine once a proof of concept exists, fans of other browsers will
> quickly provide equivalents.
>
> 1) User installs greasemonkey script.  Possibly tailors a few things
> like how long logins are valid for (paranoid=5 minutes, normal=1 hour,
> unconcerned=1 day).
>
> 2) User visits web page.  The Verify button is replaced with a login
> button.  User enters the URI and presses login.  This pops up a window
> locally and prompts for a master password.  Once the user enters the
> correct password, the popup goes away, the input field becomes readonly,
> and the login button gets replaced with a logout button.  Note: no
> server interaction, no delays occur.  User continues and ultimately
> submits the form.
>
> 3) User visits a second web page, on a different site, before the login
> expires.  The URI is again prefilled in, is again readonly, and the
> verify button is again replaced with a logout button.  The user need not
> perform any overt action to continue.
>
>   - - -
>
>  From a technical perspective, this is not very difficult to pull off.
> There are plenty of simple greasemonkey scripts that do much more than
> this to borrow techniques from.  What is required is:
>
> 1) the form itself needs to be standardized enough so that it can be
> readily and reliably identified by the greasemonkey script.  This can be
> as simple as agreeing on a class name.
>
> 2) every piece of information necessary to produce the signature needs
> to be similarly readily available.
>
> 3) the algorithm for computing the signature needs to be something that
> can be implemented in JavaScript.
>
> - Sam Ruby
> _______________________________________________
> yadis mailing list
> yadis at lists.danga.com
> http://lists.danga.com/mailman/listinfo/yadis
>
>