Review of draft-ietf-httpbis-p7-auth-19.txt

Hi,
Yet another late review:

    A user agent that wishes to authenticate itself with an origin server
    -- usually, but not necessarily, after receiving a 401 (Unauthorized)
    -- MAY do so by including an Authorization header field with the
    request.

    A client that wishes to authenticate itself with a proxy -- usually,
    but not necessarily, after receiving a 407 (Proxy Authentication
    Required) -- MAY do so by including a Proxy-Authorization header
    field with the request.

It doesn't look like use of the 2 MAYs above is appropriate, because
they are not implementation alternatives. Maybe change them to "can"?

    Both the Authorization field value and the Proxy-Authorization field
    value consist of credentials containing the authentication
    information of the client for the realm of the resource being
    requested.  The user agent MUST choose to use one of the challenges
    with the strongest auth-scheme it understands and request credentials
    from the user based upon that challenge.

This is overly simplistic: I think this should talk about the client
possibly falling back to an authentication scheme B if authentication
with scheme A failed, and both A and B were advertised by the server.


    If the origin server does not wish to accept the credentials sent
    with a request, it SHOULD return a 401 (Unauthorized) response.  The
    response MUST include a WWW-Authenticate header field containing at
    least one (possibly new) challenge applicable to the requested
    resource.

    If a proxy does not accept the credentials sent with a request, it
    SHOULD return a 407 (Proxy Authentication Required).  The response
    MUST include a Proxy-Authenticate header field containing a (possibly
    new) challenge applicable to the proxy for the requested resource.

I think this is a bit misleading. Can an authentication exchange include
more than one round trip? I think you need to be explicit one way or 
another. (If it can, then "does not accept" is not necessarily correct.)

Received on Tuesday, 8 May 2012 20:37:44 UTC