Re: [GNAP] Authentication mechanisms discovery

[Denis <[e-mail]>]

Hi Dick,

A few arguments:

  * The 401 (Unauthorized) status code indicates that the request has
    not  been applied because it lacks valid authentication credentials
    for the target resource.
    Information about how to authenticate is NOT in the HTTP
    Authorization header. So it is not a discovery mechanism but, at
    best, a trial and error mechanism.

  * As already said, reading the documentation is one way, but making a
    real time inquiry is another way which is better for clients acting
    on behalf of a User.

  * If the OPTIONS method call can be used at the GS, it should not be
    forbidden to be used as well at the RS.

The missing point in draft-hardt-xauth-protocol-13 is the lack of 
difference between an authentication made by the client application on 
its own behalf or on behalf of a User.

Denis

> A comment about an OPTIONS call being the first call in the protocol.
>
> While that is possible, I expect most use of the discovery will happen 
> by tooling rather than client software. IE, when developing against an 
> GS, the developers tool chain will check what the GS supports.
>
> On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Denis
>
>     While it is an interesting idea to use the OPTIONS method at the
>     RS, the standard way to indicate authentication mechanisms is with
>     a 401 HTTP response per
>     https://tools.ietf.org/html/rfc7235#section-3.1
>
>     And then information about how to authenticate may be in the HTTP
>     Authorization header.
>
>     This allows an RS to respond to any request including an OPTIONS
>     method call.
>
>     /Dick
>
>
>     ᐧ
>
>     On Mon, Aug 24, 2020 at 1:16 AM Denis <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         Hi Dick*,
>         *
>
>         The following comments have been elaborated after an analysis
>         of your draft: draft-hardt-xauth-protocol-13.
>
>         *1 ) Authentication mechanisms discovery at the GS*
>
>         Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are
>         proposing to support an HTTP OPTIONS request which would be
>         the first request
>         when talking to a GS. The goal is to be able to query the
>         authentication mechanisms supported by the GS. This would
>         indeed be very useful.
>
>         The HTTP OPTIONS request has been first defined in RFC 2616
>         and refined in RFC 7231 (see
>         https://tools.ietf.org/html/rfc7231#section-4.3.7).
>
>         RFC 7231 mentions:
>
>               A standard format for such a representation is not
>         defined by this specification, but might be defined by future
>         extensions to HTTP.
>               A client that generates an OPTIONS request containing a
>         payload body MUST send a valid Content-Type header field
>         describing
>               the representation media type.Although this
>         specification does not define any use for such a payload,
>         future extensions to HTTP
>               might use the OPTIONS body to make more detailed queries
>         about the target resource.
>
>         RFC 7231 also mentions:
>
>               A server generating a successful response to OPTIONS
>         SHOULD send an header fields that might indicate optional
>         features
>               implemented by the server and applicable to the target
>         resource, including potential extensions not defined by this
>         specification.
>
>         However, two types of authentication are possible: user
>         authentication and client authentication. If both are
>         supported by the GS, it would be possible
>         to address this concern either by returning two lists of
>         authentication methods or even better by using two different
>         Content-Type header fields describing
>         the representation media type, since the client is knowing
>         whether it is acting or not on behalf of a User.*
>         *
>
>         *2) Authentication mechanisms discovery at the RS*
>
>         This HTTP OPTIONS request should also be supported by a RS.
>         When a client first contacts a RS, it does not necessarily
>         know the authentication
>         methods that are /currently/ supported by the RS. This means
>         that the same request as the one used for the GS should be
>         available for a RS as well.
>
>         Denis
>
>         -- 
>         TXAuth mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/txauth
>