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

Authentication-Info Header

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Fri, 4 Dec 2009 10:19:13 -0700
To: "HTTP Working Group (ietf-http-wg@w3.org)" <ietf-http-wg@w3.org>
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529362B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
The Authentication-Info header should be added to draft-ietf-httpbis-p7-auth to provide a complete list of all the defined authentication headers. It should generalize the definition to make it useful for new authentication schemes:

   The Authentication-Info header is used by the server to communicate
   some information regarding the successful authentication in the response.
   The Authentication-Info header is allowed in the trailer of an HTTP
   message transferred via chunked transfer-coding.

     Authentication-Info = "Authentication-Info" ":" OWS Authentication-Info-v
     Authentication-Info-v = 1#auth-param

And should probably (finally) define Proxy-Authentication-Info which is only mentioned in passing in 2617.

It is also not clear if the Authentication-Info header can (or is appropriate) together with a new WWW-Authenticate challenge.

---

Also, for OAuth, we are looking for a place to provide authentication error information. The current definition of Authentication-Info limits it use to successful authentications. While I can certainly argue that an error is "some information regarding the successful authentication", (i.e. that it was not), it seems to violate the spirit of the text.

I am not aware of other authentication schemes using this header than Digest, and since Digest limits the allowed values, extending this header field to mean *any* status information (not just successful) should not break or change any existing implementation.

If the definition remains the same, we will need to decide between minting a new header Authentication-Error (and corresponding Proxy-Authentication-Error), or find a way to stick the error information together with a new challenge or as masked as new challenge. I am not excited about the latter option, especially given the possibility of multiple challenges in a single header.

EHL
Received on Friday, 4 December 2009 17:19:37 GMT

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