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