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

[Dick Hardt <[e-mail]>]

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.
>
>> ᐧ
>
>
> ᐧ