Re: [GNAP] Distinct role used by End-user to give permissions to client instances.

Fabien Imbault <> Sat, 04 September 2021 07:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DB023A1EB0 for <>; Sat, 4 Sep 2021 00:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KbAMATQL0hmU for <>; Sat, 4 Sep 2021 00:35:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 237D83A1EAB for <>; Sat, 4 Sep 2021 00:35:18 -0700 (PDT)
Received: by with SMTP id m11so1447379ioo.6 for <>; Sat, 04 Sep 2021 00:35:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pmS1go0WnpP439kgcncMA/71AtbysBGfCqgsvsA6p2w=; b=Rep6CSYYKab2PTzjQqYB4uKOtRBoUgY0bAVD5VTr4iI17zaC0Uu6+rWSxWHuVVPm1d 4kIJnmw0KlTaz5L22JcY1yNYlH0cr2dA0fq3qg0yQHd5tssPjkRNXSNELOQDUFwhfrSM u2Zin0USOfpnH/2rP2St/FLiZLvh/oFGyejucCdt7NJxtRNLWV1tya5zSWu8AP9IaHdz R+mHHZVnoDx1dEPY9vdbONVvks65wX78OfJkCttESr5j/+RFXnkHsmA5kzyqG82iWMoM HXx1cQUbZOkK1nhsFTkYqPgpyCaqFZw5H4eglTqWfotPyynZhcxENdWOkSYIGN4LG6hP GNTA==
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=pmS1go0WnpP439kgcncMA/71AtbysBGfCqgsvsA6p2w=; b=byYST4i43xQB+Vp/bCBRDB1dbBuTFLLxVpxDLVeR7bY1XMCOqRtu2o3kFGWKYTwOxv SkD3dXkzzGf/BJRJQ0QlHg3ybWUYdrdvnNTbtP+esQqwMc0tKk/7BfnL3PHYWF14DgFa 9o+WnqrDjj7zADZwOrM36h8s+RB64cVGr8cIjeRNRPQIwZ+4VI+gDGDg/ERLl3/sKBlc 38d3LHINUWfHPINX4EReaBw/CJF1JLJTbErk+jXyDk2d312CA7vRAwSV6wM+8jmozUmU MiS6eZEh2VIqnMiNc6Iai9ijbKVH1HthmOxjsBhjVhwKls0ERvYPkK0Ijbvkj5xtGCmF FyQg==
X-Gm-Message-State: AOAM533uaQ5aZdVbrTc/kwik0AUd4ycOmTBXFPtziimSBtsfA3IaPV3C UU6ilsmPI2C/gpo2p/pFptWL/1WWD14Vh9xkD1bw8poX97o=
X-Google-Smtp-Source: ABdhPJyRphGJh/XG/XkG8vIEoaYXNjhEDm+oPssJ0noCPy5Bx3hC/Z5tcK2y6R0brqk0f8NP+xCwGFoP0vC6pmEToxY=
X-Received: by 2002:a5d:9da4:: with SMTP id ay36mr2196031iob.153.1630740916513; Sat, 04 Sep 2021 00:35:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Sat, 04 Sep 2021 09:35:05 +0200
Message-ID: <>
To: Adrian Gropper <>
Cc:, GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="0000000000000cb28105cb267522"
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 07:35:23 -0000

Hi Elf,

Indeed that's interesting. I'm not entirely sure I get all the ins and outs
of what you're trying to do, but I'll give a first answer based on my
limited understanding.

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

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

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


Le ven. 3 sept. 2021 à 21:50, Adrian Gropper <> a
écrit :

> An interesting use-case. One way to discuss the protocol issues is from a
> transparency perspective.
> If the RS / RO is presumed to be operating as a (regulated or informal)
> fiduciary with no conflict of interest for its own profit, then both Alice
> and Bob should have total transparency on what is actually shared with the
> other. That transparency and potentially semi-autonomous behavior would be
> managed by the respective EUXS agents.
> 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.
> Notification as part of an authorization protocol is, in my experience
> with UMA 2, an option. Even when the RO is the subject and separate from
> the RS, the RS may override the scope of an access token. This could be due
> to security (e.g. DoS attack) or jurisdictional constraints (cross-border
> clients). In these cases, transparency demands that the RS notify the RO or
> the AS of the exception.
> - Adrian
> On Fri, Sep 3, 2021 at 9:57 AM <> wrote:
>> Hello,
>> I'm participating in AuthN and AuthZ related work of
>> I will intentionally keep this email short and provide further details
>> based on responses.
>> Given that I'll try to focus on one problem we are trying to address and
>> we can start zooming out from there as needed.
>> In our scenarios different End-user and Resource Owner is very common
>> scenario.
>> We are working on few proposals for handing User Authorization, in that
>> case ACME organization (Resource Owner) could authorize Alice (End-user)
>> to access specific data.
>> In the same way ACME authorizes Bob (another End-user) to access some
>> specific data. Data that Alice and Bob can access have certain overlap.
>> Now both Alice and Bob should be able to independently permission /
>> authorize various applications (Client instances) they wan to access
>> that data owned by ACME.
>> In fact both Alice and Bob have broader peer networks, including other
>> Organizations and Individuals. We are also defining common permission
>> model,
>> which would allow expressing application access to span across data
>> owned by any number of owners.
>> In the scenario above, we consider assumption that given Resource Owner
>> owns all the data on given Resource Server.
>> In that case Authorization Server which issues Access Tokens stays
>> associated with RS, so also with specific Resource Owner.
>> Since each End-user needs some party which would take responsibility for
>> them to give consent and permission apps (Client instances) they are
>> using.
>> We look at another role let's just call it EUXS (End-user's X Server),
>> similar to OIDC Provider. It stays associated with End-user in similar
>> way to rel="" links to OP.
>>  From here it would be really great to see how GNAP would help handing
>> following:
>> End-user's X Server, in a similar way to OIDC Provider, issues at token
>> (let's call it a permissions token) to Client instance representing
>> permissions applicable to a specific RS.
>> Once again very often that RS is controlled by Resource Owner other than
>> End-user.
>> Client instance uses that 'permissions' token with AS to get Access
>> Token which finally can be used when making requests to RS.
>> Here I make assumption that AS understands that permissions token and
>> later either makes it available to RS or translates it to something that
>> RS can enforce.
>> Oh, also RS would hint their AS with as_uri in WWW-Authenticate, since
>> client doesn't have that prior knowledge.
>> As I mentioned User Authorization is handled separately so AS & RS have
>> prior knowledge of what access Resource Owner granted to End-user.
>> In this email I mostly focus on End-user having another party associated
>> with them (EUXS for the sake of this discussion) where they
>> can further delegate that access their received to apps (Client
>> instances) which they want to use to exercise access to data.
>> I hope description above is sufficient to roughly illustrate the
>> scenario. I can fill in more details as needed.
>> I very much appreciate any hints on how GNAP can handle described
>> scenario in elegant way.
>> Best regards,
>> elf Pavlik
>> --
>> TXAuth mailing list
> --
> TXAuth mailing list