Re: [OAUTH-WG] Authentication-Info Header

On 2010/01/21 3:17, Eran Hammer-Lahav wrote:
>     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.

We use the Authentication-Info: header in our proposed authentication
scheme (Mutual), and it will be good to have a common syntax for several
authentication schemes.
# We realized, during our implementation, that some implementations prefer to
# have a common syntax for each HTTP header, even when its meaning
# depends on some other values in headers (e.g. on authentication
# schemes).  These use generic lexer-parser to parse such headers first into
# key-value pairs before interpretation.

As Julian says that it is out of current HTTPbis spec,
if you are going to generalize it somewhere (e.g. OAuth WG),
I will join the discussion there.

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

Sorry for my laziness, but could you please give me a little-bit
detail (or a pointer to that) what will be the possible payload on that
[may be in oauth WG ML]?
In our proposal, a field in WWW-Authenticate was sufficient for carrying an
error information (ours has a 1-bit flag in WWW-Authenticate to distinguish
between password mismatch and key expiration, on which client behavior differs).
I'm interested if we also have a similar need which is not realized now.

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

Received on Thursday, 21 January 2010 11:42:43 UTC