W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

Proposal: 3xx (Unauthorized, See Other) status

From: Thomas Broyer <t.broyer@gmail.com>
Date: Tue, 20 Jan 2009 00:02:43 +0100
Message-ID: <a9699fd20901191502o2d0d3493u543b3cad167a7cb7@mail.gmail.com>
To: ietf-http-wg@w3.org

Hi all,

For the purpose of my http-cookie-auth I-D [1], I'm currently doing a
survey of the current authentication mechanisms (other than RFC 2617)
used "on the wild."
Most Single Sign-On systems involve a redirection from the Service
Provider (a.k.a Consumer) to the Identity Provider (which redirects
back to the SP with some token or "assertion", but that's not the
concern here).
In some cases, the SP and IdP share the same "root domain" (e.g.
docs.google.com, mail.google.com, www.google.com/reader,
www.google.com/accounts; http://fr-fr.facebook.com,
https://www.facebook.com) so a 401 (Unauthorized) could be used (see
example 2 in draft-broyer-http-cookie-auth [1]), and access granted
through a cookie with the appropriate Domain attribute value (in
Google's case, Domain=.google.com), even though using distinct cookies
might be a better choice for security.
In other cases though, it is not possible (the SP and IdP do not share
a common "root domain", as is the case for e.g. www.flickr.com and
login.yahoo.com). There are possible workarounds using a meta refresh
and/or some javascript (see notes about the yet-to-be-written example
3 in draft-broyer-http-cookie-auth [1], a no-code demo can be found at
[2], file source avail. at [3]) but that's not ideal.
In both cases, for instance, if the SP runs on HTTP and the IdP on
HTTPS, if the 401 payload contains an HTML "login form", the user
cannot know before hand that the form will be submitted on a secured
channel to the IdP (this is a problem with the UA, but IMO not only,
as it's also related to CSRF and to phishing).


I therefore wonder if a new 3xx status had been proposed before, in
order to communicate lack of authorization (same as a 401) but
redirecting/deferring to another resource to authenticate the user.
If it has not been proposed/discussed before, would HTTPbis be a good
place to define it, or should/could I include it in
draft-broyer-http-cookie-auth (as cookies are the only
non-SSL-client-cert non-RFC2617 "authentication" mechanism that I know
of) or some other I-D?



If people want some "literature" about such SSO systems, one is spec'd
as part of SAML 2.0 [4] in the SSO profile.

[1] http://ltgt.net/projects/http-cookie-auth/draft-broyer-http-cookie-auth-00.html
[2] http://ltgt.net/tests/http-cookie-auth/test01/
[3] http://hg.ltgt.net/http-cookie-auth/file/tip/tests/test01
[4] http://saml.xml.org

-- 
Thomas Broyer
Received on Monday, 19 January 2009 23:03:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:00 GMT