> Am 26.04.2019 um 16:17 schrieb George Fletcher <[email protected]>: > > > >> On 4/25/19 1:54 PM, Torsten Lodderstedt wrote: >> >> >> Am 25.04.2019 um 17:03 schrieb George Fletcher <[email protected]>: >> >>> 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 <[email protected]>
>>>>>> 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 protected]>:
>>>>>> Hi Sascha,
>>>>>>
>>>>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch
>>>>>>>> <[email protected]>:
>>>>>>>>
>>>>>>>> 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 protected]>:
>>>>>>>> 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 protected]
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
