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