Re: [GNAP] Authentication mechanisms discovery

[Denis <[e-mail]>]

Hi Dick,

> I view unauthenticated OPTIONS calls to the GS returning what is 
> available when unauthenticated.

Yes, if the call is made on the root URL.

> Client authentication mechanisms MAY be returned, but are not required 
> to be returned by the GS.

... or by the RS. :-)

> Your concept of being RS centric is interesting, and sheds light on 
> the features you are requesting. There are many aspects of that to 
> standardize,
> and contrary to a GS centric view, I don't know of common patterns to 
> examine to see what has worked, and what has not worked. I do see how
> an RS centric model could work with the current GNAP protocol.

Really ? I believe that the /current /GNAP protocol would need to be 
modified.

> -- but I am strongly against GNAP *only* being RS centric. In my use 
> cases, I have no need for an RS.

You are pushing onan open door. I already wrote on the thread "Two 
comments on draft-richer-transactional-authz-06":

    There are two cases to consider, one of them is "AS centric" while
    the other one is "RS centric".
    (...)  These two use cases should be supported.

> wrt. user authentication, my response was
>
>     - 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.
>
> Your response does not seem related to user authentication.

As soon as there is a User choice which requires a User consent, I see a 
need to support an OPTIONS call.

Denis

PS. I will be away from my desk from tomorrow until the end of the week, 
so don't expect replies during that time window.

>
> /Dick
>
> On Tue, Aug 25, 2020 at 9:18 AM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Dick,
>
>>     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?
>
>     Please remember that there are two different reasons to use the
>     OPTIONS methods: "Authentication mechanisms discovery" and "API
>     discovery".
>     The "Authentication mechanisms discovery"  does not require
>     authentication : this is already stated in the draft.
>
>     The RS returns how to authenticate in the same way that the GS
>     does it, except that it may also indicate which ASs are
>     appropriate and which attributes
>     should be included into an access token.
>
>     Since the OPTIONS method is used to support the User consent, it
>     shall be supported on every API endpoint that requires a user consent.
>
>>     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.
>
>     Not exactly. There would clearly be two flavours of it : one for
>     "Authentication mechanisms discovery" and another one "API discovery".
>
>>     As I have stated previously:
>>
>>     - a real time query only works if the results are standardized.
>>     There are few standardized APIs or standardized "scopes".
>
>     The suggestion is indeed to define return standardized parameters
>     for each of these two flavours.
>
>>     - 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.
>
>     Please look again at the major difference between "Authentication
>     mechanisms discovery" and "API discovery". This question is once
>     again
>     whether an "AS centric" method is supported or a "RS centric"
>     method is supported.
>
>     Denis
>
>
>     PS: Once again : "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". Any comment ?
>
>
>>     ᐧ
>>
>>     On Tue, Aug 25, 2020 at 2:37 AM Denis <[e-mail]
>>     <mailto:[e-mail]>> 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
>>>         <[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
>>>
>>
>
>     -- 
>     TXAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/txauth
>
> ᐧ