> 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.
>
> 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
>
>> 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
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
