Section 5: Add warning on sending params unprotected (Hannes)

[19:23:44] Hannes Tschofenig: I am wondering whether this sentence will destroy most of the benefits you describe in the document:

"However, parameters MAY also be passed using the OAuth 2.0 request syntax even when a Request Object is used" [19:23:53] Hannes Tschofenig: If you do that you obviously void any confidentiality protection [19:24:25] Hannes Tschofenig: If implementations do not check (which they will likely not do) then integrity protection will also be void [19:30:00] Nat Sakimura: Right. For anything that is sent over just as unprotected parameter will obviously be not protected. Not only from the confidnetiality point of view, but more importantly, from the integrity point of view. [19:30:55] Nat Sakimura: However, the document also mandates that if a same parameter is sent both in the parameter and the request object, the supporting server MUST use the one in the request object. [19:33:40] Hannes Tschofenig: Ok. [19:33:51] Hannes Tschofenig: I might be worthwhile to repeat this in the security consideration section [19:34:29] Hannes Tschofenig: I would prefer to use either the JSON- encoding or the original encoding -- not both. There is, however, the problem with clients interacting with resource servers they haven't yet been talking to. [19:35:13] Hannes Tschofenig: Just mailed you a few editorial remarks [19:35:55] Hannes Tschofenig: If you note in the security consideration section (which is very short anyway) that when parameters are sent in both encodings then the JWT-version must be used [19:36:08] Hannes Tschofenig: Maybe just copying the text that is already in the doc would help [19:36:34] Hannes Tschofenig: And noting that confidentiality protection is lost in such a case

Comments (1)