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

[Pete Resnick <[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?

Thanks,

pr

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