It would be fine not allowing that across the board but rather through a language like so
‘Authorization Servers MAY allow per-transaction parameters such as “state” and “nonce” to be sent outside of the Request Object using regular OAuth 2.0 parameter syntax, the specific parameters are at the implementer’s discretion’ Odesláno z iPhonu 28. 8. 2019 v 23:23, Filip Skokan <panva...@gmail.com>: > 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 this >>>> specification MUST only use the parameters included in the request >>>> object. >>> >>>> 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 this >>>> specification MUST only use the parameters included in the request >>>> object. >>> >>> 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
