Re: [OAUTH-WG] Transaction Authorization with OAuth

Pedro Igor Silva <psilva@redhat.com> Mon, 22 April 2019 16:35 UTC

Return-Path: <psilva@redhat.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 9784812006A for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 09:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 t02habEuf14w for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 09:35:31 -0700 (PDT)
Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (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 2CA16120052 for <oauth@ietf.org>; Mon, 22 Apr 2019 09:35:31 -0700 (PDT)
Received: by mail-vs1-f46.google.com with SMTP id o10so6544816vsp.12 for <oauth@ietf.org>; Mon, 22 Apr 2019 09:35:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HWX2VLzW8+vPBaq4AStUPGNzvegrQ/STgh677g3s4j8=; b=hUAQwO5pg2tdK7jcEcknAjytb1i8Cv7ivD+PV+5cViZ/QfsNdYPCaJw7H6+pncURur XW76ChUo88O5r5hLhlItWwhpoWA1FGRJrTCefNDuYBaUkPfzuvqPQ8o/0g7pD168UtfD SpZTbAqjcjOBLlxJc4sWgIVrOEqOEhoqed0UfqjBLz/PWFRFJXbgpkvrpzsmhA+JoRyB 2hlzpjNkaF7QpKDbWGl529XnwKnJtgFzNjs+X3sGbW65Ez/5wAqBrxiIDCTj9AfM9HaI UlZyEjfiHh0RddbUwVSmFM7Gt/egKxp9945sChKRvHt05rN0/aq/nb8bwaLRJ+16/goE c6Aw==
X-Gm-Message-State: APjAAAXW69lmH5aB+HspEcs6nOALljqPoRkbvhaklEsGTGHADYK4/tYs 3oltcm47B+mUIjsd3xSQJzoR6ssl03WdLDhL7vKuaQ==
X-Google-Smtp-Source: APXvYqzTUdzjwC5cw/PPmuBTHKKQHmOCHG86eQHWGvQUMXbihgAEq+mXPt7IVlmh+6Yhr/9lMwBOi0AWEbV615I6Bu8=
X-Received: by 2002:a67:7b53:: with SMTP id w80mr10790913vsc.144.1555950929782; Mon, 22 Apr 2019 09:35:29 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <CAJrcDBfmhR5Fx1okJv7xdgATytDTA8rhBZNJJviY39WGK06uPw@mail.gmail.com> <981DFB7E-4EA6-4C66-8B78-F6FE3AC2B712@manicode.com>
In-Reply-To: <981DFB7E-4EA6-4C66-8B78-F6FE3AC2B712@manicode.com>
From: Pedro Igor Silva <psilva@redhat.com>
Date: Mon, 22 Apr 2019 13:35:18 -0300
Message-ID: <CAJrcDBctFixzPB+80QHcwDAFEPm_+=BwABMXCGFoWxvcnORMkg@mail.gmail.com>
To: Jim Manico <jim@manicode.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000754be70587210e16"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PiyiQGXcDTKOeHBME8shCeYq9aE>
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:35:36 -0000

Yeah, I did.

XACML is a good standard, even better after v3. We do have options to
leverage XACML policy language model to write policies, but protocol-wise,
something on top of OAuth, would be very nice. As an authorization
framework, fine-grained/contextual authorization seems to be a natural
addition to OAuth.

Regards.
Pedro Igor

On Mon, Apr 22, 2019 at 1:11 PM Jim Manico <jim@manicode.com> wrote:

> 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 <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
>> <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
>
>