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

[Francis Pouatcha <[e-mail]>]

On Tue, Aug 11, 2020 at 11:39 PM Dick Hardt <[e-mail]> wrote:

> Thanks Francis
>
> (I'm assuming your second (2) should have been a (6) )
>
Yes. Typo

>
> Am I correct that 1, 4, & 7 are human interactions,
>
Yes in the university use case. They might not be human interaction in
other use cases. They are not part of the protocol, but help for use
case mapping.


> and 2, 3, 5, & 6 are part of the protocol?
>
Yes.

>
> ᐧ
>
> On Tue, Aug 11, 2020 at 7:14 PM Francis Pouatcha <[e-mail]> wrote:
>
>> Hello Dick,
>>
>> I will use the university registration use case as an example to
>> illustrate steps (1) and (7).
>>
>> +-----------+      +--------------+  +-----------+  +----+
>>  +---------------------+
>> | Requestor |      | Orchestrator |  | RS        |  | GS |  | Resource
>> Controller |
>> | is UNIV-1 |      |  is UNIV-1   |  | is UNIV-0 |  | or |  |         is
>>         |
>> |   Staff   |      | Registr. App |  | Server    |  | AS |  |
>> Student       |
>> +-----------+      +--------------+  +-----------+  +----+
>>  +---------------------+
>>   |(1) RegisterStudent(StudentId)          |           |                |
>>   |---------------------->|                |           |                |
>>   |                       |(2) RequestRecordIntent(RecordType,StudentId,
>>   |                       |     OrchestratorId):AuthRequest[RecordType,
>> StudentId]
>>   |                       |<-------------->|           |                |
>>   |                       |                |           |                |
>>   |                       |(3) AuthZRequest(RecordType,StudentId
>> ,OrchestratorId)
>>   |                       |--------------------------->|                |
>>   |                       |                |           |(4)
>> ConsentRequest(RecordType,
>>   |                       |                |           |
>>  OrchestratorId):Consent
>>   |                       |                |           |<-------------->|
>>   |                       |(5) AuthZ[RecordType,StudentId,OrchestratorId]
>>   |                       |<---------------------------|                |
>>   |                       |                |           |                |
>>   |                       |(2) RequestRecord(RecordType,StudentId
>> ,OrchestratorId)
>>   |                       |     :RecordOf[StudentId]   |                |
>>   |                       |<-------------->|           |                |
>>   |(7) Registered         |                |           |                |
>>   |<----------------------|                |           |                |
>>   +                       +                +           +                +
>>
>> Step (1) is the initial service request "RegisterStudent" sent by
>> the university staff to the University registration application.
>>
>> Step (7) is the response to step (1), the notification of the university
>> staff that the registration was successful.
>>
>> Best regards
>> /Francis
>>
>>
>> On Tue, Aug 11, 2020 at 7:38 PM Dick Hardt <[e-mail]> wrote:
>>
>>> 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)
>>>
>>>
>>>>
>>>>
>>>>> 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. 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.
>>>
>>>
>>>> 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.
>>>
>>>> ᐧ
>>>
>>
>>
>> --
>> Francis Pouatcha
>> Co-Founder and Technical Lead
>> adorsys GmbH & Co. KG
>> https://adorsys-platform.de/solutions/
>>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/