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

[Dick Hardt <[e-mail]>]

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]> 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]> wrote:
>
>
>
>
>
>>
>>
>>
>> Hi Dick,
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi Francis, responses inline ...
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Aug 11,
>>
>> 2020 at 3:37 PM Francis Pouatcha <[e-mail]>
>>
>> wrote:
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>> Hello Dick,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Aug
>>>
>>> 11, 2020 at 6:22 PM Dick Hardt <[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]
>
> https://www.ietf.org/mailman/listinfo/txauth
>
>