Non-browser Identity Verification

[Brad Fitzpatrick]

Oh, even better:  the not-a-website app can run its own webserver on an
ephemeral port:

   Location: http://127.0.0.1:2384/?openid.user_setup_url=......

*ducks*

Okay, I think I hear you now.  Not all client apps (consumers) will use an
HTTP library that uses the "system's" cookies, which is unreliable anyway,
since what browser is the system one?  But you're still going to invoke
their default browser anyway, right, to send them to their homesite to do
their auth?  Otherwise they're giving their password to the consumer app,
which is scary.

So shit, the local webserver actually is sounding nice.

- Brad


On Wed, 18 May 2005, Brad Fitzpatrick wrote:

> Why can't the non-browser consumer just parse the redirect URL?  It's also
> URL-escaped.
>
> The non-browser consumer can send a "return_to" URL of
> "http://I_AM_NOT_A_WEBSITE" and the identity consumer will happily
> redirect the user to:
>
>    Location: http://I_AM_NOT_A_WEBSITE?openid.user_setup_url=......
>
> What am I missing?
>
>
>
> On Wed, 18 May 2005, Martin Atkins wrote:
>
> > Martin Atkins wrote:
> > > The current scheme is (as far as I can see) bound to the browser. If
> > > this is to become some amazing used-everywhere identity system, I think
> > > it's important to support non-browser-based auth too. I suspect it might
> > > already be supported in some sense, but let's think about it a little
> > > anyway.
> > >
> > [...]
> >
> > Having pondered this, I think the sanest approach here is to simply have
> > two request modes. The "browser" mode is what we have now. The "raw"
> > (better name please) mode differs as follows:
> >
> > * Responses from the ID server are, rather than redirects to a URL,
> > instead a 200 OK response of type application/x-www-form-urlencoded
> > containing the url-encoded response parameters. Non-success responses
> > can use other response codes, such as 403 for "I don't know how to
> > assert that identity at all".
> >
> > * When the client makes the request to the ID server, the server
> > response with a 401 Unauthorized response and a WWW-Authenticate header.
> > The client must then prompt the user for a username and password and
> > make another request. Using cookies for authorization is expressly
> > forbidden in raw mode because entering the username and password is
> > taken as implied permission to assert the identity: there is no trust
> > root or reply URL outside of the browser scenario.
> >    If Cookies were allowed, it would allow browser-bound scripts to pose
> > as clients and bypass the privacy protection.
> >
> > This only changes the token-fetching part of the process. Presumably the
> > client will then submit this token as part of a request to the consumer
> > which will do the token verification as normal.
> >
> > It is worth noting that aside from the Cookie special case the "browser"
> > mode could actually be implemented as a wrapper around the "raw" mode,
> > and that browser mode is the special case despite it being our only case
> > currently. (There is nothing stopping an ID server from using HTTP-based
> > auth in "browser" mode if that is what it wants to do.)
> >
> > I'll throw out for discussion the matter of whether an explicit mode
> > selection parameter is the best approach or if it can be inferred from
> > other stuff.
> >
> > _______________________________________________
> > 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
>
>