Subject: [GNAP] Authentication mechanisms discovery

From: Denis <[email-masked]>
Date: Mon, 24 Aug 2020 10:16:44 +0200

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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 24 Aug 2020 09:05:22 -0700

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 <[email-masked]> wrote:

> Hi Dick
> *, *
> 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:
>
>       the representation media type.  Although this specification does
>       might use the OPTIONS body to make more detailed queries about the
> target resource.
>
> RFC 7231 also mentions:
>
> However, two types of authentication are possible: user authentication and
> client authentication. If both are supported by the GS, it would be
> possible
> acting or not on behalf of a User.
>
> 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
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 24 Aug 2020 09:09:39 -0700

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 <[email-masked]> wrote:

>>       A client that generates an OPTIONS request containing a payload
>> body MUST send a valid Content-Type header field describing

---

From: Justin Richer <[email-masked]>
Date: Mon, 24 Aug 2020 16:12:07 -0400

Denis, thanks for writing this up. I don’t think we want to get into the business of defining what an API should do for service and capability discovery, especially since there are a wide variety of API patterns and styles out there, each with their own discovery principles. I agree with Dick that the right way to approach this is likely to use the “WWW-Authenticate” header response, which is what I’ve proposed as a straw man in section 10.4 of XYZ:

https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10.4 <https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10.4>

For use cases like yours where the client starts at the RS, this makes a lot of sense and the RS can point the client toward the AS it should be using, and even tell it what kind of thing it needs to ask for next. There’s a lot of work we can do there to make that robust and useful.

But, just like AS discovery, I think that’s an optimization for cases where that information isn’t known by some other means. It’s my stance that, wherever possible, discovery should be an optional add-on to let software optimize the experience, not something required for the protocol to work. “Discovery” and “registration” assume a mostly-static world, where sysadmins are making security decisions ahead of time and assigning identifiers to those decisions. I think that if we take a step back and look at the fundamentals of what we’re trying to solve here, we don’t actually need discovery or registration a lot of the time, and certainly not as add-ons like they are in OAuth 2.

When I wrote XYZ, one of the goals was for it to be “dynamic first”, so that the client and server wouldn’t :need: to know anything about each other ahead of time in order for the core protocol to work. Now of course, in many cases, the AS is only going to trust calls from keys that it’s seen as part of a static registration record, and a client is going to be configured or programmed to only take actions that are available at the AS it’s been written to talk to. But it’s important to me that these cases are optimizations on the overall protocol, which (unlike OAuth) doesn’t assume a discovery or registration step happened out of band first. 

In today’s world, we’ve got so many signals that software can send each other at runtime that can be processed and likely trusted much more than a static discovery/registration ever could. The client can send over device posture, organizational affiliation attestations, verifiable credentials of the current user (without the AS ever seeing the user), derived credentials that are tied to some external trusted registry (think of a CA style model but for more than certificates), or any number of other signals that people are using and building. None of these lend themselves to OAuth’s “client_id is required everywhere” model, which was built around a notion of two web sites talking to each other. That’s why I think we should not only be getting away from the discovery/registration mindset and towards a dynamic-first negotiated protocol which can, in turn, be optimized in a secure and clean fashion.

 — Justin

> On Aug 24, 2020, at 4:16 AM, Denis <[email-masked]> 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 <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
> [email-masked]

---

From: Tom Jones <[email-masked]>
Date: Mon, 24 Aug 2020 15:35:45 -0700

If anyone is interested in contributing to a Mobile Authentication
Assurance Statement, let me know.
We have one in process now in Kantara. It's our view that it would just be
a signed jwt that could be included anywhere it was needed.
Peace ..tom

On Mon, Aug 24, 2020 at 1:12 PM Justin Richer <[email-masked]> wrote:

