[Openid-specs-ab] Question to Google about redirect_uri parameter in authorization request
Michael.Jones at microsoft.com
Thu Dec 6 00:50:17 UTC 2012
Brian, is the current inconsistency within the Connect specs that you've identified in this sentence in http://openid.net/specs/openid-connect-standard-1_0.html#anchor9: "Ensure that the redirect_uri parameter is present if the redirect_uri parameter was included in the initial Authorization Request and that their values are identical for the Scheme, Host, Path, and Query Parameter segments"? If the phrase "if the redirect_uri parameter was included in the initial Authorization Request", would the Connect specs then be self-consistent, in your view?
Or are you also concerned that this language in http://openid.net/specs/openid-connect-registration-1_0.html#anchor3 would be inconsistent: "redirect_uris - RECOMMENDED for Clients using the code flow with a query parameter encoded response. REQUIRED for Clients requesting implicit flow fragment encoded responses as defined in OAuth 2.0 [OAuth2.0]. A space-delimited list of redirect URIs. One of the URL MUST match the Scheme, Host, and Path segments of the redirect_uri in the authorization request."? Or do people also believe that registering redirect_uris should always be REQUIRED?
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Brian Campbell
Sent: Wednesday, December 05, 2012 10:27 AM
To: Breno de Medeiros
Cc: <openid-specs-ab at lists.openid.net>; Naveen Agarwal
Subject: Re: [Openid-specs-ab] Question to Google about redirect_uri parameter in authorization request
I think that at some level our views are informed by the current behavior of our respective authorization server implementations. Yours always requires redirect_uri and mine will allow it to be omitted in the case where the client has registered a single redirect_uri. Both are compliant (that probably favors your argument) and we both have reasons for the current behavior. I can't change mine now as it would impact interoperability of existing deployments.
Honestly I'm good with whatever direction the WG goes with on it. The original reason I submitted the ticket was that the Connect specs were inconsistent within themselves on the parameter treatment. In order to fix that it seemed less error prone to just remove all the related text from Connect and defer to OAuth on it. I didn't expect any controversy on it but I've been in enough WGs that I should know better :) I don't think I agree with your conclusions but I follow the line of reasoning and am fine if the WG goes with that approach.
On Wed, Dec 5, 2012 at 10:58 AM, Breno de Medeiros <breno at google.com> wrote:
> For instance, today the OAuth2 spec is mute on the case where the RP
> has registered a single redirect_uri with the provider. It does not
> prohibit the provider from throwing an error. We believe Google's
> implementation that throws an error if redirect_uri is not present is
> compliant, though it probably will not interoperate will all
> OAuth2-compliant client configurations. It's probably less
> interoperable than other implementations right there. As we don't
> expect OAuth2 to provide strong interoperability guarantees, and we do
> understand very well the great value that OAuth2 brings to our
> ecosystem, we're happy to continue the current behavior.
> If the OIDC connect is mute on the redirect_uri issue and delegate all
> redirect_uri processing compliance to OAuth2 spec, I expect that we
> will keep our current behavior and claim full interoperability on this
> particular aspect. Perhaps that suits the OIDC WG's views just fine.
> On Wed, Dec 5, 2012 at 9:47 AM, Breno de Medeiros <breno at google.com> wrote:
>> On Wed, Dec 5, 2012 at 9:40 AM, Brian Campbell
>> <bcampbell at pingidentity.com> wrote:
>>> That's a fair example but the point I've been trying to make is that
>>> that variability already exists in OAuth and, even if we all agree
>>> that it's a bad thing, it can't just be undone in Connect.
>> Why not? There's a long standing tradition where protocols that build
>> on other protocols define tighter compliance profiles. If OIDC
>> _contradicted_ OAuth2, that'd be certainly an issue, but it's not the
>> case. An OIDC-compliant OAuth2 solution would also be OAuth2
>> compliant. Or it could choose to implement two behaviors based on the
>> presence of the 'openid' scope.
>>> An AS that
>>> currently allows for that variability in OAuth (and such things do
>>> exist) will need to now have further conditions on the variability
>>> based on what protocol is being used in the request (identified by
>>> the presence of the openid scope value I guess?). From the
>>> perspective of someone who has to develop, support and maintain such
>>> an AS, that seemed like not a particularly ideal situation. So I was
>>> looking to get consistent treatment between the spec suites because
>>> it would make my life easier. I also feel that any problems with
>>> potential ambiguity around the parameter would be exacerbated rather
>>> than helped by having Connect treat it differently.
>> And so we remain in disagreement.
>>> On Wed, Dec 5, 2012 at 10:05 AM, Tim Bray <tbray at textuality.com> wrote:
>>>> On Wed, Dec 5, 2012 at 8:07 AM, Brian Campbell
>>>> <bcampbell at pingidentity.com>
>>>>> > You don't have interoperability with OAuth2.
>>>>> Please spare that hyperbole for personal blog posts attacking the
>>>>> evils of big corporate America. It's a crutch argument that's
>>>>> largely untrue and any interoperability problems that OAuth 2
>>>>> might suffer are certainly not due to the conditional optionality
>>>>> of one request parameter.
>>>> Calm down. It is absolutely the case that OAuth2, for all its
>>>> virtues, does not give you interoperability in the sense that "If I
>>>> protect my resources in an OAuth2 comformant way and you protect
>>>> yours in an OAuth2 conformant way, then conformant client software will automatically work with both."
>>>> That kind of thing is true with HTTP, and with SMTP, and with lots
>>>> of other ****P's, but not remotely OAuth 2.0. I'm not even sure
>>>> this is a problem,
>>>> OAuth2 gives you a framework that you can build real interoperable
>>>> protocols on, which I think OIDC is trying to be.
>>>> So, for OIDC, it is very valuable to remove as many as possible
>>>> variations and at-the-discretion-of-the-server clauses, if there is
>>>> to be a reasonable hope of good interoperability. Every "if"
>>>> statement you force on implementers is a barrier to that.
>>>> For example: Send a redirect_uri with your auth request, then you
>>>> don't have to worry about breaking things when someone puts another
>>>> redirect in the app registration to do some testing on their
>>>> laptop. Seems like a no-brainer to me.
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab