Re: [GNAP] Authentication mechanisms discovery

[Dick Hardt <[e-mail]>]

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]> 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]
> https://www.ietf.org/mailman/listinfo/txauth
>