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

[Ned Freed <[e-mail]>]

> Folks,

> Mark mentioned to me that he did not think one major issue in his review
> of this document was fully addressed. I would like to get some feedback
> from other folks here on the Apps-discuss list as I cannot say myself
> that I fully understand the implications of the issue.

> Mike Jones <[e-mail]> wrote:

> > Mark Nottingham <[e-mail]> wrote:
> >
> >> * Section 2.3 URI Query Parameter
> >>
> >> This section effectively reserves a URI query parameter for the
> >> draft's use. This should not be done lightly, since this would be a
> >> precedent for the IETF encroaching upon a server's URIs (done
> >> previously in RFC5785, but in a much more limited fashion, as a
> >> tactic to prevent further, uncontrolled encroachment).
> >>
> >> Given that the draft already discourages the use of this mechanism,
> >> I'd recommend dropping it altogether. If the Working Group wishes it
> >> to remain, this issues should be vetted both through the APPS area
> >> and the W3C liaison.
> >>
> >> (The same criticism could be leveled at Section 2.2 Form-Encoded Body
> >> Parameter, but that at least isn't surfaced in an identifier)
> >
> > There are some contexts, especially limited browsers and/or
> > development environments, where query parameters are usable but the
> > other methods are not.  Thus, the query parameter method must be
> > retained.  Also, Justin Richter's comments describing the value to him
> > of the query parameter method are pertinent:  A URL with all
> > parameters including authorization is a powerful artifact which can be
> > passed around between systems as a unit.
> >
> > As to using a standard parameter name, this is essential for
> > interoperability.  It is not reserved in any contexts other than when
> > the Bearer spec is employed, which is a voluntary act by both
> > parties.  Thus, this poses no undue burdens or namespace restrictions
> > on implementations in practice.
> >
> > Finally, you'll find that OAuth 1.0 [RFC 5849] similarly defined, not
> > one, but two standard query parameter values:  oauth_token and
> > oauth_verifier.  As this didn't cause any problems in practice then,
> > I'm sure that defining an access_token parameter within the Bearer
> > spec for interoperability purposes won't cause a problem either.

> Would anyone (including, but not limited to, Mark) be able to better
> explain the issue here?

Pete, I think the issue is moot at this point. A quick google search clearly
shows that this stuff is already deployed by multiple vendors, including use of
access_token. As such, it is effectively impossible to change it at this point.

I have to say I would have a lot more comfortable with a name like
oauth_access_token that removes the possibility of conflict with other uses,
but at this point it's a "grin and bear it" situation AFAICT.

				Ned