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

[Fabien Imbault <[e-mail]>]

Indeed.

Le mer. 19 août 2020 à 17:09, Justin Richer <[e-mail]> a écrit :

> In my perspective, the focus should be on defining the protocol: what
> you’d call the transaction pattern. We can potentially use a API language
> to describe how an entity can perform a role within that protocol, but
> ultimately we should be defining the protocol.
>
>  — Justin
>
> On Aug 19, 2020, at 6:31 AM, Fabien Imbault <[e-mail]>
> wrote:
>
> Just wondering if that might be a way to compose the generic
> transaction/continuation pattern (XYZ style, layer 1) from a lower-level
> GS-API (layer 0).
> Fabien
>
> On Thu, Aug 13, 2020 at 9:28 PM Dick Hardt <[e-mail]> wrote:
>
>> Hi Francis
>>
>> I have come to a similar conclusion. I'll be posting my thoughts in a
>> concrete proposal and am keen to hear how it fits into how your mental
>> model.
>>
>> /Dick
>> ᐧ
>>
>> On Thu, Aug 13, 2020 at 12:00 PM Francis Pouatcha <fpo=
>> [e-mail]> wrote:
>>
>>> Lots of mails, so I will summarize my opinion in this single mail:
>>>
>>> We are dealing with different levels of abstraction here, this is why we
>>> are always falling back to wording battles.
>>>
>>> oAuth2/OIDC vs. GNAP
>>> AS vs. GS/DS/IS
>>> Entity vs. Roles
>>> User (human) vs. Requestor
>>> Client vs (Orchestrator/Requesting Party/Negotiator...)
>>> front-channel & back-channel
>>>
>>> To direct the discussion, we have to agree on the level of abstraction
>>> at which we want a certain discussion to take place.
>>>
>>> Abstraction Level-0: GNAP
>>>
>>> Level-0 deals with roles (participants) and messages
>>> (request/responses). Level-0 does not consider entities (users) or the
>>> nature of any other participants, neither Level-0 deals with the way a
>>> message is transported (synchronous/asynchronous) or the type of
>>> interaction used to materialize the message (front-channel, back-channel).
>>> The purpose of this abstraction layer is to provide a common understanding
>>> of the core elements of the protocol.
>>>
>>> Level-0 can still provide some basic definition of messages including
>>> information schema as long as we are not limiting the protocol with
>>> constraints from lower layers.
>>>
>>> Level-0 is ideal to address some fundamental privacy and confidentiality
>>> matters that will be materialized in lower layers.
>>>
>>> Abstraction Level-1: OAuth2 / OIDC / [SSI/DiD/VC]
>>> Instantiation of Level-0 for a constrained application space. This is
>>> why we will meet the world Client, User, RO, AS, .... here roles defined in
>>> Level-0 will be mapped to entities, interaction will be used to materialize
>>> messages defined in Level-0.
>>> The protocol mapping at this layer also takes into consideration that
>>> some of those participants are human or only pieces of software, running on
>>> the user device or on a server with consequences on the protocol design.
>>>
>>> Abstraction Level-2: Trust Frameworks like IAM / PSD2,FAPI / ....
>>>
>>> In Summary:
>>> Level-0: Roles, Messages
>>> Level-1: Entities, Interactions
>>> ...
>>>
>>> And if it happens we want to define GNAP at Level-1 (instead of 0), let
>>> declare it as such and limit the application space before we proceed with
>>> further discussions.
>>>
>>> Best regards.
>>> /Francis
>>>
>>>
>>>
>>>
>>> On Thu, Aug 13, 2020 at 1:30 PM Denis <[e-mail]> wrote:
>>>
>>>>  Justin,
>>>>
>>>> Your response does not address my point. I am talking of two different
>>>> channels with the RS, i.e. not with the AS.
>>>>
>>>> Denis
>>>>
>>>> Denis, I want to focus on one point here:
>>>>
>>>> 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.
>>>>
>>>>
>>>> One of my goals with XYZ’s design was to be able to separate the
>>>> interaction with the user from the web-based flows for the delegation
>>>> protocol, and that aspect is enshrined in the GNAP charter as well.
>>>>
>>>> It points to the reality that there are two different aspects of the
>>>> traditional AS that we might need to talk about separately now. One deals
>>>> with delegation, issuing tokens, returning data directly to the client (not
>>>> through a separate API, since that’s the RS), and other back-channel stuff.
>>>> The other aspect deals with interacting with the user and/or resource
>>>> owner.
>>>>
>>>> We already saw bits of this in OAuth 2: the AS is defined by the pair
>>>> of the token endpoint and authorization endpoint, each filling the
>>>> respective roles above. What if we formally separate these? Strawman names:
>>>>
>>>> Delegation Server (DS) - handles the back-channel stuff
>>>>
>>>> Interaction Server (IS) - handles the front-channel stuff
>>>>
>>>>
>>>>  — Justin
>>>>
>>>>
>>>> --
>>>> TXAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>>
>>> --
>>> Francis Pouatcha
>>> Co-Founder and Technical Lead
>>> adorsys GmbH & Co. KG
>>> https://adorsys-platform.de/solutions/
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>> --
>> TXAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
>