Browser Login Plugin

[Brad Fitzpatrick]

URL to consumer's private key?  Ouch.  :)  Yeah, I know what you mean.

But really you want the comment to go to your own identity server ("blog
host") where you can review the comment text, make sure it hasn't been
altered, and have your identity server sign it.  But that seems like
something that can be added on later.

If consumers had private keys (which would suck as a requirement... too
much pain), then what do they get from signing a trackback?  What does,
say, LiveJournal benefit from getting a trackback that's singed from
someblog.com?  That we know it came from someblog and can trust it?  We
can't trust the contents... so that the origin is correct?  I'm not
bashing this idea... I just don't fully understand what's being
verified/protected.

- Brad


On Fri, 20 May 2005, Ben Nolan wrote:

> I'm with Brad on this one. openid_url is much simpler. The one thing that I
> could see as being useful would be if we specify that the trust_root is
> somewhere in the form (as a hidden field say) - that way the bookmarklet /
> greasemonkey plugin could automatically add the trust_root to the users
> trusted sites *before* it fills out openid_url and submits it.
>
> That makes the process truly one click.
>
> An aside: I think the protocol should have support for consumers having
> private keys from the get-go, this way a consumer could send a signed
> trackback to the users weblog and if the consumer is on the trusted_root
> list - we can auto-add the trackpack / comment ping.
>
> EG - the call from the consumer site to the IDServer should include the url
> to the consumer private key (optional) - and the idserver should record that
> url.
>
> Regards,
> Ben
>
> On 5/20/05, Brad Fitzpatrick <brad at danga.com> wrote:
> >
> > 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,
> > it can just submit, or javascript could intercept.
> >
> > 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<http://radfitz.com>].
> > I heard
> > that's what the WHATWG is trying to standardize anyway... just little
> > naming conventions.
> >
> > - Brad
> >
> >
> > 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
> > > http://lists.danga.com/mailman/listinfo/yadis
> > >
> > >
> > _______________________________________________
> > yadis mailing list
> > yadis at lists.danga.com
> > http://lists.danga.com/mailman/listinfo/yadis
> >
>