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

Francis Pouatcha <> Thu, 13 August 2020 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A739D3A105E for <>; Thu, 13 Aug 2020 11:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7TdDypWk6e_i for <>; Thu, 13 Aug 2020 11:59:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CEEF3A106E for <>; Thu, 13 Aug 2020 11:59:31 -0700 (PDT)
Received: by with SMTP id 9so5551897wmj.5 for <>; Thu, 13 Aug 2020 11:59:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VWJkt9+1TILKT8hsutDCrRUbEU/liXYOhDTRZEEX7dk=; b=SrGUMe7baBegjdSV7+ok/o9Spu2dEb0s/pmS1ZyNNvNSyEi4fixgr03IhjEUjklzuO Yq5PdRugQ78y+8caAyBLqDsrk9TYM/NzVAB1SfqRGFnEl+X3sj5kXalqlqB55pj5IrD1 LRpg41kdjv7Xn22TjvrX1/Pd4DzHW6vcYWa/k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VWJkt9+1TILKT8hsutDCrRUbEU/liXYOhDTRZEEX7dk=; b=jmsvaFWu6JoCpasAo4T3VGH6fsNb9GVUXC/vdUYVeLRS16uYfSXaZXSWp1UmyK4/Mh O6U6yH9sp15SkxUHqSHwJyarL/8s7cntuBJ/DRO7GI6eLLDhYfuuJ+zBzF4fs1StP3pf q/oFTJNayC77bu2Zar89KeK2hiJeXhQ1yUhAidHEGclLiM5+ZQxKyud7yWR6GXB52HJB 55wXtN7X9wxIy0fkDrzZJUuonc+7IbZn0A039fhXWRw5MIOMUcx8f0D7vRGw5/zBHIxX 14IHj6E+/lG0DSAFLW/NEApnzbAhFYKdwh1Hgw5o/7xILcygTFlhCmdxGhx/aX3GBV3u RWTg==
X-Gm-Message-State: AOAM532OXzFcWa8ut1J/vVE4L4hPsNXPpnHZwA5FFhg4XtO0hL/KjO5M PQetgV7RF0yq/VWBzSZ/b7MaJrtdisHd3Wbg9WmlrQ==
X-Google-Smtp-Source: ABdhPJx169ajI/bGbStYjaKTH6QWF+tBxALdVm4/8Gogz3HNPAp9wpd0iZ2f29iuVpmZZkWzGn4TKqKoGzFOf+FfGPo=
X-Received: by 2002:a05:600c:2157:: with SMTP id v23mr5370072wml.38.1597345169637; Thu, 13 Aug 2020 11:59:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Francis Pouatcha <>
Date: Thu, 13 Aug 2020 14:59:18 -0400
Message-ID: <>
To: Denis <>
Cc: Justin Richer <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000006b9af005acc6e79f"
Archived-At: <>
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Aug 2020 18:59:41 -0000

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

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.

On Thu, Aug 13, 2020 at 1:30 PM Denis <> 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

Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG