[GNAP] User consent

[Denis <[e-mail]>]

This is a new thread built from "Revisiting the photo sharing example (a 
driving use case for the creation of OAuth)"

Justin,

> So what I’m saying is that what you’re defining as part of the RS was 
> (in Oauth) defined as a function of the AS.
> As such, I contend that it needs to be its own separate functional 
> role, neither AS nor RS.

I don't see that as separate roles, but as two different kinds of 
interactions with the same entity.

> That way it could be fulfilled by an entity either closely tied to the 
> AS or closely tied to the RS, as appropriate.
> It would give us more flexibility to talk about the patterns.

Nevertheless, such a possibility should be explored in more depth.

In my response to Dick I wrote:

    A set of a choices should be presented by the RS to the Client in a
    standardized way. The choices made by the user
    should be locally recorded by the Client, hence the RS does not need
    to be informed of these choices. The RS will only know
    the end result of these choices when/if it gets back one or more
    access tokens.

    Human to software interactions should be part of the protocol.

    RS to Client: a set of choices
    Client to RS: Done (choices have been done by the user).

For a RS, before performing a given operation, the RS should specify to 
the User how many access tokens would be required, from which ASs
they could be obtained and which types of attributes these access tokens 
should contain.

For an AS, a key question would be whether some choices would be 
presented by the AS to the Client in a standardized way ? I don't know.
What would be such choices ?  I let Dick, yourself or someone else 
respond but I wonder that such choices could be presented by an AS
to a User (through the Client) in a standardized way.

Denis


>  — Justin
>
>> On Aug 13, 2020, at 1:29 PM, Denis <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>  Justin,
>>
>> Your response does not address my point. I am talking of two 
>> different channels with the RS, i.e. not with the AS.
>>
>> Denis
>>
>>> Denis, I want to focus on one point here:
>>>
>>>> In OAuth 2.0, the user consent is performed by the AS using an 
>>>> authorize endpoint where the user consent is solicited and captured.
>>>>
>>>> Since a user, with no prior experience, shall first connect to a RS 
>>>> to perform an operation, the user consent shall be performed by the 
>>>> RS,
>>>> instead of the AS. This means that we should define a "consent" 
>>>> endpoint at the RS.
>>>
>>> One of my goals with XYZ’s design was to be able to separate the 
>>> interaction with the user from the web-based flows for the 
>>> delegation protocol, and that aspect is enshrined in the GNAP 
>>> charter as well.
>>>
>>> It points to the reality that there are two different aspects of the 
>>> traditional AS that we might need to talk about separately now. One 
>>> deals with delegation, issuing tokens, returning data directly to 
>>> the client (not through a separate API, since that’s the RS), and 
>>> other back-channel stuff. The other aspect deals with interacting 
>>> with the user and/or resource owner.
>>>
>>> We already saw bits of this in OAuth 2: the AS is defined by the 
>>> pair of the token endpoint and authorization endpoint, each filling 
>>> the respective roles above. What if we formally separate these? 
>>> Strawman names:
>>>
>>> Delegation Server (DS) - handles the back-channel stuff
>>>
>>> Interaction Server (IS) - handles the front-channel stuff
>>>
>>>
>>>  — Justin
>>>
>>
>