Re: [OAUTH-WG] Transaction Authorization with OAuth

Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 30 April 2019 10:39 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 230F51202A1 for <oauth@ietfa.amsl.com>; Tue, 30 Apr 2019 03:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 AsKwEAvARDOT for <oauth@ietfa.amsl.com>; Tue, 30 Apr 2019 03:39:55 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) (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 A4A12120130 for <oauth@ietf.org>; Tue, 30 Apr 2019 03:39:54 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.105]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1hLQAx-0007KB-QB; Tue, 30 Apr 2019 12:39:51 +0200
Content-Type: multipart/signed; boundary="Apple-Mail-B61BB958-A3E7-48F7-8DE9-40580FDA51B3"; 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: <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com>
Date: Tue, 30 Apr 2019 12:39:48 +0200
Cc: Sascha Preibisch <saschapreibisch@gmail.com>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <2EDD8634-20D1-40DE-AA0D-A64AB6AEA539@lodderstedt.net>
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> <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com>
To: George Fletcher <gffletch@aol.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/qnFYLLnYtANN8wHoPcP7JkeSzg8>
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, 30 Apr 2019 10:39:57 -0000


> Am 26.04.2019 um 16:17 schrieb George Fletcher <gffletch@aol.com>:
> 
> 
> 
>> On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>> 
>> 
>> Am 25.04.2019 um 17:03 schrieb George Fletcher <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.

I understand your sentiments. How would you envision to ask a user for consent about those details if this consent is required by law?

>> 
>>> 
>>>> 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
>>> 
>