Re: [OAUTH-WG] Transaction Authorization with OAuth

Pedro Igor Silva <psilva@redhat.com> Mon, 22 April 2019 14: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 4332012004E for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 07:35:05 -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 92sV3oSHEsOQ for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 07:35:03 -0700 (PDT)
Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) (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 CFB80120004 for <oauth@ietf.org>; Mon, 22 Apr 2019 07:35:02 -0700 (PDT)
Received: by mail-vs1-f53.google.com with SMTP id e2so6305368vsc.13 for <oauth@ietf.org>; Mon, 22 Apr 2019 07:35:02 -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=sN7W30FS9cBYOdJ0Rv0F9KtsNuJcS/cnlbPrHrKZc5E=; b=iccgn1jkkXDWVD6aSBa7WLiSXIUQoTLCAO9qiUFF82Om60uXmrmmau3XnV1z/eZxp7 CRnKw9M7nclt4xinb5M7g6wUOA4DdKeSXMOo0i3opOHpW1wwgxHagmQZdpSz6t0pBTuQ SthlMN1HKb+XgO2HgUvt5qWPyIOSRb1nt7KaPrWwYI5MogzIb+DuS0pXVoz+cPm8ER+2 tqALbFgMZFicsi0hdhjV/Hc+zu6MxBXtE5AswnDbyID3tcpRSZCuPERGCOY22nG0C3Pt a2qvhIKU8V9VtLdUZmJW6eBcxrBjrsxEO+dEJu8ZSI+TkXNkJWvmWzts7ANxMSe2n3gG k3+Q==
X-Gm-Message-State: APjAAAVNuHxXksBmmYyBZ0Uu8O8FlKwIEW1gDHxP21PYsmlpZtgQhpSG ckGFmhR8LsG+GO1mmscPrqBlFDGcq1oPJKXmfJL2Mhwe77s=
X-Google-Smtp-Source: APXvYqwq5UaGs+7HySFZBL51PoFuGQdfYAoiOFk/k52K4wVTvKHtnJY0u86gMfjMak3FsvOZvPFPVEDWbq5lta1F2S4=
X-Received: by 2002:a67:ef8d:: with SMTP id r13mr10184427vsp.6.1555943701309; Mon, 22 Apr 2019 07:35:01 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
In-Reply-To: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
From: Pedro Igor Silva <psilva@redhat.com>
Date: Mon, 22 Apr 2019 11:34:50 -0300
Message-ID: <CAJrcDBfmhR5Fx1okJv7xdgATytDTA8rhBZNJJviY39WGK06uPw@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009b834405871f5f19"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/AqTMi8Df1WFt8wCKligJjKBdKu8>
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 14:35:05 -0000

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
>