Re: Proposal: 3xx (Unauthorized, See Other) status

Hi Thomas,

We're not chartered to do extension work, but you can certainly use  
the mailing list for review and discussion.

BTW, this sounds a little bit like a previous discussion;
   http://www.w3.org/mid/76F49FF4-54D7-4917-85A3-A0D648E57C7E@mnot.net

Cheers,



On 20/01/2009, at 10:02 AM, Thomas Broyer wrote:

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


--
Mark Nottingham     http://www.mnot.net/

Received on Friday, 23 January 2009 00:26:09 UTC