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" <[email protected]> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
