Re: [GNAP] Authentication mechanisms discovery

I agree, the 401 response is not the ideal architecture, but it works for
any URI or method. What if the OPTIONS method itself requires
authentication? How does the RS return how to authenticate? Does the RS
need to support the OPTIONS method on all API endpoints?

An OPTIONS method at the RS is not forbidden, but just like at the GS,
OPTIONS is a general discovery mechanism, not just for authentication.

As I have stated previously:

- a real time query only works if the results are standardized. There are
few standardized APIs or standardized "scopes".

- there are a very wide set of choices on how the user can authenticate.
I'm not saying GNAP should not support your model of the user
authenticating somewhere other than the GS, but I don't see that as being
in the core protocol.

ᐧ

On Tue, Aug 25, 2020 at 2:37 AM Denis <denis.ietf@free.fr> wrote:

> 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 <dick.hardt@gmail.com> 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 <denis.ietf@free.fr> 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
>>> TXAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>