John, Nat, Tangui raises a good point I have missed,
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 not?* The OIDC language also includes sections which make sure that some required arguments are still passed outside of the request with the same value to make sure the request is "valid" OAuth 2.0 request, 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. 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 since its even called out to be already in place in OIDC. S pozdravem, *Filip Skokan* On Thu, 25 Jul 2019 at 20:48, Танги Ле Пенс <tangui.lepe...@mail.ru> wrote: > Filip, thank you for your reply. Additional remarks inline. > > On 25.07.2019 21:14, Filip Skokan wrote: > > See my reply inline. > > > > S pozdravem, > > *Filip Skokan* > > > > > > On Thu, 25 Jul 2019 at 19:57, Танги Ле Пенс > > <tangui.lepense=40mail...@dmarc.ietf.org > > <mailto:40mail...@dmarc.ietf..org>> wrote: > > > > In > > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it > > is stated that an error is to be returned when the object request is > > invalid. These errors are "invalid_request_uri" and > > "invalid_request_object". > > > > However, to which redirect URI redirect in the following cases: > > * the request object is invalid (eg. invalid signature), should we > > still > > use client_id/redirect_uri of the invalid request object? > > > > * the request URI could not be reached > > * the request object is encrypted and cannot be decrypted (bad key) > > > > > > FS: if the client_id & redirect_uri combination is valid (the uri is > > valid for that client) - yes, its fine to use those (dtto state). this > > applies to all three > > It doesn't apply to an encrypted object that cannot be decrypted. > > > > > Would it be acceptable to use the "client_id" and "redirect_uri" > > request > > query parameters in such a case? Although it contradicts the current > > specification which states that they shall not be used, and it would > > defeat confidentiality when using encryption. > > > > > > FS: how would it defeat confidentiality? > If you use a JWE in the first place, it's so that the parameters cannot > be read on the wire. > > > > > > Another option is not redirecting and displaying the error message on > > the AS, like when the client_id is unknown for instance. > > > > > > FS: also an acceptable outcome, one with no caveats > > Except degraded UI for the end user, if we assume that an error on the > client side is easier to manage that a cryptic error on the AS with no > link back to the client. Also, the client could have a retry strategy > (it might just be that the request object at the request object URI is > expired, due to network latency, etc.). > > So if my understanding is correct, it's up to the implementer to make a > decision on this point? Couldn't it lead to incompatibility, divergent > implementations? > > > > > Also I don't get the example in > > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.2 > > < > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5..2.2> > > : > > > > https://server.example.com/authorize? > > response_type=code%20id_token > > &client_id=s6BhdRkqt3 > > &request_uri=https%3A%2F%2Ftfp.example.org > > <http://2Ftfp.example.org>%2Frequest.jwt > > %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM > > &state=af0ifjsldkj > > > > in regards to the following statement in > > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5 : > > > > 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. > > > > My understanding is that "response_type", "client_id" and "state" > > will > > be ignored by a JAR-compliant OAuth2 server. Isn't it confusing to > > add > > them to the example? > > > > > > FS: they will only be ignored IF they are also part of the request > > object so i believe its fine to have them part of this example. > > It's seems ambiguous to me when reading the specification. > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-4 states > that: > > A Request Object (Section 2.1 < > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.1>) is > used to provide authorization > request parameters for an OAuth 2.0 authorization request. It MUST > contains all the OAuth 2.0 [RFC6749 < > https://tools.ietf.org/html/rfc6749>] authorization request parameters > including extension parameters. > > So there'd be no such thing as "client_id" and "redirect_uri" as query > parameters, and other parameters members of the request object in my > interpretation. > > In OpenID Connect you can indeed have both, the request object's > parameters having precedence over query parameters > (https://openid.net/specs/openid-connect-core-1_0.html#RequestObject): > > When the request parameter is used, the OpenID Connect request parameter > values contained in the JWT supersede those passed using the OAuth 2.0 > request syntax. However, parameters MAY also be passed using the OAuth > 2.0 request syntax even when a Request Object is used; this would > typically be done to enable a cached, pre-signed (and possibly > pre-encrypted) Request Object value to be used containing the fixed > request parameters, while parameters that can vary with each request, > such as state and nonce, are passed as OAuth 2.0 parameters. > > What do you think? > > > > > Maybe I've missed something? > > > > Regards, > > > > -- > > Tangui > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
