Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 2 May 2019 20:12:58 -0500

On Tue, Apr 30, 2019 at 12:08:32PM +0200, Torsten Lodderstedt wrote:
> 
> 
> > Am 28.04.2019 um 06:08 schrieb Benjamin Kaduk <[email-masked]>:
> > 
> >> On Wed, Apr 24, 2019 at 07:08:25PM +0200, 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?
> > 
> > I think it reminds me of why draft-ietf-oauth-jwt-bcp recommends using the
> > "typ" header, and all the reasoning we have to do about different types of
> > tokens (not) being replayable at a different endpoint and being interpreted
> > wrongly.
> 
> While I agree with the need to use the typ header, I don’t see a direct relationship to my proposal as it is about specifying the intended scope of tokens but not the token format itself. Can you explain your thoughts in more detail?

I'll try; my thoughts do not seem entirely well formed, though, so perhaps
it will not work very well.

It seems like we're opening up for the structured_scope to be an arbitrary
JSON object.  But the recipient needs to know what context to interpret
that object in -- e.g., this "payment" subobject has a clear intent to
transfer money in the indicated currency from the one account to the other.
But someone else might put a different subobject under "payment", perhaps
one where users "pay" each other in virtual kittens for good behavior,
which is a different context but the same JSON element.

Receivers will of course have some expectation of what they should be
getting, and can in effect enforce that what they receive matches a schema,
but those are implicit ways of indicating what context an object is to be
interpreted in, and we may want to consider explicitly stating an indicator
of the context in which an object is intended to be considered.  Maybe
there's already something in the containing message that will fill that
role (see also: "not entirely well formed"), in which case this concern
evaporates.

Thanks,

Ben

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 3 May 2019 08:22:47 +0200

Hi Ben,

understood! It seems some scheme identifier would be helpful.

thanks,
Torsten.

> Am 03.05.2019 um 03:12 schrieb Benjamin Kaduk <[email-masked]>:
>

---

From: Takahiko Kawasaki <[email-masked]>
Date: Sat, 4 May 2019 03:47:25 +0900

Dear Torsten,

