Dear Aaron and Warren, 1. Thx a lot for such a quick response. It completely makes sense. The initial idea was to be a little more elaborate or explicit in mentioning the preference of choosing one option over the other in the specs itself.
2. Aaron yesterday discussed the idea of having an error code when the "redirect_uri" parameter does not match at token endpoint and authorization endpoint. We could consider making the wording a little elaborate like: "redirect_uri": REQUIRED, if the redirect_uri parameter was included in the authorization request as described in Section 4.1.1, *when multiple URIs are registered with the authorization server, *in which case their values MUST be identical. *The error codes in case of mismatch of the URIs are not defined*. If no redirect_uri was included in the authorization request, this parameter is OPTIONAL. Regards and Best Wishes Jaimandeep Singh On Wed, Jul 27, 2022 at 7:56 PM Aaron Parecki <aaron= [email protected]> wrote: > The discussion yesterday was about the redirect_uri parameter at the token > endpoint, not at the authorization endpoint. > > The redirect_uri parameter at the authorization endpoint is currently: > > * optional if the client has only one redirect URI registered > * required if the client has multiple redirect URIs registered > > The redirect_uri parameter at the token endpoint is currently: > > * required if the authorization request included the redirect_uri > parameter, and optional otherwise > > The discussion yesterday led to the conclusion that making any changes to > the parameter at the token endpoint in either direction (either always > required or omitting it entirely) would lead to worse interoperability. > > Aaron > > > > On Wed, Jul 27, 2022 at 9:38 AM Warren Parad <wparad= > [email protected]> wrote: > >> Can you explain why you think: >>> >>> But definitely cannot be both (as in the present definition). >> >> >> From a theoretical perspective, of course it can be. But perhaps there is >> a concrete reason you think otherwise, I think it would be prudent to share >> that context explicitly with an explanation here. That way we aren't >> opening old conversations in the middle of the meeting, and also it lets us >> be prepared to understand the perspective without having to dive in on the >> spot. >> >> On Wed, Jul 27, 2022 at 2:42 PM Jaimandeep Singh <jaimandeep.phdcs21= >> [email protected]> wrote: >> >>> Dear Aaron, >>> >>> 1. Yesterday you brought up an important issue of choosing >>> "redirect_uri" to be REQUIRED vs OPTIONAL parameter at the authorization >>> code endpoint. The esteemed members had their considered opinion that the >>> definition should remain as it is. >>> >>> 2. However, I am of the opinion that an important parameter like >>> "redirect_uri" needs to be more clearly defined. It can either be OPTIONAL >>> or REQUIRED, but definitely cannot be both (as in the present >>> definition). Maybe Aaron can bring up the topic again for discussion in the >>> side meeting for further deliberations. >>> >>> Regards >>> Jaimandeep Singh >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
