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
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
