[Openid-specs-ab] Question to Google about redirect_uri parameter in authorization request

Brian Campbell bcampbell at pingidentity.com
Wed Dec 5 17:40:43 UTC 2012

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. 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.

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>
> wrote:
>> > 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.
> -T
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab

More information about the Openid-specs-ab mailing list