Re: [GNAP] Distinct role used by End-user to give permissions to client instances. Sat, 04 September 2021 14:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D6693A18F3 for <>; Sat, 4 Sep 2021 07:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (public key: not available)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7ju11CmfV2HI for <>; Sat, 4 Sep 2021 07:43:24 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:10a:28c1::32]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 031753A18F1 for <>; Sat, 4 Sep 2021 07:43:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35EED6B5D8 for <>; Sat, 4 Sep 2021 14:43:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=modoboa; t=1630766594; bh=2LlNPS+abv5Cat4deMHCRPyngZNSg7oGM20GXKO60Zc=; h=Date:From:To:Subject:In-Reply-To:References:From; b=VAPwAub297KdlkjHOk7mSW3gRfPF4YsKss4qvewBvbb6QZ5vR7vS2UsqXcNiiExqY WdFzRNPszAaSwKbxWf2ywaTpbbg6PSAKidmIU/iQfqpkkDgA/E/EZEcD/MfrjRK8HA QL48hGH/3qabaecYPrvreo78nBXs0rXxvLd9HmF15umLvxERvc52cbGDx8oUk2KiLe 3mqY3LptEmXjsT7HZHssfgupeWIXsqq32a02arukH68sS+6xd0BJSD1Bku73RBvhZR wrZx5w5AZGv2OgWPd4gkAhPwMjknPuOD4c4eOys1gBUw+yLNUhXMhlFFe7jkCpYoCS 3qorxVXq85Q0A==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id GF6JwMCltGJ7 for <>; Sat, 4 Sep 2021 14:43:12 +0000 (UTC)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA for <>; Sat, 4 Sep 2021 14:43:12 +0000 (UTC)
MIME-Version: 1.0
Date: Sat, 04 Sep 2021 09:43:12 -0500
In-Reply-To: <>
References: <> <> <>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [GNAP] Distinct role used by End-user to give permissions to client instances.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 04 Sep 2021 14:43:30 -0000

Hi Adrian, Fabien,

Thank you for your responsens!

> If the RS / RO is truly acting as an RO and owes relatively little
> to Alice and Bob, then the protocol would be easier because the EUXS
> would have less information to work with. In the limit, Alice’s
> EUXS would not even be notified of Bob’s access to the shared RS.

I think I'm discussing this case. Here both End-users Alice and Bob
each one has EUXS they choose to use. Similar to how each Alice and Bob
can choose their OIDC Provider.
When ACME (RO) sets access policy, they grant access to End-users like 
Alice (EU) and Bob (EU)
and let them permission clients independently using their EUXSs.
We work on notification system so that Alice's EUXS would get notified
when ACME shared access with Alice. When ACME shares access with Bob
Alice's EUXS has NO knowledge of that happening, only Bob's EUXS
will get notified.

>> Notification as part of an authorization protocol is, in my
>> experience with UMA 2, an option.

Yes, as I mentioned when RO gives access to some EU, that EUXS of that 
EU gets
notified. To clarify, similar as OIDC Provider, EUXS can be discovered 
for any EU.

> In GNAP section 4 (of the core spec) theorically allows the case when
> the end-user and the RO are different. The details of how that would
> work in still quite thin (and the rest of section 4 considers only the
> case when they're the same).

In the scenarios we work with, different EU and RO is a very common 
Here I'm trying to focus on most common scenario where RO sets access 
only based on identities of EUs (In our case IRIs are used to identify 
Later EUs, independently from RO, can permission clients they are using.
In the end RS and AS associated with it, the one that RS hints in
WWW-Authenticate using as_uri, need to take into account policy set by 
which determines access for given EU, as well as permissions given by EU 
the Client. Mentioned

> Seems to me that your use case is also relatively close to having to
> manage several ASs, with one that's associated to the RS (a case
> entirely made possible in GNAP) and one handling permissions tokens
> (to take your wording). Similar scenarii have been discussed in the
> past. Currently we assume in GNAP core that there's only one AS
> involved, but it's entirely possible that an extension would really
> get into the weeds of how more complex cases would work. That's kind
> of the spirit behind the RS part of the spec, and the entire
> discussion on capabilities. Please see
> as a
> pointer.

I think we would always have specific AS associated with RS. Again RS 
advertises it
via WWW-Authenticate as_uri . It issues Access Token which client is 
using with that RS.

I probably haven't mentioned that in our scenario End-user is using 
client to seamlessly
access resources in any number of Resource Servers, where each RS can be 
controlled by different RO.
Client would keep track of which Access Token should be used with which 
For that reason we also don't expect client to redirect EU to any of RS 
associated ASs.
EU would only give consent to the client at their EUXS.

Suggested EUXS would be something closer to OIDC Provider. It stays 
with EU, similar to rel="".
EUXS keeps track of all the data that any number of ROs shared with the 
EU. Based on that it presents
consent screen to EU where they can decide which of that data they want 
to access using given client.
As I mentioned, EU shouldn't interact with any of RS associated ASs.
Client should be able to get 'permissions token' from EUXS for each 
distinct RS
(each RS can be in control of different RO). Later Client would exchange 
that 'permissions token'
with AS associated with RS that this token was created for. This should 
happen without End-user

Probably it can be useful to discuss it in terms of delegation chains.

1. ACME (RO) delegates some access to Alice (EU)
2. Alice (EU) further delegates some of the access, which she received 
from ACME (RO), to a Projectron (Client)

More advanced case, which I intentionally tried not to start with would 
allow longer chains

1. ACME (RO) delegates some access to Omni (EU-ish) - Omni another 
2. Omni (EU-ish) further delegates some access their received from ACME 
(RO) to Alice (EU)
3. Alice (EU) further delegates some access, which she received from 
Omni (EU-ish),
    which they received from ACME (RO), to a Projectron (Client)

Having just one RO associated with any RS probably makes both scenarios 

Again I think only RS associated AS should issue Access Token that it's 
used with RS.
EUXS would issue 'permission tokens', similar to OIDC Provider issuing 
ID Tokens.
I imagine those 'permission tokens' later being exchanged with RS 
associated AS
without End-user interaction.

BTW I think this comment in mentioned issue provides a useful hint.

> If an AS receives and processes an access token, it is acting as an RS.
> There are two transactions at the same time and one entity plays 
> different roles in each.
> If an RS requests a token in response to an incoming request, that RS 
> is now a client instance.

> Now to answer your question in detail, I guess we'd need to map the
> flows and see how that goes.

I have some sequence diagrams which I can adjust to illustrate discussed 
scenario better.
I will also try to clarify there which role any given party plays in 
each interaction.
I'll write a followup message once I have them ready.

Thank you for all your feedback!
elf Pavlik