> On 26. Apr 2019, at 16:35, George Fletcher <gffle...@aol.com> wrote:
>
> Look at this in more detail... what about calling it "transactional_scope"
> instead of "structured_scope" as the scope is specific to an individual
> transaction and not applicable across transactions. That would then separate
> it from the more capability based 'scope' provided by OAuth2.
There are cases, where the scope/token is applicable across multiple requests
for a longer period. A request for access to account information service, for
example, would look like this:
{
"access":{
"balances":[
{
"iban":"DE40100100103307118608"
},
{
"iban":"DE02100100109307118603"
}
],
"transactions":[
{
"iban":"DE40100100103307118608"
}
]
},
"recurringIndicator":true,
"validUntil":"2017-11-01",
"frequencyPerDay":"4"
}
>
> In this context I like the pushed-request-object method as the resource
> server is going to need to pull the same transactional requirements when it
> receives the access token.
All in one place :-)
best,
Torsten.
>
> Thanks,
> George
>
> On 4/26/19 10:17 AM, George Fletcher wrote:
>>
>>
>> On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>>>
>>>
>>> Am 25.04.2019 um 17:03 schrieb George Fletcher <gffle...@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 <saschapreibi...@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
>>>>>>
>>>>>> <tors...@lodderstedt.net>
>>>>>> :
>>>>>>
>>>>>>> Hi Sascha,
>>>>>>>
>>>>>>>
>>>>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch
>>>>>>>> <saschapreibi...@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
>>>>>>>>
>>>>>>>> <tors...@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
>>>>
>>
>>
>>
>> _______________________________________________
>> 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
