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

Breno de Medeiros breno at google.com
Wed Dec 5 17:47:39 UTC 2012


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



-- 
--Breno


More information about the Openid-specs-ab mailing list