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

Re: Authentication-Info Header

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Wed, 20 Jan 2010 11:17:58 -0700
To: HTTP Group <ietf-http-wg@w3.org>
CC: OAuth WG <oauth@ietf.org>
Message-ID: <C77C88D6.2D6C8%eran@hueniverse.com>

Any comments? Suggestions?

EHL

On 12/4/09 9:19 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

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 Wednesday, 20 January 2010 18:18:39 GMT

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