HTTP Authentification Interoperability problems

Joe Gregorio has written a blog post about HTTP Authentification  
Interoperability Problems.

He cites
http://www.w3.org/TR/NOTE-authentform
http://whatwg.org/specs/web-apps/current-work/#requirements

He has forgotten CHIPs (See below)


[[[
I am not making any of this stuff up. Basic is not really an option  
since it transmits your name and password unencrypted. Yes, it  
encodes it as base64, but that's not encryption. Apache 2.0 does not  
do 'auth-int'. While Python's urllib2 claims to do MD5-sess, Apache  
does not implement it correctly. In addition looking at the code of  
urllib2 it supports algorithm=SHA, but there's no mention of that as  
an option in RFC 2617. WSSE isn't really specified for plain HTTP; it  
was originally designed for WS-Security and unofficially ported to  
HTTP; the definitive reference is an XML.com article, and while an  
august publication, it hardly ranks up there with the IETF or W3C.

There are some bright spots: on Apache 2.0.51 or later you can get IE  
and Digest to work by using this directive:

BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On

Now before you start telling me to use TLS please realize that I,  
like many other people, use a shared hosting account; even if I  
wanted to shell out the money to buy a certificate I wouldn't be able  
to set up TLS for my site.

And don't even get me started on how browsers handle authentication  
and how web designers have conniption fits because they can't control  
the look and feel of the default pop-up dialog that prompts you for  
your name and password when you use Basic or Digest.

For further reading you may want to check out this W3C note from 1999  
(!) User Agent Authentication Forms. In addition the WHATWG's Web  
Applications 1.0 specification lists Better defined user  
authentication state handling. (Being able to "log out" of sites  
reliably, for instance, or being able to integrate the HTTP authe

Are you sad, disgusted and exasperated? If so then you might be in  
the right state of mind to join the Ietf-http-auth mailing list and  
help us get out of this mess. In the mean time, would you like a cookie?
]]]

-- Problems with HTTP Authentication Interop | 2006-01-10 | BitWorking
http://bitworking.org/news/Problems_with_HTTP_Authentication_Interop
Wed, 11 Jan 2006 14:07:58 GMT




[[[
3.2: Identification and Session mechanisms SS CM

HTTP/1.1 provides a number of mechanisms for identification,  
authentication and session management. Using these mechanisms instead  
of user-based or session-based URIs guarantees than the URIs used to  
serve resources are truly universal (allowing, for example, people to  
share, send, or copy them).

    1.

       Use standard identification instead of per-user URIs SS CM

       For the reasons stated above, standard identification  
mechanisms should be prefered over user-dependent URIs.

       Standard identification mechanisms for the World Wide Web are  
described in RFC 2617 : "HTTP Authentication: Basic and Digest Access  
Authentication" [RFC2617].
    2.

       Use standard session mechanisms instead of session-based URIs.  
SS CM

       For the reasons stated above, standard session mechanisms  
should be prefered over session-dependent URIs.

       The latter may only be used in very specific cases, when  
standard mechanisms do not provide the desired features.

       Example of an acceptable practice:
       A URI may have some modifiers, like "?" used to pass arguments  
for cgi, or ";" to pass other kind of arguments or context  
information. Used for information tracking, this is a proper use of  
session information in URIs.

       Example of a bad practice:
       Bob tries to visit http://www.example.com/resource, but since  
it's a rainy Monday morning, he gets redirected to http:// 
www.example.com/rainymondaymorning/resource. The day after, when Bob  
tries to access the resource he had bookmarked earlier, the server  
answers that Bob has made a bad request, and serves http:// 
www.example.com/error/thisisnotmondayanymore. Had the server served  
back http://www.example.com/resource because the Monday session had  
expired, it would have been, if not acceptable, at least harmless.

       Standard session mechanisms include RFC 2109 : "HTTP State  
Management Mechanism" [RFC2109], also known as "cookies".
]]]

-- Common HTTP Implementation Problems
http://www.w3.org/TR/chips/#cp3.2
Fri, 24 Jan 2003 15:21:02 GMT

-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
*** Be Strict To Be Cool ***

Received on Wednesday, 11 January 2006 14:20:21 UTC