> Denis, thanks for writing this up. I don’t think we want to get into the
> business of defining what an API should do for service and capability
> discovery, especially since there are a wide variety of API patterns and
> styles out there, each with their own discovery principles. I agree with
> Dick that the right way to approach this is likely to use the
> “WWW-Authenticate” header response, which is what I’ve proposed as a straw
> man in section 10.4 of XYZ:
>
>
> https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10.4
>
> For use cases like yours where the client starts at the RS, this makes a
> lot of sense and the RS can point the client toward the AS it should be
> using, and even tell it what kind of thing it needs to ask for next.
> There’s a lot of work we can do there to make that robust and useful.
>
> But, just like AS discovery, I think that’s an optimization for cases
> where that information isn’t known by some other means. It’s my stance
> that, wherever possible, discovery should be an optional add-on to let
> software optimize the experience, not something required for the protocol
> to work. “Discovery” and “registration” assume a mostly-static world, where
> sysadmins are making security decisions ahead of time and assigning
> identifiers to those decisions. I think that if we take a step back and
> look at the fundamentals of what we’re trying to solve here, we don’t
> actually need discovery or registration a lot of the time, and certainly
> not as add-ons like they are in OAuth 2.
>
> When I wrote XYZ, one of the goals was for it to be “dynamic first”, so
> that the client and server wouldn’t :need: to know anything about each
> other ahead of time in order for the core protocol to work. Now of course,
> in many cases, the AS is only going to trust calls from keys that it’s seen
> as part of a static registration record, and a client is going to be
> configured or programmed to only take actions that are available at the AS
> it’s been written to talk to. But it’s important to me that these cases are
> optimizations on the overall protocol, which (unlike OAuth) doesn’t assume
> a discovery or registration step happened out of band first.
>
> In today’s world, we’ve got so many signals that software can send each
> other at runtime that can be processed and likely trusted much more than a
> static discovery/registration ever could. The client can send over device
> posture, organizational affiliation attestations, verifiable credentials of
> the current user (without the AS ever seeing the user), derived credentials
> that are tied to some external trusted registry (think of a CA style model
> but for more than certificates), or any number of other signals that people
> are using and building. None of these lend themselves to OAuth’s “client_id
> is required everywhere” model, which was built around a notion of two web
> sites talking to each other. That’s why I think we should not only be
> getting away from the discovery/registration mindset and towards a
> dynamic-first negotiated protocol which can, in turn, be optimized in a
> secure and clean fashion.
>
>  — Justin
>

---

From: Denis <[email-masked]>
Date: Tue, 25 Aug 2020 11:37:45 +0200

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

> 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 <[email-masked] 
> <mailto:[email-masked]>> 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
>     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 <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi Dick*,
>         *
>
>         The following comments have been elaborated after an analysis
>         of your draft: draft-hardt-xauth-protocol-13.
>
>         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
>               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.*
>         *
>
>         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
>         [email-masked] <mailto:[email-masked]>

---

From: Denis <[email-masked]>
Date: Tue, 25 Aug 2020 12:36:13 +0200

Justin,

> Denis, thanks for writing this up. I don’t think we want to get into 
> the business of defining what an API should do for service and 
> capability discovery,
> especially since there are a wide variety of API patterns and styles 
> out there, each with their own discovery principles. I agree with Dick 
> that the right way
> to approach this is likely to use the “WWW-Authenticate” header 
> response, which is what I’ve proposed as a straw man in section 10.4 
> of XYZ:
>
Section 10.4 deals with an error case when making a call to RS without 
an access token, or with an invalid access token.
It has nothing to do with either "Authentication mechanisms discovery" 
(nor with "API discovery").

> For use cases like yours where the client starts at the RS, this makes 
> a lot of sense and the RS can point the client toward the AS it should 
> be using,
> and even tell it what kind of thing it needs to ask for next. There’s 
> a lot of work we can do there to make that robust and useful.

Fine.

> where that information isn’t known by some other means.

  ... or is not up-to-date any more.

