Sascha, I see the challenge, thanks!
Potentially, one would need to have a more explicit typing support (schemes?)
and use the name of the individual elements just as names, e.g. payment1,
payment2.
best regards,
Torsten.
> Am 25.04.2019 um 23:35 schrieb Sascha Preibisch <saschapreibi...@gmail.com>:
>
> Torsten,
>
> I think that works in most cases if you look at it that way.
>
> It is just that elements such as 'iban' are practically unknown here
> in Canada for example. This means, there needs to be a differentiator
> that tells a client that one payment may be of type 'payment_eu' and
> in the other case 'payment_ca'. Actually .... now I see the 'type'
> element. With that, 'payment + type' would provide that information.
>
> The only thing I would look into would be a change in the document
> hierarchy to simply parsing of it. Potentially multiple payments could
> be submitted at once also by adding a 'payments' root element:
>
> {
> "payment": {
> "sepa-credit-transfer": {
> "instructedAmount": {
> "currency": "EUR",
> "amount": "123.50"
> },
> "debtorAccount": {
> "iban": "DE40100100103307118608"
> },
> "creditorName": "Merchant123",
> "creditorAccount": {
> "iban": "DE02100100109307118603"
> },
> "remittanceInformationUnstructured": "new Smartphone"
> }
> }
> }
>
> But generally, the 'structured_scope' is a good concept I think.
>
> Thanks again, Torsten,
>
> Sascha
>
> Am Mi., 24. Apr. 2019 um 10:08 Uhr schrieb Torsten Lodderstedt
> <tors...@lodderstedt.net>:
>>
>> 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
>>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
