Non-browser Identity Verification
brad at danga.com
Wed May 18 11:52:18 PDT 2005
Why can't the non-browser consumer just parse the redirect URL? It's also
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:
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
More information about the yadis