Well it kind of blows, doesn't it? I wasn't able to find the "why" anywhere in the mailing list archive around the time this was changed.
My take on satisfying both worlds looks like this - allow just JAR - no other params when possible. (which btw isn't possible to do with request_uri when enforcing client based uri whitelist and the jwsreq 5.2.2 shows as much) - enforce the "dupe behaviours" defined in OIDC (if response_type or client_id is in request object it must either be missing or the same in regular request). - allows merging request object and regular parameters with request object taking precedence since it is a very useful feature when having pre-signed request object that's not one time use and clients using it wish to vary state/nonce per-request. I wish the group reconsidered making this breaking change from OIDC's take on request objects - allow combination of parameters from the request object with ones from regular parameters (if not present in request object). S pozdravem, *Filip Skokan* On Wed, 28 Aug 2019 at 23:02, Brian Campbell <bcampb...@pingidentity.com> wrote: > Filip, for better or worse, I believe your assessment of the situation is > correct. I know of one AS that didn't choose which of the two to follow but > rather implemented a bit of a hybrid where it basically ignores everything > outside of the request object per JAR but also checks for and enforces the > presence and value of the few regular parameters (client_id, response_type) > that OIDC mandates. > > On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan <panva...@gmail.com> wrote: > >> Hello everyone, >> >> in an earlier thread I've posed the following question that might have >> gotten missed, this might have consequences for the existing >> implementations of Request Objects in OIDC implementations - its making >> pure JAR requests incompatible with OIDC Core implementations. >> >> draft 14 of jwsreq (JAR) introduced this language >> >> The client MAY send the parameters included in the request object >>> duplicated in the query parameters as well for the backward >>> compatibility etc. >>> >>> *However, the authorization server supporting thisspecification MUST >>> only use the parameters included in the requestobject. * >> >> >> Server MUST only use the parameters in the Request Object even if the >>> same parameter is provided in the query parameter. The Authorization >> >> >> The client MAY send the parameters included in the request object >>> duplicated in the query parameters as well for the backward >>> compatibility etc. >>> >>> *However, the authorization server supporting thisspecification MUST >>> only use the parameters included in the requestobject. * >> >> >> Nat, John, everyone - *does this mean a JAR compliant AS ignores >> everything outside of the request object while OIDC Request Object one >> merges the two with the ones in the request object being used over ones >> that are sent in clear?* The OIDC language also includes sections which >> make sure that some required arguments are still passed outside of the >> request object with the same value to make sure the request is "valid" >> OAuth 2.0 request (client_id, response_type), something which an example in >> the JAR spec does not do. Not having this language means that existing >> authorization request pipelines can't simply be extended with e.g. a >> middleware, they need to branch their codepaths. >> >> Is an AS required to choose which of the two it follows? >> >> Thank you for clarifying this in advance. I think if either the behaviour >> is the same as in OIDC or different this should be called out in the >> language to avoid confusion, especially since this already exists in OIDC >> and likely isn't going to be read in isolation, especially because the >> Request Object is even called out to be already in place in OIDC in the JAR >> draft. >> >> Best, >> *Filip* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth