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

[Dick Hardt <[e-mail]>]

Thanks Francis

(I'm assuming your second (2) should have been a (6) )

Am I correct that 1, 4, & 7 are human interactions, and 2, 3, 5, & 6 are
part of the protocol?

ᐧ

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/
>