Re: [OAUTH-WG] Transaction Authorization with OAuth

George Fletcher <gffletch@aol.com> Fri, 26 April 2019 14:17 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 67FA1120453 for <oauth@ietfa.amsl.com>; Fri, 26 Apr 2019 07:17:37 -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 wzxrMzccOG-x for <oauth@ietfa.amsl.com>; Fri, 26 Apr 2019 07:17:34 -0700 (PDT)
Received: from sonic305-2.consmr.mail.bf2.yahoo.com (sonic305-2.consmr.mail.bf2.yahoo.com [74.6.133.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 DD1AF120447 for <oauth@ietf.org>; Fri, 26 Apr 2019 07:17:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556288252; bh=De1zCG/2WbYCTqKRd5ahfKbQeuoZyg848jby/xQs5pw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=I1pjUwHR2MrqNLsMMqGtS2N9oAW1hEf8ibhKo6Df6GL+njtNVGvm5XXkWBrAux/R/FY26iup5pNsr56H5rdZd/R3LfmpKsYIVcuLqMNzU+ZFm21eir4L78t0ldiqWlC6LEicoMpGb/Okkq5RJg/5BT0Vm+grG53pgF8AfzdgoL2MtzpsGfhl2+9xJZy5S+UtvmpwPagdDIEFDwc+WQYVQmZUJJC/Fx0mXadUU3LVNkrM4C1LgTXwOdt9d6ONUBKTZg/XUiA71lBkej4YkrXBBXl6spX/62msejZ6Uk5T0mrnO2KZYpO2GznXd+fJ+2R8W/PzOiN0Bo3dfboGvHv80w==
X-YMail-OSG: hwrfwjEVM1kwNMdYZjjlUJ_CxscxuoKPyPRV9_8cn5yP1ax5YkjUr5dSLpGCv2V pOBNJeNYf6h6iVzowtJSIEPmzXzOI.9cjBykOCskUjPihI5KIIuKYesdDOBjgZ70qU5ghqyQ1sqS 6re4EXwOrqqiCm4bSUlGkFM10bVpDmoSvzzLhAAUzKUzObREA3CtYMMeegGpxN4snrbcd1HeKvY4 JNqCyv8hPoAtdFGfx.Aqr7JI4WNOYFQDqhmZYL0AO2kUDSKXR4RCuRRnc6bN.LlXam3NECzbCv82 Ip4vGubZZ9c1_8pgGfjpK3KoGXFnppfWuZ0iDL18k7RqiVXYQvDGniXU42z2PqswfDbH62O85UFH 6.lfl8EHT6XXpJbHTSupjZTLrxIEzJBRzxRtUt9abHPlXdoEOdySSiBZuNTaN2tnPCcGziDJJ_M4 dhDPDRXJbtpNygT2a_oiLCBB9KJpNeB82o55GOExJ_yb4d.NSTS_xoQg.ppaOAd.juzF2u65uxa_ dsgmYmnpnGULWHP9cE.EEhNG1DRKjAqbfrf9wYpggBTINssb3Fu6rRY3.cft.Z3hCt39zkaYeU5k NMnKTvd4L0HvDvB62G5rBjO8Se.KTkQjmsVFIEzMtKhqykHnraG8fAowrqQqs.ecZxIbtxg0RERL D8HmpLlm6h8WPKznqWbTJqAXloQDaUs0EukpsuOZdoRoJq.Ko6CIZOcsa0NmS7WnkQP8ccLEs3Fq C3UR.pjAhtvZNqtJqA4PUKIFKpWxo_wJKnurYzvOthrCDrLO8EAiBGPIvaBlBvMSCLkBFYtI7CAK CnllADONYSBuQYBUsQWYIC1kqg6iS32wCNG86hiY8d7ggTADvnXDoV6tGc70QjUmnqDu7nPKfgZk XWMUusKxhnrh9.rd1CV1DjFuNjWQCwDNWwLEWxv2TPyYIgR9trprlCPlAWICLX0wIfsxWBqDJhj8 ZmxD6ZNQxjkro0zFOc00AiYW_qBp9f1xFD7ex3sM_r9K86Z9zqNccsr3de6H8xOQf31dxOAGGU3D dFBRqevNc3bToPT3VZoyMKHy1racuYILvSLkVrgIYmY_0i7ubW1XUYHvbSc4xuZ0q0r87wpLnJsi 1NGx1NfKyBg--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Apr 2019 14:17:32 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 01f5d52cb073ab53fb0403f6a1bb1ab8; Fri, 26 Apr 2019 14:17:27 +0000 (UTC)
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Sascha Preibisch <saschapreibisch@gmail.com>, oauth <oauth@ietf.org>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <CAP=vD9u8ki=WzHr-VrLZcdU4nszNja5pgkB+4n2N+-xqCrpm=Q@mail.gmail.com> <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net> <CAP=vD9sL-ESxo5obtnYCFrT4EEjeQt-0GDsqmxWFDy3+HxDN4A@mail.gmail.com> <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com> <B5BEEA54-B2B1-468A-AAE7-2B23A400919A@lodderstedt.net>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com>
Date: Fri, 26 Apr 2019 10:17:26 -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: <B5BEEA54-B2B1-468A-AAE7-2B23A400919A@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------F18232DABEF90B539B745C18"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-rMc4dvQg_0JjN8sYpRsowvs-Ao>
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: Fri, 26 Apr 2019 14:17:48 -0000


On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>
>
> Am 25.04.2019 um 17:03 schrieb George Fletcher <gffletch@aol.com 
> <mailto:gffletch@aol.com>>:
>
>> A couple of thoughts...
>>
>> 1. It doesn't feel like these are scopes (at least not as scope is 
>> defined by RFC 6749). It feels like they are more transaction 
>> requirements.
>
> What???s the difference? In my opinion, if you authorize a transaction 
> it???s the same. Moreover, in other use cases (account information) it a 
> complex requirement for a potentially long lasting grant.
>
> In both cases, they describe the request power of the token == it???s scope.
I guess I look at scope as "authorized to transfer" maybe something like 
"authorized to transfer up to 10K". However the details of which account 
to take the money from and the account of where to put the money are not 
aspects of the scope but rather restrictions on the transaction.

It may be fine to have a model where the client tells the AS what 
transaction it wants to perform for the purpose of getting consent from 
the user to perform that transaction... but I don't think the details of 
the transaction should be considered scope(s).

For me.. scope is a capability the client is authorized to perform... 
"send an Instant message", or "read a buddy list".
>
>>
>> 2. The schemas are going to be very ecosystem specific, correct?
>
> API (e.g. all psd2 standards), ecosystem, single deployment - just 
> like ???traditional??? scope values
Again, I would want the transaction requirements to be part of the API 
not part of the scope. In my mind, the authorization token should convey 
the client is authorized to perform a set of actions (capabilities) and 
then the API parameters define the exact details of that particular 
transaction.
>
>>
>> On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
>>> Hi Sascha,
>>>
>>> I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition.
>>>
>>> In my last example, the scope is defined as
>>>
>>>     "structured_scope":{
>>>        "sign":{
>>>           "credentialID":"qes_eidas",
>>>           "documentDigests":[
>>>              {
>>>                 "hash":
>>>                   "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
>>>                 "label":"Mobile Subscription Contract"
>>>              }
>>>           ],
>>>           "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>>>        },
>>>        "payment":{
>>>           "type":"sepa-credit-transfer",
>>>           "instructedAmount":{
>>>              "currency":"EUR",
>>>              "amount":"123.50"
>>>           },
>>>           "debtorAccount":{
>>>              "iban":"DE40100100103307118608"
>>>           },
>>>           "creditorName":"Merchant123",
>>>           "creditorAccount":{
>>>              "iban":"DE02100100109307118603"
>>>           },
>>>           "remittanceInformationUnstructured":"new Smartphone"
>>>        }
>>>
>>> This means ???sign" and ???payment" would determine the scheme of the respective object.
>>>
>>> What do you think?
>>>
>>> best regards,
>>> Torsten.
>>>
>>>> On 23. Apr 2019, at 17:14, Sascha Preibisch<saschapreibisch@gmail.com>  wrote:
>>>>
>>>> Hi Torsten!
>>>>
>>>> If 'structured_scope' would become a generic field for application
>>>> specific content, I believe an indicator for the type of content would
>>>> be needed on the long run. That is what I meant my 'profile'. I hope
>>>> this helps!
>>>>
>>>> Thank you,
>>>> Sascha
>>>>
>>>> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
>>>> <torsten@lodderstedt.net>:
>>>>> Hi Sascha,
>>>>>
>>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch<saschapreibisch@gmail.com>:
>>>>>>
>>>>>> Thank you for the article, Torsten!
>>>>> my pleasure :-)
>>>>>
>>>>>> I like that 'scope' is out of the game for these kinds of authorizations.
>>>>>>
>>>>>> What I can see for the general use case is a required identifier
>>>>>> within the 'structures_scope' document that identifies the profile it
>>>>>> should be used for.
>>>>> What does profile mean in this context?
>>>>>
>>>>> best regards,
>>>>> Torsten.
>>>>>> Thank you,
>>>>>> Sascha
>>>>>>
>>>>>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>>>>> <torsten@lodderstedt.net>:
>>>>>>> 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
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>