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

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

OTOH, the bearer spec is applied to *any* web resources using OAuth authentication where some other namespace definition must exist.

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