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

[Francis Pouatcha <[e-mail]>]

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/