Non-browser Identity Verification

[Brad Fitzpatrick]

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
>
>