Re: [OAUTH-WG] Transaction Authorization with OAuth

Jim Manico <jim@manicode.com> Mon, 22 April 2019 16:11 UTC

Return-Path: <jim@manicode.com>
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 AF8DE12009E for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 09:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.com
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 lFg444pxQZiW for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 09:11:02 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540F9120077 for <oauth@ietf.org>; Mon, 22 Apr 2019 09:11:02 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id t20so607802otl.5 for <oauth@ietf.org>; Mon, 22 Apr 2019 09:11:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7F40M1y7vwWpvCnocluvjoMFX9J3CZPFRiAzN7bwJR4=; b=lUqx+PZZS7iRcCf9cRN2Y9cQ8FKOBw9M0PgQ1hPVB0icDvfX6bXwGC3/rdYdmfXb1Y 6g1I0e+O7tEeBoa4XYsNQeVxkLyqgLnhyKYrqI0SXBmCBkGL/rb0/yQHqRAzHcBk1moz zPD5eV4PyjBDVJQz3MzsJBfe5vX4Xzk1D84Jn5Qv3k3C1viBc4MiFtKBp9vMiYlS6PTT QhCCTogcfCM3k1GzydgTPeV67NQNu15B+h4BNgeV9QhECIaSSPlsxJ31hixb0Z1GeMBU rvjYA5xqawwMXlFee1cdbGOY6wD28DFVR6mUGbmNWKEBzZHLfrbJMoKHenUKpixsbxqT rp7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7F40M1y7vwWpvCnocluvjoMFX9J3CZPFRiAzN7bwJR4=; b=UrcVpcWMZl7SW4xpAXpwbYrLJPJumt6Ga4dj2wWqfot+HcszFmWO/BlPudtbo6ZWWj 7VxzT72r7+6A+F+av7DOsNcM5wx5bKofqO3eXqfBnymmlBSG25A8b6GEHotcRO3zc3dN CcSYQeiVtA4+YhFz2G4ERwlM+zZeiQb3bzR4++JFzhCsHHXOcpHFh5ac7pJEGtU4zzEw 5PUmtHumhCaJ3xqxQZJyQRuBHSOtjj2NW2L1G5AuGo7BjIf5XqQVDx+iDFCqOaQg4nPN WQAVXuOUzZ3M23BK6AglU93jrtRwtQdhq51qZYZ4v+/ZT/vRV6aFJHZVKWtwiR4Q8f55 8p3A==
X-Gm-Message-State: APjAAAXBs9mG6n2dq3/oNPlLxiCnjf/qPpQ2PLZcmVYfgH0+MHUvENfl bw+wVn624lS75IAqiUQI6g2jEflZtmk=
X-Google-Smtp-Source: APXvYqy7z2ZWr9/y91iV1Nk3/U3X+BaYDzvmLZOQbIrCSh//tq6b0xX+ZgT22QmLn9LPzT0tTIFvGQ==
X-Received: by 2002:a9d:12a2:: with SMTP id g31mr13144593otg.174.1555949460987; Mon, 22 Apr 2019 09:11:00 -0700 (PDT)
Received: from [10.233.85.132] (mobile-166-137-219-069.mycingular.net. [166.137.219.69]) by smtp.gmail.com with ESMTPSA id z12sm5622408otp.2.2019.04.22.09.10.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Apr 2019 09:10:59 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-63316A54-7CDB-47CD-8E9A-5BC0C3194676"
Mime-Version: 1.0 (1.0)
From: Jim Manico <jim@manicode.com>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <CAJrcDBfmhR5Fx1okJv7xdgATytDTA8rhBZNJJviY39WGK06uPw@mail.gmail.com>
Date: Mon, 22 Apr 2019 11:10:58 -0500
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <981DFB7E-4EA6-4C66-8B78-F6FE3AC2B712@manicode.com>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <CAJrcDBfmhR5Fx1okJv7xdgATytDTA8rhBZNJJviY39WGK06uPw@mail.gmail.com>
To: Pedro Igor Silva <psilva@redhat.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/umIaBlcqjQ8hmql7Q0e17FF0eeE>
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:11:06 -0000

Have you looked at other standards that address find grained access control like NIST ABAC or XACML? This is a somewhat solved issue and I wonder if previous work can be leveraged. 

A basic string “scope” is certainly not enough to represent and transport complex authorization policy. I would imagine that something closer to XACML would work.

--
Jim Manico
@Manicode

> On Apr 22, 2019, at 9:34 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
> 
> Hi Torsten,
> 
> Great article, thanks for sharing it.
> 
> 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). 
> 
> 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.
> 
> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth