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

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Sunday, April 15, 2012 1:50 PM
> To: Eran Hammer
> Cc: Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-oauth-v2-
> bearer.all@tools.ietf.org; Apps Discuss
> Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-
> oauth-v2-bearer
> 
> 
> Hi Eran,
> 
> On 04/15/2012 07:31 AM, Eran Hammer wrote:
> >
> >
> >> -----Original Message-----
> >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> >> bounces@ietf.org] On Behalf Of Stephen Farrell
> >> Sent: Friday, April 13, 2012 3:36 PM
> >> To: Mark Nottingham
> >> Cc: Pete Resnick; Ned Freed;
> >> draft-ietf-oauth-v2-bearer.all@tools.ietf.org;
> >> Apps Discuss
> >> Subject: Re: [apps-discuss] Reserved URI query parameter in
> >> draft-ietf- oauth-v2-bearer
> >>
> >>
> >>
> >> On 04/13/2012 10:24 PM, Mark Nottingham wrote:
> >>> Because it's a name space that is managed and owned by the authority
> >>> of
> >> the URI, not any standards organisation.
> >>>
> >>> I.e. we tell them how the URI is structured, not what to put into it.
> >>>
> >>> We made *one* exception for this in .well-known as an escape valve
> >>> for
> >> abuse. If we continue allowing this kind of abuse, we'll have little
> >> defence against things like standardising filename extensions in URLs
> >> and reserving an "/about/" URI's semantics -- things which are
> >> clearly violating the architecture of the WWW:
> >>>  http://www.w3.org/TR/webarch/#uri-opacity
> >>
> >> (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.
> 
> I guess that might be a big difference, not sure. Where is that aspect (a
> complete API package) described in the oauth base spec or elsewhere?

http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-3

This section defines the two server and one client endpoints required by OAuth. Those opting to deploy these resources must abide by their syntax which completely defines their URI query parameters.

> I also don't recall mention of API packages in the other responses on this
> thread, so I'm not sure if that's a wide-spread opinion or if there's
> disagreement about it.

This should be pretty standard API approach, whereas the full scope of query parameters are defined as a set and are not expect to overlap with any others on the API resources. By adopting the API, the developer buys into the namespace definition. However, when using OAuth for authentication of existing API endpoints that have otherwise nothing to do with OAuth, there is a namespace collision.

> > OTOH, the bearer spec is applied to *any* web resources using OAuth
> authentication where some other namespace definition must exist.
> 
> Seems like a fair point. But like I said above, I'm unsure if that's just a matter
> of degree or not. (Maybe the base spec is "a little bit pregnant" in this
> respect? ;-)

This isn't a matter of degree. The basic assumption is that providers supporting OAuth bearer authentication will be required to understand this query parameter and therefore, cannot use it to avoid any client confusion.

EH

> S
> 
> > EH
> >
> >> Ta,
> >> S.
> >>
> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-25#page-24
> >>     (bottom of page)
> >>
> >>
> >>>
> >>> Cheers,
> >>>
> >>>
> >>> On 13/04/2012, at 4:20 PM, Stephen Farrell wrote:
> >>>
> >>>>
> >>>>
> >>>> On 04/13/2012 08:43 AM, Ned Freed wrote:
> >>>>> I certainly don't object to doing that. In fact I don't object to
> >>>>> dropping this nasty hack from the document, although perhaps
> >>>>> documenting it as *not* standardized and explaining why it sucks
> >>>>> would
> >> be even better.
> >>>>
> >>>> So I've a possibly naive question:
> >>>>
> >>>> Why is it harmful to standardise a parameter name for use in query
> >>>> strings?
> >>>>
> >>>> Note: I'm not asking if access_token is a good or bad name for one
> >>>> of those, nor how exactly to standardise one well or badly, nor who
> >>>> should do that, but it seems from the comments here that some folks
> >>>> are against the idea of standardising anything after the authority
> >>>> is a bad idea, and I don't get why exactly that might be the case.
> >>>>
> >>>> Thanks,
> >>>> S.
> >>>>
> >>>
> >>> --
> >>> Mark Nottingham
> >>> http://www.mnot.net/
> >>>
> >>>
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> apps-discuss mailing list
> >> apps-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >