Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

[Eran Hammer <[e-mail]>]

A good example is the 'callback' query parameter used in JSONP.

OAuth 2.0 originally used a 'callback' parameter for its own APIs but we changed it after feedback from Facebook indicated there developers were confused by it and in some cases, that caused conflict with existing frameworks where 'callback' was always processed automatically. So while OAuth does not use JSONP, it had to renamed the parameter to 'redirect_uri' to avoid *potential* conflict.

EH

> -----Original Message-----
> From: Mark Nottingham [mailto:[e-mail]]
> Sent: Wednesday, April 18, 2012 12:00 PM
> To: Dick Hardt
> Cc: Eran Hammer; Stephen Farrell; Pete Resnick; Ned Freed; draft-ietf-oauth-
> [e-mail]; Apps Discuss
> Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-
> oauth-v2-bearer
> 
> 
> On 18/04/2012, at 10:26 AM, Dick Hardt wrote:
> 
> > Thanks Eran, I think I understand.
> >
> > To restate what you have said, specifying a query parameter as part of the
> spec is "bad" web architecture and potentially sets a precedent for other
> specifications to reserve a query parameter. Correct?
> >
> > The reality is that the world is a messy place. Developers hack the
> architecture to accomplish goals not envisioned by the architects. The
> architects can accept the reality of the world, or ignore it and lose their
> relevance. In my opinion, putting the query parameter mechanism into an
> appendix is ignoring the reality of current implementations. Adding language
> to the spec that use of the query parameter is not architecturally ideal, but
> accepts the reality of the current web would be far more preferable.
> 
> ... Except that AIUI that method has been identified as not good practice for
> entirely practical reasons, independent of the architectural reasons.
> 
> Putting that aside, there's a large difference between acknowledging and
> documenting broad practice that's bad and sanctioning its use to encourage
> further abuses.
> 
> Believe it or not, things like this *do* affect real people -- just not the
> "hackers" who are working on OAuth. It affects people who run real Web
> sites, because they have to consider what query parameters they can use in
> their apps without danger of colliding with OAuth or the future extensions
> that mimic it (do you *really* think this is going to be the Last Authentication
> Scheme in the World?). It affects the folks who have to figure out how to
> graft this mechanism onto existing systems that already use the parameter
> name you've chosen.
> 
> I really don't want to have to go through a list of 50 such "reserved" query
> parameters every time I write a new Web app in ten years. Sorry if having a
> perspective that's further out than my nose gets me out of the "hacker"
> bucket into the dreaded "architect" camp. Deploying and maintaining
> extremely large systems over a long period of time has taught me that it's a
> good idea. YMMV.
> 
> Thanks,
> 
> >
> > -- Dick
> >
> > On Apr 17, 2012, at 8:28 PM, Eran Hammer wrote:
> >
> >> A site has a bunch of APIs. They want to use OAuth with Bearer tokens.
> They can no longer use the access_token parameter for their own use cases
> because the Bearer token specification creates a conflict. This conflict does
> not exist with the use of the header. It does exist with the use of the body if
> they have an access_token parameter already in use.
> >>
> >> The API format has nothing to do with OAuth, but the use of a query
> parameter leaks into that namespace.
> >>
> >> This isn't a critical issue. It is a hack - it has always been since it was
> introduced in OAuth 1.0. The issue raised was about web architecture in
> general and setting a precedence. I don't think it will likely to create real-
> world problems, but the same goes for not supporting this use case anymore
> (or at least explicitly marking it as deprecated, maybe even demoted to an
> appendix documenting historical use).
> >>
> >> While the violation of the provider namespace is a significant principal, I
> want to make sure my view isn't coming off as some severe warning. Either
> way, it is not a big deal IMO.
> >>
> >> EH
> >>
> >> From: Dick Hardt [mailto:[e-mail]]
> >> Sent: Tuesday, April 17, 2012 12:32 PM
> >> To: Eran Hammer
> >> Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; Ned
> >> Freed; [e-mail]; Apps Discuss
> >> Subject: Re: [apps-discuss] Reserved URI query parameter in
> >> draft-ietf-oauth-v2-bearer
> >>
> >> Please elaborate on what the issue is then as protecting API resources is
> what OAuth is all about.
> >>
> >> On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote:
> >>
> >>
> >> That has nothing to do with this issue. The protected resources API format
> was never part of OAuth at any time.
> >>
> >> EH
> >>
> >> From: Dick Hardt [mailto:[e-mail]]
> >> Sent: Tuesday, April 17, 2012 9:50 AM
> >> To: Eran Hammer
> >> Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed;
> >> [e-mail]; Apps Discuss
> >> Subject: Re: [apps-discuss] Reserved URI query parameter in
> >> draft-ietf-oauth-v2-bearer
> >>
> >>
> >> On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote:
> >>
> >>
> >>
> >> (Sticking with the naivety:-) So, what's different there from how the
> >> base oauth draft registers client_id and shows how that can be used
> >> in a GET request? [1]
> >>
> >> Big difference. The base draft specifies its own endpoints as part of a
> complete API package for obtaining authorization. These parameters are
> scoped only for the endpoints defined and not for any others. There is no
> possibility of conflict because the specification defines the entire namespace.
> >>
> >> OTOH, the bearer spec is applied to *any* web resources using OAuth
> authentication where some other namespace definition must exist.
> >>
> >>
> >> If we had kept it all in one spec as it had originally been drafted,
> >> this would not be an issue, and it would be easier for implementers
> >> to understand. I don't know of anyone looking to implement the bearer
> >> spec independent of the base spec. (would be interested if anyone
> >> does know of an implementation)
> >
> 
> --
> Mark Nottingham
> http://www.mnot.net/
> 
> 
>