Re: [OAUTH-WG] Transaction Authorization with OAuth

George Fletcher <gffletch@aol.com> Tue, 23 April 2019 11:32 UTC

Return-Path: <gffletch@aol.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 4929B12033E for <oauth@ietfa.amsl.com>; Tue, 23 Apr 2019 04:32:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 ZH64ma1kZCbw for <oauth@ietfa.amsl.com>; Tue, 23 Apr 2019 04:32:25 -0700 (PDT)
Received: from sonic311-13.consmr.mail.bf2.yahoo.com (sonic311-13.consmr.mail.bf2.yahoo.com [74.6.131.123]) (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 24F61120045 for <oauth@ietf.org>; Tue, 23 Apr 2019 04:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556019144; bh=huUOC5O97QsvQkGlhgw2hYeV+/kIBGIozJKVamw2fH0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=advU92qeuoLRqN/DPvkm/1PJhgWLJcL4XXGJ2YfQ15j62pbLtRfkHaylEw+LZMT1XuWOSrWUnxvu2CJ+4pazMenxOh83CFcwEYnCG12qCyQLWCd3ETms4v9DYwMmzfCL3S9FPkPqb1w86Hh6Y5+QZivixS3Hs0DEElh7vhqqrGHoaxqFzHkEDpshb6kyjSQy396JcOttWYx5MtwG5IQJnTHPh9mk7wvU1dknrMt8B2sqdwT7t/kRmqsu3Wlz6ofsZBe/zpUmmDZbOzXhEVr9t6GPeEVVw2rfQbJl2/L79KVyHi3Pa+Bno6lwappu8+uAnogM5J/ExZ8JzjYeNAP0vg==
X-YMail-OSG: uQj2ZscVM1lS4SM5UwWsz1K0BHWrcqArm07zcXg1ZAn6uV.2lf6rx.IxOUwC33U 6dq02ARqb8vUrcxWZoI11mX9ywu0GQxfr17fmcQDsy7H3wTmToff4z_JP5XcT9gA1z1LL2UrToJF 1mhuSfr2hVWZ23UDChPncE08uCFaGthHnPFdUBXBXub9frgOPGf0wR3xVMP8YHEqUlb8K.xLvOkV JYWezob2lKODJ8lzpAYg1rtUugF1WUrsEhJXqry9_WJtL8RKk5luJ2KMILmLtzzf3kUyuZFzko5Z qFLKeRgLACdDYeTncd9eR8YdGYhdwWE8HJpDeirWrDpr41xi19nGmBGxUDwAfAZckUMfhvez5xFd WvP8boaA0EIh6._2Hj8mIixu.KL7UTACN7Z99.Tq_GUg3Rr6lxE1RMHp7NNYEN5DtrHl_YKvq9Bb QBlTNb_x.v20nSvYAhpDlQRJe2zOcq5KiBliniTA3.PmKQ9omgJcZo_kEfo2hNQXH43NauoLX2kU fw2uOzS_aChfj1n7sVv2QKr0btoWlO1mZJepjzGn9QwxTN.upOEB94xbvgDszcByPHNpSI.t.HoU OzmTcayIA_7TULxWFafIVBnEPntWprvHLMLN2e5dzEzp9iAzY6Xz1CPN3dhOWeEF3fgmFO8h1QiN 6XMS6S03U2azdfkmlwgvkLEykYL45hy7TwPHNALZ17Ls_RfhI2UXJeKtBE3EVb0nCeRGmCO44tTE Ylkcnw_50elCFwBTWJpv.aSt.TuoDVGrwdI1WGnPddOTPMRoICbHul50XI2opDitXj87cubUCLjk oR8A2IAUqSo7VdwwhXk9FnLewXXJTSgq8hhEm0xXKebyIsGN7uxeYizPNqaUTl.AGR8pQt4_YHFN HidSBtyaFHijH7f2OuNZhfyHJIMqtmFSFHJ6VC7LBtFSNfw2W64Ct9qGDhQLBFkEErKiCNX.mtci pOoa7HMub.YlA1FdPRuj0PTzhZ2XkReZI5Gk5K1f6YFjBFvlbn2UtkR3uwi9DJUC1x6gjY1WgCLG jChRjH_PuxUA2uBCPOawdLbzOaj3svoYFbKmgNZmDLapFEDGcaYKLbrUyw5EaLmjNGyALiHp2lqt h3fJ2MncrxJqCzJ7Ri4z7_rvgdxXrqB3hvCbABw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Tue, 23 Apr 2019 11:32:24 +0000
Received: from nat-vpn-users2.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.130.101]) ([184.165.8.97]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6ca11eb9e404b53fccbf11c0966c32eb; Tue, 23 Apr 2019 11:32:23 +0000 (UTC)
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Pedro Igor Silva <psilva@redhat.com>, oauth <oauth@ietf.org>
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> <F7C4C5AC-F83E-476D-B280-D4E97DE57772@lodderstedt.net>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <f247e9de-e39f-56d8-7c60-2f6f30f3ed80@aol.com>
Date: Tue, 23 Apr 2019 07:32:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <F7C4C5AC-F83E-476D-B280-D4E97DE57772@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------73129D378A24826BDE652009"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Cdd_pd140yex8N4-tFbr2WujpUA>
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 11:32:27 -0000

Yes, from 3.3.1 of the UMA OAuth2 grant...

scope
    OPTIONAL. A string of space-separated values representing requested
    scopes. For the authorization server to consider any requested scope
    in its assessment, the client MUST have pre-registered the same
    scope with the authorization server. The client should consult the
    resource server's API documentation for details about which scopes
    it can expect the resource server's initial returned permission
    ticket to represent as part of the authorization assessment (see
    Section 3.3.4
    <https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#authorization-assessment>).

https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#seek-authorization

On 4/23/19 1:04 AM, Torsten Lodderstedt wrote:
> Does UMA use the standard scope parameter?
>
> Am 22.04.2019 um 21:03 schrieb George Fletcher <gffletch@aol.com 
> <mailto: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.
>>