Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

[Denis <[e-mail]>]

Dick,

I first jump on the following exchanges:

    [Dick] Most deployments today accomplish (2) by the developer
    reading RS documentation. I'm in favor of showing that step in an
    abstract diagram.

    [Denis] Really by reading RS documentation ? Non capisco l'italiano.
    Jag förstår inte svenska. Jeg forstår ikke norsk.
    One of the goals is for any Client to access any RS without the need
    to read any documentation.

    [Dick]That is impractical. Most RSes today have resource specific
    APIs. The Client is either reading a standard API doc, or the
    resource specific API doc.

I am not so sure that it is impractical.

In 2012, Geert Jansen considered the possibility for complete 
auto-discovery by the API user, so that the API can be used by a human 
with a web browser,
without any reference to external documentation. See the "Form 
Definition Language" in 
:https://restful-api-design.readthedocs.io/en/latest/forms.html

In his view, forms need to specify three pieces of information:

    1.    How to contact the target and format the input.
    2.    A list of all available input fields.
    3.    A list of constraints with which the input fields must comply.

Hence, in his view, the form consists of 3 parts: form metadata, field 
definitions, and constraints.

What do you think ?


The second point on which I would like to insist is about the use of a 
"dialog box" for user interaction. This wording is used in RFC 6973.

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.

Denis


> comments inline ...
>
> On Wed, Aug 12, 2020 at 7:14 AM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Dick,
>
>>     Hi Francis, responses inline ...
>>
>>     On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Hello Dick,
>>
>>         On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt
>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>             Hi Francis
>>
>>             The user is an entity, not a role in the protocol in how
>>             I am defining roles, so steps (1) and (7) are confusing
>>             to me on what is happening.
>>
>>         "Requestor" is the role (*was* User). So the UML participant
>>         refers to the role "Requestor"
>>
>>
>>     I still don't understand what is happening in (1) and (7)
>
>
> Would you provide more explanation?
>
>>
>>
>>
>>             I also think that (2) could be an extension to GNAP,
>>             rather than part of the core protocol.
>>
>>         If you make it an extension, you hide. It shall rather be an
>>         optional, integral part of the protocol.
>>
>>
>>     Most deployments today accomplish (2) by the developer reading RS
>>     documentation. I'm in favor of showing that step in an abstract
>>     diagram.
>
>     [Denis] Really by reading RS documentation ? Non capisco
>     l'italiano. Jag förstår inte svenska. Jeg forstår ikke norsk.
>
>     One of the goals is for any Client to access any RS without the
>     need to read any documentation.
>
>
> That is impractical. Most RSes today have resource specific APIs. The 
> Client is either reading a standard API doc, or the resource specific 
> API doc.
>
>>     But it is not clear to me what the requirements for (2), and they
>>     may vary radically across use cases, so putting it in the core
>>     document seems to be getting ahead of ourselves.
>
>     [Denis] I can only reinsist on earlier explanations given about
>     the Client-server use cases built along "Privacy by Design" since
>     they are fundamental.
>
> I agree with the principle of "Privacy by Design". There are LOTS of 
> details in how to do what you outline below, and I expect they will be 
> radically different across use cases, which is why I don't think it 
> fits into the core document, but I do agree with calling it out in the 
> abstract. When I publish an updated draft, let me know what you think 
> then.
>
>
>         Taking into consideration both the "data minimization"
>         principle and the "user participation" principle when a user
>         first authenticates to a RS leads to the following:
>
>         1) When accessing a RS for the first time, the user should be
>         informed of the authentication means proposed by the RS. The
>         user should be able to use a dialog box
>         where some choices are presented by the RS. The user should be
>         able to locally make his own choices and to indicate his
>         consent to its Client.
>
>         2) When a user chooses to perform one operation on a RS, the
>         RS should limit the data to be collected from the user to only
>         what is strictly necessary
>         to perform that operation. That data consists of specific
>         types of attributes that need to be guaranteed by one or more
>         ASs. The user should be able
>         to use a dialog box where some ASs choices are proposed by the
>         RS. The user should be able to locally make his own choices
>         and to indicate
>         his consent to its Client.
>
>         It is important to notice that the choices that will be
>         proposed to a user may depend upon previous personal
>         information voluntarily released by that user.
>         This means that the choices proposed by the RS may be tailored
>         for the user. Furthermore, the proposed choices may only be
>         disclosed to already authenticated users.
>
>     Denis
>
>>         In some open banking designs,
>>         - the "Orchestrator/Negotiator/Client" will not know the AS
>>         to talk to unless the call (2).
>>
>>
>>     Have you put these use cases in the wiki?
>>
>>         - the request (2) might result in an exemption, meaning no
>>         need for further authorization, allowing to skip (3, 4, 5)
>>         and even (6).
>>
>>
>>     Agreed.
>>
>>     ᐧ
>
>
> ᐧ