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

[Ned Freed <[e-mail]>]

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

Agreed on all points. I'm also not wild on the alternative, but as you
say, it would be acceptable.

				Ned