The argument that variability harms interoperability is a fair one (though not always so straightforward) but would have been better made around this parameter during the development of OAuth because the variability is already written into RFC 6749. I think it'd be hard to argue that the Connect spec suite has any precedent of eschewing variability in favor of interoperability or simplicity so deferring to that here seems a bit arbitrary. <br>
<br>Putting this requirement into Connect introduces a different kind of variation all together. Whether or not the parameter is required (under the particular circumstance of a single registered redirect uri) would depend on if you are doing plain old OAuth or if you are doing Connect. That seems even worse IMHO and will certainly be a pain to support.<br>
<br>I raised the issue originally because the difference between the two related specs caused some actual confusion amongst some folks I was working with (including people who are involved in working on/with both of these specs). It seemed really awkward, to me anyway, to have Connect treat a parameter that's defined in OAuth differently than OAuth treats it. I'd prefer to see consistent treatment between the two specs but it's not worth fighting about so I'll drop it, if others really want it this way. At the very least, however, the various Connect specs need to be consistent with themselves. <br>
<br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 4, 2012 at 11:37 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">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 style="font-size:1em;margin-top:0px;margin-bottom:0px">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><div class="h5"><div>On 2012-12-04, at 2:52 PM, Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>> wrote:</div>
<br></div></div><blockquote type="cite"><div><div class="h5">-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" target="_blank">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" target="_blank">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" target="_blank">openid-specs-ab@lists.openid.net</a>>" <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">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" target="_blank">https://bitbucket.org/openid/connect/issue/669/inconsistent-treatment-of-redirect_uri</a><br>
<br>[2]<br><a href="http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20121203/002612.html" target="_blank">http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20121203/002612.html</a><br><br></blockquote>
<br><br><br>-- <br>--Breno<br></div></div>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></blockquote></div><br></div></div></blockquote></div><br></div>