> It’s my stance that, wherever possible, discovery should be an 
> optional add-on to let software optimize the experience, not something 
> required for the protocol to work.

I would guess that you are missing an important point: I am not simply 
considering the support of, one way or another, the concepts behind HATEOAS
but in case where the client is acting on behalf of a user, a 
combination of both HATEOAS and User consent, i.e. knowing at the same time
which actions that can be done and the access control characteristics 
associated with these actions (which is an aspect that is not addressed 
in HATEOAS).
In such a case, the information sent by the RS would be used by the 
client to get the User Consent *and choices*.

If you have comments on these topics, please send them using the thread 
"API discovery".

> “Discovery” and “registration” assume a mostly-static world, where 
> identifiers to those decisions.

On the contrary, "discovery" is far from being static since it is done 
in real-time.

> I think that if we take a step back and look at the fundamentals of 
> what we’re trying to solve here, we don’t actually need discovery or 
> registration a lot of the time,
> and certainly not as add-ons like they are in OAuth 2.
>
> When I wrote XYZ, one of the goals was for it to be “dynamic first”, 
> so that the client and server wouldn’t :need: to know anything about 
> each other ahead of time
> in order for the core protocol to work.
>
> Now of course, in many cases, the AS is only going to trust calls from 
> keys that it’s seen as part of a static registration record, and a 
> client is going to be configured
> or programmed to only take actions that are available at the AS it’s 
> been written to talk to. But it’s important to me that these cases are 
> optimizations on the overall
> protocol, which (unlike OAuth) doesn’t assume a discovery or 
> registration step happened out of band first.

This is only one half of the story: this is an "AS centric" view. If 
only one AS is associated with a RS and the programmer knows it (which 
is a specific use case), then
"API discovery" can be avoided when two web sites are talking to each 
other. Please consider this other thread, i.e. "Two comments on 
draft-richer-transactional-authz-06"
to send your comments about the "AS centric" and the "RS centric" use cases.

> In today’s world, we’ve got so many signals that software can send 
> each other at runtime that can be processed and likely trusted much 
> more than a static discovery/registration ever could.
> The client can send over device posture, organizational affiliation 
> attestations, verifiable credentials of the current user (without the 
> AS ever seeing the user), derived credentials that are tied
> to some external trusted registry (think of a CA style model but for 
> more than certificates), or any number of other signals that people 
> are using and building. None of these lend themselves
> to OAuth’s “client_id is required everywhere” model, which was built 
> around a notion of two web sites talking to each other.

I wonder why you are speaking of a "client_id" which is a topic that I 
have not addressed in any of the three recently threads that I have opened.

> That’s why I think we should not only be getting away from the 
> discovery/registration mindset and towards a dynamic-first negotiated 
> protocol which can, in turn,
> be optimized in a secure and clean fashion.

Unfortunately, your conclusion (which is not crystal clear to me) is 
unrelated to the arguments you have exposed.

Denis

>  — Justin
>
>> On Aug 24, 2020, at 4:16 AM, Denis <[email-masked] 
>> 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
>> 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 
>> authentication and client authentication. If both are supported by 
>> the GS, it would be possible
>> the representation media type, since the client is knowing whether it 
>> is acting or not on behalf of a User.*
>> *
>>
>> same request as the one used for the GS should be available for a RS 
>> as well.
>>
>> Denis
>>
>> -- 
>> TXAuth mailing list

---

From: Dick Hardt <[email-masked]>
Date: Tue, 25 Aug 2020 08:53:34 -0700

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 <[email-masked]> 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
> difference between an authentication made by the client application on its
> own behalf or on behalf of a User.
>
> Denis
>
>>>       A server generating a successful response to OPTIONS SHOULD send
>>> an header fields that might indicate optional features

---

From: Denis <[email-masked]>
Date: Tue, 25 Aug 2020 18:18:32 +0200

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.

> 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".

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