To the point. (^_^; It is "request object". Sorry.

Best,
Taka

2019年4月30日(火) 19:24 Torsten Lodderstedt <[email-masked]>:

> Dear Taka,
>
> thanks for your feedback.
>
> How would this more generic mechanism differ from the JSON-based request
> object? I personally would advocate to use both, structured scope & pushed
> request object, to together.
>
> best regards,
> Torsten.
>
> Am 26.04.2019 um 09:47 schrieb Takahiko Kawasaki <[email-masked]>:
>
> Dear Torsten,
>
> I was impressed with your article. It describes considerations points very
> well that implementers of leading-edge authorization servers will
> eventually face or have already faced.
>
> It seems to me that the mechanism of "structured_scope" can be positioned
> as a more generic mechanism whose usage doesn't necessarily have to be
> limited to scopes. I mean that the mechanism can be used to include any
> arbitrary dynamic structured data in an authorization request. So, if there
> were something I might be able to propose additionally, I would suggest
> renaming "structured_scope" to a more generic name.
>
> Best Regards,
> Takahiko Kawasaki
> Representative director, Authlete, Inc.
>
> 2019年4月21日(日) 3:21 Torsten Lodderstedt <[email-masked]>:
>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 8 May 2019 10:43:43 -0400

>     George::
>
>     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.
>
>
> Torsten:: I understand your sentiments. How would you envision to ask 
> a user for consent about those details if this consent is required by law?

So it seems we are looking for two key aspects as it relates to the 
transaction(s) and consent...

1. Require explicit user consent regarding the details of the transaction
2. Specify the details of the transaction

It seems the mapping of this to the term "scope" is because at the 
authorization endpoint it's the "scopes" the user has to consent to. 
However, we don't have to try and map this transactional functionality 
into the existing more capability model of OAuth2.

Assuming that something like a "consent receipt" will be issued to the 
user once they have consented... what about using a term more consistent 
with consent? "transaction_consent" ? I'd even be fine with 
"transaction_details" and then have the spec require that the user 
consent to all information in the "transaction_details" object. Though I 
suspect there are use cases where there are more details in the 
transaction than for which the user needs to give consent. So that might 
not be the best name.

At this point I'm probably splitting hairs:) Naming things is hard:)

On 4/30/19 6:39 AM, Torsten Lodderstedt wrote:
>
>
> Am 26.04.2019 um 16:17 schrieb George Fletcher <[email-masked] 
> <mailto:[email-masked]>>:
>
>>
>>
>> On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>>>
>>>
>>> Am 25.04.2019 um 17:03 schrieb George Fletcher <[email-masked] 
>>> <mailto:[email-masked]>>:
>>>
>>>> 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,
>>>>>
>>>>> 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<[email-masked]>  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
>>>>>> <[email-masked]>:
>>>>>>> Hi Sascha,
>>>>>>>
>>>>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch<[email-masked]>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>> <[email-masked]>:
>>>>>>>>> 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
>>>>>>>>>

---

From: Dave Tonge <[email-masked]>
Date: Fri, 10 May 2019 15:52:12 +0200

Thanks Torsten for this article - it is incredibly helpful.

I'm very much in favour of the "structured_scope" approach.

While I understand George's point I think the line is very blurred between
coarse-grained scopes and fine-grained transaction consent. In addition
fine-grained authorisation metadata is needed for ongoing access APIs as
well, e.g. how can a client ask for ongoing access to:
 - transactions in a users accounts with ids abc123 and abc124

>From a UX perspective it is beneficial for the AS to ask the user for
consent once. The AS therefore needs to have all the information about
relating to the consent available when the user is redirected to the
authorization endpoint. There should be a standard way for the Client to
pass this data to the AS and I think structured scopes either sent as a
query param or in a request object are a neat way of doing this.

Dave

---

From: George Fletcher <[email-masked]>
Date: Fri, 10 May 2019 16:27:06 -0400

One thing to keep in mind with the "Push Request Object" model and the 
concept of a more detailed scope structure, if the specified values are 
not for a single transaction, then the AS will be required to keep the 
"Pushed Request Object" for the "lifetime" of the access_token and 
possibly the refresh_token depending on the use case. This could have 
some implementation issues for the AS.

Thanks,
George

On 5/10/19 9:52 AM, Dave Tonge wrote:
> While I understand George's point I think the line is very blurred 
> between coarse-grained scopes and fine-grained transaction consent. In 
> addition fine-grained authorisation metadata is needed for ongoing 
> access APIs as well, e.g. how can a client ask for ongoing access to:
> authorization endpoint. There should be a standard way for the Client 
> to pass this data to the AS and I think structured scopes either sent 
> as a query param or in a request object are a neat way of doing this.
>
> Dave
>

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 13 May 2019 14:20:15 +0200

Indeed but at the same time, it may be needed for the AS to keep it
anyways for compliance purposes.

I have not gone through the thread yet, but here is my brief response
to Torsten's post.

https://nat.sakimura.org/2019/05/12/comments-back-to-transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-by-torsten/

Cheers,

Nat Sakimura

On Fri, May 10, 2019 at 10:27 PM George Fletcher
<gffletch=[email-masked]> wrote:
>
> One thing to keep in mind with the "Push Request Object" model and the concept of a more detailed scope structure, if the specified values are not for a single transaction, then the AS will be required to keep the "Pushed Request Object" for the "lifetime" of the access_token and possibly the refresh_token depending on the use case. This could have some implementation issues for the AS.
>
> Thanks,
> George
>
> While I understand George's point I think the line is very blurred between coarse-grained scopes and fine-grained transaction consent. In addition fine-grained authorisation metadata is needed for ongoing access APIs as well, e.g. how can a client ask for ongoing access to:
> From a UX perspective it is beneficial for the AS to ask the user for consent once. The AS therefore needs to have all the information about relating to the consent available when the user is redirected to the authorization endpoint. There should be a standard way for the Client to pass this data to the AS and I think structured scopes either sent as a query param or in a request object are a neat way of doing this.
>
> Dave
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 May 2019 19:10:16 +0200

> Am 10.05.2019 um 22:27 schrieb George Fletcher <[email-masked]>:
> 

It’s not necessarily the request object but the client id and the scope. Can you please explain what implementation issue you expect? I don’t see much of a difference between storing/maintaining simple scope values and a JSON document for a grant.