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