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

[John C Klensin <[e-mail]>]

--On Friday, April 13, 2012 00:43 -0700 Ned Freed
<[e-mail]> wrote:

>> On 12/04/2012, at 4:15 PM, Ned Freed wrote:
>> > 
>> > 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.
> 
>> I would still like to see us do the right thing by the W3C,
>> and I don't see why the IESG can't insert language that
>> cautions against this (as well as future things like it).
> 
> 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.
> 
> But I also think that believing this will prevent or even
> significantly limit it's use is probably unrealistic given how
> far it deployment appears to have gotten.

Agreeing that the horse has left the barn and is far down the
street, the IETF is still being asked to publish this and
publish it with some level of authority that we call "IETF
Consensus" and/or "Standard".

Recommendation:

(1) For reasons explained in my earlier note, prune this down to
one recommended/standardized method, not three.

(2) For any other methods, document them as existing practice
(and consequently alternatives) and _at least_ discuss the
reasons for and against using them.

(3) If the recommendation is to use a reserved query parameter
keyword, seriously consider making that keyword something like
"oauth_access_token" but noting that "access_token" is in use as
a synonym and that, while we discourage it, servers SHOULD
normally treat it as a synonym.  I disagree with Ned to the
extent that, as a firm believer in Murphy's Law and the general
perversity of the universe, I would have said "reduce", rather
than "remove", the possibility of conflict, but even "reduce"
would be A Good Thing.

(4) The document should explain the risks associated with
someone using "?access_token"  to mean something else entirely
and of parsing, hashing, or encoding URL tails in ways that
effectively disable the intent of the spec.

I think that represents a reasonable balance with reality and
existing practice while avoiding IETF endorsement of practices
we have ample reason to believe are undesirable and should not
be encouraged or endorsed.

An alternative would be to not standardize this at all but
simply publish a slightly-revised version of the document as an
Informational description of existing practice, noting W3C
endorsement to whatever degree that is appropriate.  I actually
don't think that is a particularly good idea, but it would be
another way out.

best,
   john