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

elf-pavlik@hackers4peace.net Fri, 03 September 2021 13:55 UTC

Return-Path: <elf-pavlik@hackers4peace.net>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907023A1F48 for <txauth@ietfa.amsl.com>; Fri, 3 Sep 2021 06:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level:
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=hackers4peace.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32xVy-S-Wt0X for <txauth@ietfa.amsl.com>; Fri, 3 Sep 2021 06:55:14 -0700 (PDT)
Received: from email.ecobytes.net (email.ecobytes.net [176.9.199.32]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984153A1F4B for <txauth@ietf.org>; Fri, 3 Sep 2021 06:55:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by email.ecobytes.net (Postfix) with ESMTP id 471BF620CE for <txauth@ietf.org>; Fri, 3 Sep 2021 13:55:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers4peace.net; s=modoboa; t=1630677308; bh=DUUubME+EHNUwZqTgViJyez3Xpof9ayxroYbo0yE4ic=; h=Date:From:To:Subject:From; b=l7g2Bz3e+ZMTA1vXzT6Yw24neqiEZvLtIX3clH9W6UWt2AXm3IpVzcK7LSnq08MBD Ug3EmJxGQQOrvj/rMpZIURyP6s3YTNSIjzyoqTKpEmwdO9SD7JrQOBxU3KKipZ4Qoe EG8V9eQu+jbSsW92HB8eBzagEp2y57xCQG694vEMMyGvTfPjYkyFTvZVlJzOENR21y K28szz2pqLGjO2vUjWxeNi1p0r+f/h6IhENCL0ymZqHQLDRkShNDfmaXKRf1BInnoP ciWTi/tlGKEivpz8Pu0bC7ON+/jIJnllOWUSCutKXa/tA1uBeP+NyEYSSlcbFalzGX vyMcszaZtX0qQ==
X-Virus-Scanned: Debian amavisd-new at email.ecobytes.net
Received: from email.ecobytes.net ([127.0.0.1]) by localhost (email.ecobytes.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mkgenr_RZtPs for <txauth@ietf.org>; Fri, 3 Sep 2021 13:55:06 +0000 (UTC)
Received: from webmail.ecobytes.net (geogale.ecobytes.net [88.99.144.132]) (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 email.ecobytes.net (Postfix) with ESMTPSA for <txauth@ietf.org>; Fri, 3 Sep 2021 13:55:06 +0000 (UTC)
MIME-Version: 1.0
Date: Fri, 03 Sep 2021 08:55:06 -0500
From: elf-pavlik@hackers4peace.net
To: txauth@ietf.org
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <10c8c1d93688494588a9d7032a0aa37d@hackers4peace.net>
X-Sender: elf-pavlik@hackers4peace.net
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/nhV4f59Xf5EaZ8c-YjkWWN6oCr0>
Subject: [GNAP] Distinct role used by End-user to give permissions to client instances.
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Sep 2021 13:57:11 -0000

Hello,

I'm participating in AuthN and AuthZ related work of 
https://solidproject.org/

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="http://openid.net/specs/connect/1.0/issuer" 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