Re: [OAUTH-WG] Transaction Authorization with OAuth

[Torsten Lodderstedt <[e-mail]>]

Hi Ben,

understood! It seems some scheme identifier would be helpful.

thanks,
Torsten.

> Am 03.05.2019 um 03:12 schrieb Benjamin Kaduk <[e-mail]>:
> 
>> On Tue, Apr 30, 2019 at 12:08:32PM +0200, Torsten Lodderstedt wrote:
>> 
>> 
>>>> Am 28.04.2019 um 06:08 schrieb Benjamin Kaduk <[e-mail]>:
>>>> 
>>>> On Wed, Apr 24, 2019 at 07:08:25PM +0200, 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?
>>> 
>>> I think it reminds me of why draft-ietf-oauth-jwt-bcp recommends using the
>>> "typ" header, and all the reasoning we have to do about different types of
>>> tokens (not) being replayable at a different endpoint and being interpreted
>>> wrongly.
>> 
>> While I agree with the need to use the typ header, I don’t see a direct relationship to my proposal as it is about specifying the intended scope of tokens but not the token format itself. Can you explain your thoughts in more detail?
> 
> I'll try; my thoughts do not seem entirely well formed, though, so perhaps
> it will not work very well.
> 
> It seems like we're opening up for the structured_scope to be an arbitrary
> JSON object.  But the recipient needs to know what context to interpret
> that object in -- e.g., this "payment" subobject has a clear intent to
> transfer money in the indicated currency from the one account to the other.
> But someone else might put a different subobject under "payment", perhaps
> one where users "pay" each other in virtual kittens for good behavior,
> which is a different context but the same JSON element.
> 
> Receivers will of course have some expectation of what they should be
> getting, and can in effect enforce that what they receive matches a schema,
> but those are implicit ways of indicating what context an object is to be
> interpreted in, and we may want to consider explicitly stating an indicator
> of the context in which an object is intended to be considered.  Maybe
> there's already something in the containing message that will fill that
> role (see also: "not entirely well formed"), in which case this concern
> evaporates.
> 
> Thanks,
> 
> Ben