Re: [GNAP] Distinct role used by End-user to give permissions to client instances. Thu, 16 September 2021 03:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E8773A0BEF for <>; Wed, 15 Sep 2021 20:04:35 -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 OlhFnwPhAgcZ for <>; Wed, 15 Sep 2021 20:04:30 -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 5057D3A0BE9 for <>; Wed, 15 Sep 2021 20:04:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FADC8E474 for <>; Thu, 16 Sep 2021 03:04:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=modoboa; t=1631761462; bh=PEq33pOQ1wDEE/+CZMvAhT14yoZdKkZ1syYxp8vGuBU=; h=Date:From:To:Subject:In-Reply-To:References:From; b=EPvc3I4kJedz26Rad1QOrpQBrmHfZhqOHoqQxOIgfM7ClwkrQXgqFXusXwyxkoBLl SF0gd2EqGAI9spV6z7Oa72KGuQzQc1N2EfoQ8yph7w4w44fRykGE/s7yNxN+5H2gUl 7ll0xE89yZRS9ZTITJjN+bwAbIJM6debaV+x9gYIvmnBFDrbs8PJ7E/bHxsYMPsrDf RO6dkI+JKoL4GKJ70Vp/AUVRpmp8fw8PpPnj6c0c5bA7xo3EddMMUESHNUjOkflQzp mUIiNzZvDdkkkeXXdssh0zkJm2VLAcZIygSAEDgYcsBfYxHHpt0PuDb1HSI9I0Ya9x sMjKcgIiERFhA==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id OYXPAuZ353hN for <>; Thu, 16 Sep 2021 03:04:20 +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 <>; Thu, 16 Sep 2021 03:04:20 +0000 (UTC)
MIME-Version: 1.0
Date: Wed, 15 Sep 2021 22:04:19 -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: Thu, 16 Sep 2021 03:04:35 -0000

Hi Justin,

Thank you for your in-depth reply!
I'll try to respond in-line.

> Phase 1: Client Instance makes a request to EUXS for an assertion
> representing the current user. The nature and format of this assertion
> are out of scope for GNAP itself, but would be in the purview of
> Solid’s profile of the technologies — for now we’ll call this a Solid
> Assertion Token (SAT) within this description. A JWT would be a
> reasonable carrier for such an assertion. What GNAP offers is a
> standard way for the client instance to request this assertion and
> have it delivered directly. We’re assuming that the end user interacts
> with or otherwise associates with the EUXS so that the EUXS knows who
> the end user is. Or possibly, the EUXS knows that the client in
> question has already been authorized and can issue the SAT directly.
> GNAP allows for both scenarios to come out of the same request
> message, allowing for a clean fallback in different situations.

I haven't mentioned it (trying to start as simple as possible), but we 
possibility of having separate IdP and EUXS.
The IdP would stay in line with OIDC and issue assertion representing 
the current end-user.
Trying to follow your naming we could call it Solid Identity Assertion 
Token (SIAT)
The EUXS would stay responsible for issuing an assertion representing
'permissions' - what access end-user delegates to the given client 
We could call this one Solid Permissions Assertion Token (SPAT)

While we evaluate defining separate IdP and EUXS, we also want to
support combined IdP+EUXS which could combine user interaction
into a single flow.

So far I think both IdP and EUXS act as AS. Until now also the
End-user acts as RO who controls issurance of both assertion SIAT and 

> Phase 2: Client instance talks to the AS that controls access to the
> RS. The client instance presents the SAT as part of its “user”
> information field in the request. The AS validates the SAT based on
> Solid’s rules. The AS contacts the RO to get permission for the client
> instance on the end user’s behalf. How that happens is up to the AS,
> but the SAT would likely have some kind of RO identifier within it:
> namely representing what’s being requested, not who the SAT was issued
> to. Or it could be based on the RS and permissions the client instance
> is asking for — so the client instance and end user wouldn’t
> necessarily know who the RO was at all, just that they want access to
> the RS and it’s controlled by … someone. Once the RO approves it, the
> AS issues the access token to the client instance.

The SPAT would indeed contain information about what client can access
on a given RS. Actually EUXS would most likely need to issue one SPAT
per RS that End-user wants to access using the client.

Currently we look at approache where RS has only one RO which has
full control over all the Protected Resources on that RS.

At the sime time End-user will be using the client to access resources
across any number of Resource Servers, where each RS can be in control
of different RO.

Having one SPAT per RS should preven any undesired leak of information
across those different Resource Servers.

What I need to emphasis here, RO who controls given RS, doesn't really
get involved in authorizaing client instances (unless they also act as
End-user of that client). RO grants access directly to End-user,
than End-user can authorize/permission clients they use via EUXS,
independently of RO associated with RS.

Here also EUXS is responsible for authenticating the client,
AS associated with RS relies on client identity from SPAT.

When it comes to flow where End-user wants to request access to
resources on RS (RO != End-user). We consider their EUXS would
handle it for them. Once the End-user has access, they can delegate
it to any clients they want to use to excercise it.

> Phase 3: Client instance calls the RS with the access token from AS.
> It may or may not contain any information from the SAT, since the only
> thing the RS ultimately needs to know is if the token is good for the
> request being made. Solid can further profile the access token itself
> (either its format or its introspected data) to convey specific
> information. GNAP remains agnostic on this decision, but provisions
> for standardizing these elements are in the GNAP-RS document.

Yes, I think this part seems straight forward.

> An alternative process inverts some of the phases:
> Phase 1 (alt): Client instance talks to the AS to get access and says
> it can interact with the end user through the EUXS and get an
> assertion (SAT) as a result. The AS passes whatever information it
> needs to complete this back to the client instance. The end user
> interacts at EUXS to get the SAT generated and handed back to the
> client instance.

I need to think further about this flow. Currently we focus mostly
on flow where client starts 'following their nose' from End-user
identiy, discovers their IdP and EUXS (this information is public).
Later EUXS provides an entry point which has index of all the data
across all ther RS that End-user wants to access using given client.
Given above client interacts with EUXS before interacting with any
RS and disovering AS that controlls access to it.

> Do either of these processes align with what you had in mind, or am I
> missing some important subtleties to this use case? We’ve discussed
> both of these patterns here in the WG before and accommodations for
> them are built into the GNAP core protocol: both what it defines and
> what it allows but keeps out of scope of the core protocol
> definitions.

Yes I think it's pretty close. I hope I was able to highlight
additional nuances above.

Thank you again for taking your time to patiently disect
scenarios I'm working with.

Best regards,
elf Pavlik