Non-browser Identity Verification

[Brad Fitzpatrick]

On Wed, 18 May 2005, Martin Atkins wrote:

> Brad Fitzpatrick wrote:
> > On Wed, 18 May 2005, Martin Atkins wrote:
> >
> >
> >>The local web server approach will never work because no-one with any
> >>sense allows arbitrary incoming connections from the Internet. Some
> >>people explicitly block it, others just use some wacky NAT setup. Your
> >
> >
> > No connection is coming from the outside!
> >
>
> Right you are. I didn't think it through properly.
>
> This still seems like a lot more effort than it should be, and has its
> own issues:
> * The user will be asked to approve an assert to the localhost URL, and
> clicking "Yes; forever" won't work because it'll use a different port
> number each time.

So identity server only supports "Just this once" when it's a local
service connecting.

Maybe the return_to_url is:

    http://127.0.0.1:23423/MusicBrainz

And then the identity server says:

    Do you want to trust the application "MusicBrainz" on your local
    machine to verify your identity?

Neat, eh?  :)

> * Clients still need a whole browser to display the HTML and JavaScript
> crap that the identity server returns.

Naah, client invokes the system browser.  I wouldn't trust the app's
browser widget anyway.... I want to see my IE/Firefox/Opera window and
know that that's who I'm authenticating with.

> I have a working (if a little hacky) implementation here of a headless
> (as in no browser) client which parses the Location header. The only
> hole I can't fix is that I have to copy the authorize URL to my browser
> and hit the "Yes" button. (I've currently got a valid LJ session cookie
> hardcoded into the program, which is how it manages to get that far.)

C'mon, do the webserver.  I've seen you do 10x cooler/sicker hacks.  I've
written dumb-ass webservers from ~20 lines of Perl.

> >>The silly thing is that the browser mode is really the special case.
> >
> > That's classic Mart right there.  :)
> >
> > That's the case I'm working to solve.  Go join one of those theory working
> > groups and I'll see your implementation in 10 years.  This is about
> > solving the common case today.
> >
>
> Perhaps so, but what we've got right now is less a protocol and more
> just a hack exploiting current browser behavior. The completely pure
> approach would be to change the browser to support the clean protocol,
> but all I'm asking is for a little change to the hack protocol so that
> software that isn't a browser can still play.

Then think of OpenID as "exploiting" current browser behavior.  An exploit
so terrible that it works in all 3 major browsers.  We didn't find a hole
that everybody had.  Sites have been doing this sort of thing on the net
forever to share cookies between domains.  But usally for marketing
reasons, not good reasons.

Really, we're not designing a protocol here.... we're making a scheme that
works.

- Brad