Re: [OAUTH-WG] Authentication-Info Header

Eran Hammer-Lahav wrote:

> Any comments? Suggestions?

Hi Eran,
Speaking as an individual contributor:

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

>     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.
>
As long as this is consistent with existing usage (I don't remember of 
the top of my head how Negotiate works and whether it is using this 
header field).

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

>     It is also not clear if the Authentication-Info header can (or is
>     appropriate) together with a new WWW-Authenticate challenge.
>
Sure. I am not sure I can provide an opinion on this, as I am not an 
implementor.

>     ---
>
>     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 21:34:52 UTC