<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I think we are agreed that the authorization server needs to be able to accept redirect URI.<div><br></div><div>The question is if a client has one and only one redirect URI registered should not sending the redirect URI cause:</div><div>1: an error </div><div>2: a redirect to the registered URI.</div><div><br></div><div>RFC 6749 states in Sec 3.1.2.3 </div><div><br></div><div><pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always; ">If multiple redirection URIs have been registered, if only part of
the redirection URI has been registered, or if no redirection URI has
been registered, the client MUST include a redirection URI with the
authorization request using the "redirect_uri" request parameter.</pre><div><br></div></div><div>As redirect_uri is an optional parameter the spec allows not sending it in the case where one redirect URI is registered. </div><div><br></div><div>I think the argument Breno is making is that the spec allows the Authorization server to always require a redirect_uri so it is best to train people to always send it all the time.</div><div><br></div><div>The only downside to that is in bandwidth constrained environments it adds extra characters to the request, that don't serve any real security purpose.</div><div><br></div><div>In the interests of maximum interoperability the connect spec takes the position that redirect_uri is always sent, to avoid breaking at some IdP that require it for there OAuth implementations.</div><div><br></div><div>The other place this effects is the request to the token endpoint. in sec 4.1.3 the redirect_uri parameter is sent in the original request to the authorization server it must also be sent to the token endpoint.</div><div><br></div><div>So if space bandwidth is a issue we are sending it twice. (I do actually have a large deployer who is concerned about this) </div><div><br></div><div>Currently Connect requires the redirect_uri to always be sent be sent in the request to the token endpoint as the request_uri is always sent to the authorization endpoint.</div><div><br></div><div>The RFC allows this one condition of a single registered redirect_uri to be used to reduce request size. The question is if consistency is more important than size to us?</div><div><br></div><div>That is my analyses of the current situation.</div><div><br></div><div>John B.</div><div><br></div><div><br></div><div><div><div>On 2012-12-04, at 2:52 PM, Breno de Medeiros <<a href="mailto:breno@google.com">breno@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">-1<br><br>In my experience, every variation is harmful for interop, and is<br>expensive for developers to learn about.<br><br>All OAuth2-compliant providers need to accept a redirect_uri is specified.<br><br>On Tue, Dec 4, 2012 at 9:30 AM, Brian Campbell<br><<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>> wrote:<br><blockquote type="cite">Sorry for the re-post - I wanted to send this with Breno and Naveen directly<br>in the distribution list to increase the likelihood that they'd actually see<br>it (but forgot the first time).<br><br><br>---------- Forwarded message ----------<br>From: Brian Campbell <<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>><br>Date: Tue, Dec 4, 2012 at 10:17 AM<br>Subject: Question to Google about redirect_uri parameter in authorization<br>request<br>To: "<<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>>" <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>><br><br><br>Hey Breno and/or Naveen,<br><br>Would you guys be OK with relaxing the Connect specs to allow the<br>redirect_uri parameter to be omitted from an authorization request when only<br>one redirect_uri is registered for the given client?<br><br>The reason I'm asking it that the Connect specs are more strict about the<br>redirect_uri parameter than the base OAuth spec and I'd submitted at ticket<br>[1] requesting that Connect align with the RFC that it extends from. The<br>Connect editors have said the added constraint on the parameter was placed<br>there because it's how the the Google implementation worked and asked me to<br>follow up with you guys [2] to understand why you were requiring it and if<br>it is OK to relax that requirement in the Connect specs.<br><br>Can you shed some light on that decision and/or just give the to make the<br>change at the spec level?<br><br>Thanks in advance,<br>Brian<br><br><br>[1]<br><a href="https://bitbucket.org/openid/connect/issue/669/inconsistent-treatment-of-redirect_uri">https://bitbucket.org/openid/connect/issue/669/inconsistent-treatment-of-redirect_uri</a><br><br>[2]<br>http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20121203/002612.html<br><br></blockquote><br><br><br>-- <br>--Breno<br>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>