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

[Denis <[e-mail]>]

Dick,

A web browser is not a person.

Denis

PS1. You didn't reply to the second point of my email about a "consent" 
endpoint at the RS.

PS2. It would be better that you wait until you can use a real laptop to 
respond and that you re-use the original message,
          because the message you sent back is almost unreadable.

> The Client is not a person, it is software created by a developer. The 
> developer of the client is going to read the documentation for the RS 
> to program the Client.
>
> On Thu, Aug 13, 2020 at 6:47 AM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>
>
>
>
>
>
>
>
>
>     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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>         ᐧ
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     ᐧ
>>
>>
>
>
>
>
>
>
>
>
>
>
>
>     -- 
>
>     TXAuth mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/txauth
>