Hi Ben, understood! It seems some scheme identifier would be helpful.
thanks,
Torsten.
> Am 03.05.2019 um 03:12 schrieb Benjamin Kaduk <ka...@mit.edu>:
>
>> On Tue, Apr 30, 2019 at 12:08:32PM +0200, Torsten Lodderstedt wrote:
>>
>>
>>>> Am 28.04.2019 um 06:08 schrieb Benjamin Kaduk <ka...@mit.edu>:
>>>>
>>>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
