Re: [OAUTH-WG] Transaction Authorization with OAuth

Pedro Igor Silva <psilva@redhat.com> Mon, 22 April 2019 19:36 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 2EBE5120123 for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 12:36: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 E8KF1rMymdQD for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 12:36:32 -0700 (PDT)
Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 9237012014E for <oauth@ietf.org>; Mon, 22 Apr 2019 12:36:24 -0700 (PDT)
Received: by mail-vs1-f41.google.com with SMTP id e2so6851693vsc.13 for <oauth@ietf.org>; Mon, 22 Apr 2019 12:36:24 -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=2imgW72nJKPdiQdcHMoJBkGY26JkmtNYApFbwKUfnaA=; b=Qlu0QrKpAAuFyyPDvMiWZUYsX8sLShhIn1dfTP5YTfNL3FRoXCutPLsShjhPO/rlcG BfiglLscU3D3236FI4Rv+f5Vh4VuXJFad+JvQPWrSHqMa3zfmWRYrNr24ouvcysV0gt1 QjR/7B+/Wra7JLUOsbOgqf5otC+YrWHG7TBLO7rVsB6Ra7BWPRFzqb9QpTP1G2twni9d KQbveBEpDkVmHyBwuq4OGk3XXm9+Q+58xqyY1hWx77uZ1VoOeeBwOcNXQ8q2U7IwMaTS gbKljT/erhv/F7SGqMoqE/8GGMuftZuixcJ7Q872ZahINfnPlAN4MzJ8X+SSSi7hTr3p Zr9w==
X-Gm-Message-State: APjAAAWeM78ZBxWKIqyLnF7Ghsxa7jiAnPYZkN84XzB0itC2i4WNxNtA Z/gi+blhg9xlK+2QbYZ2ZSrh8i/USxldzxMNGKFV7g==
X-Google-Smtp-Source: APXvYqxr7tvylbh9P73dd3KKEarS0tPoqnSv0I8XyDVVMHBwhAuIFsRe3eHdWfRZMLMYD8z+myIWTE3ka7mUZKLlWrw=
X-Received: by 2002:a67:7b53:: with SMTP id w80mr11367640vsc.144.1555961783457; Mon, 22 Apr 2019 12:36:23 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <CAJrcDBfmhR5Fx1okJv7xdgATytDTA8rhBZNJJviY39WGK06uPw@mail.gmail.com> <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net> <CAJrcDBcm0x6zzWYBxjh4B8EJQozFC1ciyx5_j2rnW8DBLGqUCg@mail.gmail.com> <B41AFDAE-CE92-4477-8489-F47C05A4DD3E@lodderstedt.net> <7483a5f0-b3c1-c944-02fa-79e5a1ecc490@aol.com>
In-Reply-To: <7483a5f0-b3c1-c944-02fa-79e5a1ecc490@aol.com>
From: Pedro Igor Silva <psilva@redhat.com>
Date: Mon, 22 Apr 2019 16:36:12 -0300
Message-ID: <CAJrcDBeHHymY_Lk-oJV+M+S3Hvsw=CLBZMbeStk7Gm55ecYBuw@mail.gmail.com>
To: George Fletcher <gffletch@aol.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000063372f058723954d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/sNIA2OUGwbRvy8Rzpdq74E6bhNQ>
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 19:36:35 -0000

I think this knowledge by clients of the ecosystem is something that a
transactional authorization could avoid. Both UMA and ACE have solutions
that make clients really dumb about what they need to send to the AS in
regards to scopes. IMO, the RS should have the possibility to tell clients
the scope they need, making a lot easier to change RS's access constraints
as well as pushing contextual information that could eventually enrich the
authorization process.

On Mon, Apr 22, 2019 at 4:04 PM George Fletcher <gffletch@aol.com> wrote:

> Speaking just to the UMA side of things...
>
> ...it's possible in UMA 2 for the client to request additional scopes when
> interacting with the token endpoint specifically to address cases where the
> client knows it's going to make the following requests and wants to obtain
> a token with sufficient privilege for those requests. This requires a fair
> amount of knowledge by the client of the ecosystem but that is sometimes
> the case and hence this capability exists :)
>
> On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:
>
> The problem from my perspective (and my understanding of UMA) is the RS does not have any information about the context of the request. For example, the client might be calling a certain resource (list of accounts) and immediately afterwards wants to obtain the balances and initiate a payment. I think the UMA case the RS either predicts this based on policy or past behaviour of the client OR the client will need to issue several token requests. That might not be a problem in 1st party scenarios but it is in 3rd party scenarios if the AS gathers consent.
>
>
>