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

[Eran Hammer <[e-mail]>]

The issue is pretty simple. The OAuth bearer token specification defines an HTTP Authorization header scheme. It also provides a "hack" for sending the same authentication credentials direction in the HTTP request URI. For example:

http://example.com/protected/resource?access_token=alskjdlaskjd

This in practice claims the 'access_token' URI query parameter as a reseved parameter name used by the bearer token specification. The reason is that any future (or existing) implementation using this parameter name will now be in conflict with the OAuth bearer token specification. We do not have a mechanism for reserving URI query parameters - but in practice, this updates RFC 3986 by taking ownership of the query parameter name.

There were other voices on the OAuth WG to simply drop this mechanism but resistance from the authors and lack of strong consensus kept it in.

I supported Mark's recommendation of dropping that mechanism.

Hope this is helpful.

EH

________________________________________
From: [e-mail] [[e-mail]] on behalf of Pete Resnick [[e-mail]]
Sent: Wednesday, April 11, 2012 10:40 PM
To: Apps Discuss; [e-mail]
Subject: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

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?

Thanks,

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: [phone], Fax: [phone]

_______________________________________________
apps-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/apps-discuss