How can a client identify which ASs are trusted by the RS ?

[Denisthemalice]

On October 21, 2020 an email with the following subject "Quick review of draft-ietf-gnap-core-protocol-00"
has been sent and left unanswered. One of the topics was:

The document only speaks about "the AS", as if only one AS would exist which is obviously not the case.

The first access made to a RS shall be able to identify which ASs are trusted by the RS and for which reason(s).

[fimbault]

The reason for that has been explained: at any one point in time for a request, there's only one AS in the core protocol.

We might want to allow a preflight for a variety of reasons (token format negotiation, AS choice, etc...), but probably as an extension (cf what has been discussed about putting section 10 into its own document).

[Denisthemalice]

Even "at any one point in time for a request, there's only one AS in the core protocol", this does not prevent a RS to trust
more than one AS.

This issue relates to the "User choice and consent, and user notice" issue #215 which proposes one solution,
but there might be other solutions.

[jricher]

This should be addressed by the GNAP-RS extension created under #246 , which does not change the core model of one AS per transaction request. An additional discovery protocol could be developed to allow client instance to choice of AS if desired within that extension or another document.

[agropper]

I'm not sure we should touch this privacy third-rail unless we really mean to reopen a discussion of resource owner. A Resource Server is free to publish anything it wants but once it publishes something specific to a resource owner, it becomes a controller rather than a processor. If we take this path, even via extensions, we risk going in circles.

[Denisthemalice]

@jricher : You wrote:

This should be addressed by the GNAP-RS extension created under #246 , which does not change the core model of one AS per transaction request. An additional discovery protocol could be developed to allow client instance to choice of AS if desired within that extension or another document.

I believe that the topic belongs to the core of the document. I have created an issue with a different title that considers several aspects related to the very first request made by client to a server and hence it is larger than the topic of this thread which is limited to "How can a client identify which ASs are trusted by the RS.

The title of this new issue #252 is : Interaction (1) between the Client Instance and the RS, as described in the first figure.