[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
- [GNAP] Distinct role used by End-user to give per… elf-pavlik
- Re: [GNAP] Distinct role used by End-user to give… Adrian Gropper
- Re: [GNAP] Distinct role used by End-user to give… Fabien Imbault
- Re: [GNAP] Distinct role used by End-user to give… elf-pavlik
- Re: [GNAP] Distinct role used by End-user to give… Justin Richer
- Re: [GNAP] Distinct role used by End-user to give… elf-pavlik