Re: [OAUTH-WG] Transaction Authorization with OAuth

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 22 April 2019 16:33 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495D41200A0 for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 09:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 pZMcSnIeIqcN for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 09:33:54 -0700 (PDT)
Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524EE120129 for <oauth@ietf.org>; Mon, 22 Apr 2019 09:33:54 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1hIbt9-0000XU-H2; Mon, 22 Apr 2019 18:33:51 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <CAJrcDBfmhR5Fx1okJv7xdgATytDTA8rhBZNJJviY39WGK06uPw@mail.gmail.com>
Date: Mon, 22 Apr 2019 18:33:50 +0200
Cc: oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <CAJrcDBfmhR5Fx1okJv7xdgATytDTA8rhBZNJJviY39WGK06uPw@mail.gmail.com>
To: Pedro Igor Silva <psilva@redhat.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/_Hb51zApaApKkK_Z-YXDmRAPyKc>
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Apr 2019 16:33:56 -0000

Hi Pedro,

> On 22. Apr 2019, at 16:34, Pedro Igor Silva <psilva@redhat.com> wrote:
> 
> Hi Torsten,
> 
> Great article, thanks for sharing it.

my pleasure :-)

> 
> We have been working on a solution for fine-grained authorization using OAuth2 but specific for first-party applications where the granted permissions/scopes depend on the policies associated with the resources/scopes a client is trying to access. We don't have extensions to the authorization endpoint but a specific grant type for this purpose on the token endpoint.
> 
> The solution is similar to the Lodging Intent Pattern but also based on specific parts of UMA and ACE.
> 
> Basically, when a client first tries to access a protected resource the RS will respond with all the information the client needs to obtain a valid token from the AS. The information returned by the RS can be a signed/encrypted JWT or just a reference that later the AS can use to actually fetch the information. With this information in hands, clients can then approach the AS in order to obtain an access token with the permissions to access the protected resource.
> 
> The general idea is to empower RSs so that they can communicate to the AS how access to their resources should be granted as well as decoupling clients and RSs so that clients don't need to know the constraints imposed by the RS to their protected resources (e.g. scopes). 

Sounds very much like UMA2. The difference I see is the RS needs to be heavily involved in the authorization process (whereas the approaches I discussed leave it passive). How would you handle the use cases I described? So for example, how would you construct the JWT for the signature use case? I’m asking because the signing case uses more data in the authorization process and might bundle the request to sign multiple documents, even if the first signing request would only need the hashes or even just a single hash of a document. 

> 
> I've started to write a document with this idea in mind and I'm happy to share it with you and see what you think.
> 

Look forward to reading your article. 

best regards,
Torsten.

> Best regards.
> Pedro Igor
> 
> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> Hi all, 
> 
> I just published an article about the subject at: https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948  
> 
> I look forward to getting your feedback.
> 
> kind regards,
> Torsten. 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth