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

[Dick Hardt <[e-mail]>]

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
>