Re: [GNAP] Authentication mechanisms discovery

[Dick Hardt <[e-mail]>]

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