> 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 <[email-masked] 
>       * The 401 (Unauthorized) status code indicates that the request
>         has not  been applied because it lacks valid authentication
>         credentials for the target resource.
>         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.
>
>     difference between an authentication made by the client
>     application on its own behalf or on behalf of a User.
>
>     Denis
>
>>     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.
>>
>>         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
>>         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
>>
>>
>>         ᐧ
>>
>>             The following comments have been elaborated after an
>>             analysis of your draft: draft-hardt-xauth-protocol-13.
>>
>>             proposing to support an HTTP OPTIONS request which would
>>             be the first request
>>             The HTTP OPTIONS request has been first defined in RFC
>>             2616 and refined in RFC 7231 (see
>>             defined by this specification, but might be defined by
>>             future extensions to HTTP.
>>                   implemented by the server and applicable to the
>>             target resource, including potential extensions not
>>             defined by this specification.
>>
>>             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.*
>>             *
>>
>>             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

---

From: Dick Hardt <[email-masked]>
Date: Tue, 25 Aug 2020 09:33:42 -0700

I view unauthenticated OPTIONS calls to the GS returning what is available
when unauthenticated. Client authentication mechanisms MAY be returned, but
are not required to be returned by the GS.

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

wrt. user authentication, my response was

Your response does not seem related to user authentication.

/Dick

On Tue, Aug 25, 2020 at 9:18 AM Denis <[email-masked]> wrote:

> any URI or method.
> What if the OPTIONS method itself requires authentication? How does the RS
> return how to authenticate?
> Since the OPTIONS method is used to support the User consent, it shall be
> supported on every API endpoint that requires a user consent.
>
> The suggestion is indeed to define return standardized parameters for each
> of these two flavours.
>
>>    Authorization header. So it is not a discovery mechanism but, at best, a
>>    trial and error mechanism.
>>
>>>> authentication mechanisms supported by the GS. This would indeed be very
>>>> useful.
>>>>
>>>>       A standard format for such a representation is not defined by
>>>> this specification, but might be defined by future extensions to HTTP.
>>>> is acting or not on behalf of a User.
>>>>
ᐧ

---

From: Denis <[email-masked]>
Date: Tue, 25 Aug 2020 19:38:06 +0200

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,
> 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.

>     authenticating somewhere other than the GS, but I don't see that
>     as being in the core protocol.
>

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 <[email-masked] 
>>     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?
>     Please remember that there are two different reasons to use the
>     OPTIONS methods: "Authentication mechanisms discovery" and "API
>     discovery".
>     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
>     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.
>
>>     - 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.
>
>>     authenticating somewhere other than the GS, but I don't see that
>>     as being in the core protocol.
>
>     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
>>           * The 401 (Unauthorized) status code indicates that the
>>             request has not  been applied because it lacks valid
>>             authentication credentials for the target resource.
>>             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
>>
>>>         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
>>>         <[email-masked] <mailto:[email-masked]>> 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
>>>             And then information about how to authenticate may be in
>>>             the HTTP Authorization header.
>>>
>>>             On Mon, Aug 24, 2020 at 1:16 AM Denis
>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>                 Hi Dick*,
>>>                 *
>>>
>>>                 Sections 3 and 3.7 from
>>>                 draft-hardt-xauth-protocol-13 are proposing to
>>>                 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
>>>                       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
>>>                 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
>>>                 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 31 Aug 2020 20:13:24 -0700

>     best, a trial and error mechanism.

I'm not sure that I'm understanding you, here.  Yes, the 401 HTTP status
code does not convey information about how to authenticate, but per
https://tools.ietf.org/html/rfc7235#section-3.1 the WWW-Authenticate header
field MUST be included in the response, and that header field does contain
one or more challeng that shows how to authenticate, potentially along with
parameters for each method.  So are you also trying to say that the
combination of HTTP 401 and WWW-Authenticate is also "not a discovery
mechanism"?

Thanks,

Ben