IETF Logo Mail Archive

Re: [OAUTH-WG] Transaction Authorization with OAuth

Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 23 April 2019 05:04 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 9BF811203C9 for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 22:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Y27UA_nAIAAY for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 22:04:32 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (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 897191203C7 for <oauth@ietf.org>; Mon, 22 Apr 2019 22:04:32 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.105]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1hInbY-0003Wk-4A; Tue, 23 Apr 2019 07:04:28 +0200
Content-Type: multipart/signed; boundary="Apple-Mail-609F5A27-AAC3-4091-858F-13BF7C395337"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <7483a5f0-b3c1-c944-02fa-79e5a1ecc490@aol.com>
Date: Tue, 23 Apr 2019 07:04:27 +0200
Cc: Pedro Igor Silva <psilva@redhat.com>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <F7C4C5AC-F83E-476D-B280-D4E97DE57772@lodderstedt.net>
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>
To: George Fletcher <gffletch@aol.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/v-x9vX8z8DZkAa4-2yUruu8-Qlc>
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: Tue, 23 Apr 2019 05:04:36 -0000

Does UMA use the standard scope parameter?

> Am 22.04.2019 um 21:03 schrieb George Fletcher <gffletch@aol.com>:
> 
> 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. 
>

v2.23.0 | Report a Bug | By Email