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

From: Pete Resnick <[email-masked]>
Date: Thu, 12 Apr 2012 00:40:16 -0500

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 <[email-masked]> wrote:

> Mark Nottingham <[email-masked]> 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: (858)651-4478, Fax: (858)651-1102

---

From: Eran Hammer <[email-masked]>
Date: Thu, 12 Apr 2012 12:56:19 +0000

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: [email-masked] [[email-masked]] on behalf of Pete Resnick [[email-masked]]
Sent: Wednesday, April 11, 2012 10:40 PM
To: Apps Discuss; [email-masked]
Subject: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

Folks,

Thanks,

pr

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Apr 2012 15:09:09 +0200

On 2012-04-12 14:56, Eran Hammer wrote:
> ...

It is.

Right now the spec describes the two fallback methods and the auth 
scheme side-by side.

Maybe it should be reorganized so that is only mentions the 
query-parameter and form-based schemes as workarounds in an appendix, so 
that it becomes clearer that when you use those, you're *not* doing HTTP 
Bearer authentication?

Best regards, Julian

---

From: Tim Bray <[email-masked]>
Date: Thu, 12 Apr 2012 09:34:45 -0700

Well, it would claim it as a reserved paramater name if there a way to
do such a thing, which there explicitly isn’t in RFC3986.  URIs are
for most application purposes opaque strings; this breaks that and is
a hideous architectural botch.

For example, there is a huge amount of deployed code out there which
compares two URIs and determines whether they are equivalent or
different (to start with, every piece of crawling and caching
infrastructure in the world); must it all now be refactored to check
the parameters for oauth_* and disregard those values in their
equality considerations?  Chapter 6 of RFC3986 explicitly discusses
issues in comparing URIs for equivalency; read it, and you’ll find
nothing there about ?name=value pairs.

This is not how URIs work.  It might be convenient in some application
scenarios, but in other application scenarios it might be convenient
to add your own IP packet header bits, and you can’t do that either.

Please back this horrible idea out.  -T

---

From: John C Klensin <[email-masked]>
Date: Thu, 12 Apr 2012 14:27:14 -0400

Pete,

The first part of this may be the same as Tim Bray's answer in
different form, but, in studying it I spotted an additional, and
IMO, fundamental, issue.  I want to note that, prior to your
request, I had not reviewed this specification -- it falls into
an area in which I have assumed, and continue to believe, that
there are lots of competent people in the IETF watching and
that, in general, my time is therefore better spent in other
ways.  I've also had a specific reason to avoid it for which I
will provide details to you you off list.

We've basically got two types of identifiers or identifier
structures.  One is completely restricted and associated, to the
best of our ability, with very specific syntax rules and actual
or implied registries for keywords. The other is free-form or
has a form whose locus of interpretation is either determined by
a registered keyword and associated rigid syntax or a very
narrow rule about where interpretation of the syntax can occur.

We have both with email addresses: A high-level syntax (ignoring
source routes, "@" divides things into a left side and a right
side. The right side is a domain name (specific syntax and with
the DNS itself serving as a registry).  The left side can be
interpreted only by the destination server and is otherwise
pretty much an opaque blob of text.

It is no secret that I've never been a big fan of URIs.  Much of
the reason is that they try to combine the above and do it
badly: we've got a method type that has a rigid syntax
(case-insensitive ASCII alphanumeric string if I recall) and a
registry.  After that, the syntax gets method-dependent, with
some symbols and strings (varying somewhat by method) having
specific syntax and registry structure (e.g., when the locator
is a domain name and nothing else is permitted there) and other
bits being opaque except to the method or the combination of a
method and a particular host or other identifier, or...   And
syntax is sometimes reserved and sometimes not.    

At some level, that characterization is unfair because the
actual rules are more precise than the above implies.  On the
other hand, I suggest that the number of people in the community
who could actually describe the exact rules to a third party in
a reasonably short period of time, without the spec in front of
them and without hand waving, and have that third party
understand the rules when they are finished is few indeed.

But now the this spec presumes to come along and essentially
create an overlay on the general URI spec (see below) that
reserves a query parameter that can somehow be used even in
environments in which normal URI interpretation doesn't permit
queries.  It isn't clear from a quick reading of the spec
whether that is actually intended or whether this is a
collection of methods that apply to HTTP 1.1 only -- the text
talks about URIs but the cases and examples given appear to be
very HTTP (and maybe even HTTP 1.1)-specific.   If it were
clearly restricted to HTTP/HTTPS URLs, it would be somewhat more
palatable because those URIs at least don't prohibit query parts.

But the problem is with defining a specific query keyword,
across hosts/locations and maybe across methods, for this use.
The document doesn't discuss what has been done to demonstrate
that they keyword is not in use anywhere else (a nearly
impossible task given that there is no registry and no
restrictions on such keywords and that they are interpreted on a
per-server basis).  It should at least discuss what would happen
if someone were using this keyword for an entirely different
purpose.  Presumably such a use would safely fail any
OAUTH-related tests, but the effect of OAUTH changing the intent
of the original parameter would be, it seems to me,
unpredictable.

This is not a suggestion because the basic problem would remain,
but we have mechanisms that we have tried in the past to at
least significantly minimize the risks that a specific keyword
or bit of syntax that is newly-introduced into a previously
unrestricted or less restricted space will not interfere with an
unknown catalog of prior (or even future but unrelated) uses.
None of them use anything as generic-sounding as "access_token".
If, contrary to the other suggestions here (and Tim's and Mark's
comments), the IESG were to go ahead with this spec, the
practical risks would be reduced by borrowing notes from IDNA
(perhaps "xyz--access_token" or "access-_token") or some of the
discussions about alternatives to "x-" (perhaps
"oath-bearer.access_token").  Note the deliberately-odd mix of
hyphens and underscores in both examples.

Unless some syntax can be found that violates the URI
specification (or at least the HTTP/HTTPS URL specification, see
above) so as to mark a clear boundary between "end of normal
URI" and access token information, perhaps the "right" way to do
this would be to encapsulate the URI as a payload inside an OATH
access package.  Another plausible alternative would be to
simply eliminate this option by dropping Section 2.3 from the
spec.  But that leads to a broader issue and criticism:

IETF protocols have generally been the most successful when they
provide a minimum number of ways to do something, ideally no
more than one.  This specification provides three (see Section
2), which we normally discourage, at least in the absence of
very strong motivation.  As far as I can tell (I've read through
the spec, but not studied every word), that motivation is not
explained in the document, nor are there criteria for which one
should be selected under different circumstances (other than the
"MUST NOT use...unless" statement about the method in Section
2.2), and there is no mandatory-to-implement provision for
clients or servers.  If the authors intend to require that all
servers support all three models so that clients can do as they
like without interoperability issues, they should say so.
Otherwise, this is a recipe for interoperability failures (and,
if all servers are required to support all methods, it is a
requirement for apparently-unnecessary complexity.

Recommendation: This specification should not be approved unless
either:

(i) Two of the three methods are removed, noting that removing
2.3 would eliminate most of the keyword and syntax-related
objections.  If 2.3 remains, those issues should be dealt with
as well.

(ii) The document was enhanced with a consensus discussion about
why multiple methods are needed, how clients and servers should
make decisions about what to actually implement and use, and
what, if any methods and features can be depended on for
interoperability (e.g., are mandatory to implement).

You asked :-(

  regards,
        john

---

From: Ned Freed <[email-masked]>
Date: Thu, 12 Apr 2012 14:15:49 -0700 (PDT)

> Would anyone (including, but not limited to, Mark) be able to better

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Apr 2012 18:04:53 -0500

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

Besides which, those sites have chosen to adopt a private, pre-standard convention for their Web sites; having a standard start to encroach on their name space is a very different thing.

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: Ned Freed <[email-masked]>
Date: Fri, 13 Apr 2012 00:43:24 -0700 (PDT)

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

				Ned

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Apr 2012 15:53:10 -0400

--On Friday, April 13, 2012 00:43 -0700 Ned Freed
<[email-masked]> 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
>> > 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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Apr 2012 22:20:41 +0100

> standardized and explaining why it sucks would be even better.

So I've a possibly naive question:

Why is it harmful to standardise a parameter name for use in
query strings?

Note: I'm not asking if access_token is a good or bad name for
one of those, nor how exactly to standardise one well or badly,
nor who should do that, but it seems from the comments here that
some folks are against the idea of standardising anything after
the authority is a bad idea, and I don't get why exactly that
might be the case.

Thanks,
S.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 13 Apr 2012 16:24:39 -0500

Because it's a name space that is managed and owned by the authority of the URI, not any standards organisation.

I.e. we tell them how the URI is structured, not what to put into it.

We made *one* exception for this in .well-known as an escape valve for abuse. If we continue allowing this kind of abuse, we'll have little defence against things like standardising filename extensions in URLs and reserving an "/about/" URI's semantics -- things which are clearly violating the architecture of the WWW:
 http://www.w3.org/TR/webarch/#uri-opacity

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: Tim Bray <[email-masked]>
Date: Fri, 13 Apr 2012 15:07:02 -0700

As I pointed out in the other thread on this, it’s an architectural
botch. Go and look in RFC3986 and find where it discusses reserving
keywords in this part of the URI.  Hey, it’s not there!  (hint, hint)

What *is* there is a lengthy discussion of the very important task,
done probably millions of times per second, of comparing two URIs and
deciding if they're equivalent, i.e. identify the same thing; this is
done by every piece of caching infrastructure and webcrawler.  Do all
these have to be retooled to peek in the arguments and change their
decision based on whether some bits are just outh_* crud?    (That
question is rhetorical).

This is a deeply bad idea. -T

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Apr 2012 23:35:38 +0100

>  http://www.w3.org/TR/webarch/#uri-opacity

(Sticking with the naivety:-) So, what's different there
from how the base oauth draft registers client_id and
shows how that can be used in a GET request? [1]

Ta,
S.

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-25#page-24
    (bottom of page)

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 14 Apr 2012 01:11:04 +0200

> a hideous architectural botch.

I would like to turn this observation around.

People put stuff like this into the URI because there are applications where it would be useful to combine information such as what we'd prefer to put into HTTP header fields with URI information into one *thing*.
(Or they put stuff into Cookies because this URI munching doesn't always work very well either.)

Independent from the specific subject here (where there is little point in further invention), I think it would be useful to explore a little more the reasons for this and maybe find a better way to carry around information that is ancillary to a resource access.  The recent http+aes brouhaha is another (somewhat different, as it is client-side only) example for this need, I think.  (The way mailto: has evolved is an example where this need could be met within the URI scheme.)

Grüße, Carsten

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Apr 2012 19:41:25 -0400

--On Saturday, April 14, 2012 01:11 +0200 Carsten Bormann
<[email-masked]> wrote:

>> Well, it would claim it as a reserved paramater name if there
>> a way to do such a thing, which there explicitly isn't in
>> RFC3986.  URIs are for most application purposes opaque
>> strings; this breaks that and is a hideous architectural
>> botch.
> 
> People put stuff like this into the URI because there are
> applications where it would be useful to combine information
> such as what we'd prefer to put into HTTP header fields with
> URI information into one *thing*. (Or they put stuff into
> Cookies because this URI munching doesn't always work very
> well either.)
> 
> Independent from the specific subject here (where there is
> little point in further invention), I think it would be useful
> to explore a little more the reasons for this and maybe find a
> better way to carry around information that is ancillary to a
> resource access.  The recent http+aes brouhaha is another
> (somewhat different, as it is client-side only) example for
> this need, I think.  (The way mailto: has evolved is an
> example where this need could be met within the URI scheme.)

Carsten,

Just a quick personal opinion, related to your more general
comment above but almost unrelated to the specific OAUTH
parameter.

We (that is IETF and W3C) made a decision (a very long time ago
as these things go) to not establish an explicit terminator for
the end of a URI tail.  If we had such a terminator, we would
now have a place, post-terminator, for putting "stuff" that is
important but that would not foul up comparison of URIs.  If we
were smart about it, we might even establish a keyword registry
for things hung off  the end, thereby eliminating one of the
other problems that people are concerned about.

I don't know if it would be possible to revisit that decision at
this point.  Certainly it would be painful if it were even
possible.  But it seems to me that it, or something like it (an
equally difficult possibility might be to figure out a way to
hide qualifying information in the vicinity of the Method field)
are, I think, the only ways that one can both insert information
that is relevant to aspects of URIs generally without
compromising either the ability to compare them of the
assumption that anything that falls into the tail belongs to the
target server and gets interpreted pretty much as it desires.

regards,
    john

---

From: Ned Freed <[email-masked]>
Date: Fri, 13 Apr 2012 22:58:04 -0700 (PDT)

> People put stuff like this into the URI because there are applications where it would be useful to combine information such as what we'd prefer to put into HTTP header fields with URI information i…

This is clearly true, and there are all sorts of hacks out there to do this.

There are just too many places where you have only one slot, so you have to
combine stuff into one, as you say, thing.

That said, the rules are what they are, and comparison of URIs has to be taken
into account.

> Independent from the specific subject here (where there is little point in
> further invention), I think it would be useful to explore a little more the
> reasons for this and maybe find a better way to carry around information that
> is ancillary to a resource access.  The recent http+aes brouhaha is another
> (somewhat different, as it is client-side only) example for this need, I think. 
> (The way mailto: has evolved is an example where this need could be met within
> the URI scheme.)

I think this is an excellent idea, but of course it's far outside the purview
of the present document.

				Ned

---

From: Tim Bray <[email-masked]>
Date: Sat, 14 Apr 2012 00:58:31 -0700

That would be http://tools.ietf.org/html/rfc3986#section-6

The fact that it’s kind of long, but still doesn’t find room for
reserved ?key=val pairs, is significant in this context. -T

On Sat, Apr 14, 2012 at 12:43 AM, Dick Hardt <[email-masked]> wrote:
>
> On Apr 13, 2012, at 10:58 PM, Ned Freed wrote:
>
>
> What is the URI comparison rule you are referring to?
>
> -- Dick

---

From: Mike Jones <[email-masked]>
Date: Sat, 14 Apr 2012 18:13:06 +0000

I don't believe that URI comparison considerations are pertinent here.  Here's why...

These URIs contain a bearer token.  As such, it would be a complete security breach for these URIs to ever become visible to any but the intended parties.  Why?  Per the Security Considerations section, this would allow anyone in possession of them to successfully impersonate the client and perform operations as if they were the client.  (That's the nature of a bearer token.)

Therefore, these URIs MUST never be visible to Web crawlers or any other third parties that might try to use URI comparison rules on them in some generic way.  For security reasons, their use is scoped strictly to the client and the protected resource.

Therefore, URI comparison considerations do not apply.

				-- Mike

-----Original Message-----
From: Dick Hardt [mailto:[email-masked]] 
Sent: Saturday, April 14, 2012 1:25 AM
To: Tim Bray
Cc: Dick Hardt; Ned Freed; Carsten Bormann; Pete Resnick; Apps Discuss; [email-masked]
Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

Thanks Tim.

I did not see any discussion on normalizing key=value pairs. One would assume that http://exmaple.com/?a=1&b=2 is equivalent to http://exmaple.com/?b=2&a=1 -- but that does not seem to be significant here.

There are numerous practical reasons for the bearer token to be able to be passed as a query parameter which I would be happy to enumerate if anyone is interested. (so far no one has asked :)

I'm trying to understand the desire to remove this functionality, and after reading the spec my take away is a desire to not specify a query parameter. What am I missing?

-- Dick

On Apr 14, 2012, at 12:58 AM, Tim Bray wrote:
> The fact that it's kind of long, but still doesn't find room for 
>> That said, the rules are what they are, and comparison of URIs has to 
>> be taken into account.
>> 
>>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 14 Apr 2012 00:43:36 -0700

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Sat, 14 Apr 2012 01:24:36 -0700

Thanks Tim.

-- Dick

---

From: Eran Hammer <[email-masked]>
Date: Sun, 15 Apr 2012 06:31:28 +0000

> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Friday, April 13, 2012 3:36 PM
> To: Mark Nottingham
> Cc: Pete Resnick; Ned Freed; [email-masked];
> Apps Discuss
> > We made *one* exception for this in .well-known as an escape valve for
> abuse. If we continue allowing this kind of abuse, we'll have little defence
> against things like standardising filename extensions in URLs and reserving an
> "/about/" URI's semantics -- things which are clearly violating the architecture
> of the WWW:
> (Sticking with the naivety:-) So, what's different there from how the base
> oauth draft registers client_id and shows how that can be used in a GET
> request? [1]

Big difference. The base draft specifies its own endpoints as part of a complete API package for obtaining authorization. These parameters are scoped only for the endpoints defined and not for any others. There is no possibility of conflict because the specification defines the entire namespace.

OTOH, the bearer spec is applied to *any* web resources using OAuth authentication where some other namespace definition must exist.

EH
 
> >>> 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.
> >>
> >> Why is it harmful to standardise a parameter name for use in query
> >> strings?
> >>
> >> Note: I'm not asking if access_token is a good or bad name for one of
> >> those, nor how exactly to standardise one well or badly, nor who
> >> should do that, but it seems from the comments here that some folks
> >> are against the idea of standardising anything after the authority is
> >> a bad idea, and I don't get why exactly that might be the case.
> >>
> >> Thanks,
> >> S.
> >>
> >
> > --
> > Mark Nottingham
> > http://www.mnot.net/
> >
> >
> >
> >
> >

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Apr 2012 21:49:50 +0100

Hi Eran,

> Big difference. The base draft specifies its own endpoints as part of a complete API package for obtaining authorization. These parameters are scoped only for the endpoints defined and not for any…

I guess that might be a big difference, not sure. Where is that
aspect (a complete API package) described in the oauth base spec
or elsewhere?

I also don't recall mention of API packages in the other responses
on this thread, so I'm not sure if that's a wide-spread opinion
or if there's disagreement about it.

> OTOH, the bearer spec is applied to *any* web resources using OAuth authentication where some other namespace definition must exist.

Seems like a fair point. But like I said above, I'm unsure if
that's just a matter of degree or not. (Maybe the base spec is
"a little bit pregnant" in this respect? ;-)

S

---

From: Derek Atkins <[email-masked]>
Date: Mon, 16 Apr 2012 10:38:15 -0400

Tim,

> This is a deeply bad idea. -T

As pointed out elsewhere on this thread by Mike Jones, caches, crawlers,
and other middleware will never see this because the bearer token MUST
be protected by SSL/TLS.  So no, nothing needs to be retooled because
nothing will see it.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: William Mills <[email-masked]>
Date: Mon, 16 Apr 2012 08:32:06 -0700 (PDT)

A big problem, in my opinion, is that credentials will end up in the browser history cache when they are included in the URL.  This is significant.  Unless an explicit user "sign out" in the browser invalidates all tokens issued to the browser (this is a significant revocation requirement and revocations isn't properly solved yet) then someone sitting down at the machine can recover a credential by looking in the history.

Note that enterprise edge proxies that are doing SSL termination may well see this, but that could be considered "their problem".  I have seen apparent evidence of 
large companies using egress proxies that terminate all SSL outbound at 
their proxy (depressingly evil), and they frequently get stuff wrong in 
terms of proxy settings.

-bill

>________________________________
> From: Derek Atkins <[email-masked]>
>To: Tim Bray <[email-masked]> 
>Cc: Ned Freed <[email-masked]>; [email-masked]; Apps Discuss <[email-masked]>; Mark Nottingham <[email-masked]>; Pete Resnick <[email-masked]> 
>Sent: Monday, April 16, 2012 7:38 AM

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Apr 2012 16:47:11 +0100

Hi Bill,

> their proxy (depressingly evil), and they frequently get stuff wrong in 

Right. I agree that is an issue. The draft does try to address that
and we can chat about whether it does that well enough or not (but
that's maybe more for the oauth list really.)

But your issue is a different one from that being discussed in
this thread. Yours is due to the value being a bearer token and
not due to the name of the parameter being registered/reserved.

S.

---

From: William Mills <[email-masked]>
Date: Mon, 16 Apr 2012 09:23:18 -0700 (PDT)

> From: Stephen Farrell <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: Derek Atkins <[email-masked]>; Tim Bray <[email-masked]>; Ned Freed <[email-masked]>; "[email-masked]" <[email-masked]>; Apps Discuss <[email-masked]>; Mark Nottingham <[email-masked]>; Pete Resnick <[email-masked]> 
>Sent: Monday, April 16, 2012 8:47 AM

Yeah, true.  But if it's not there then it doesn't need a name.

---

From: Eran Hammer <[email-masked]>
Date: Mon, 16 Apr 2012 21:57:24 +0000

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Sunday, April 15, 2012 1:50 PM
> To: Eran Hammer
> Cc: Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-oauth-v2-
> [email-masked]; Apps Discuss
> >> Cc: Pete Resnick; Ned Freed;
> >> [email-masked];
> >> Apps Discuss
> >> Subject: Re: [apps-discuss] Reserved URI query parameter in
> >> draft-ietf- oauth-v2-bearer
> >>
> >>
> >>
> >>> Because it's a name space that is managed and owned by the authority
> >>> of
> >> the URI, not any standards organisation.
> >>>
> >> abuse. If we continue allowing this kind of abuse, we'll have little
> >> defence against things like standardising filename extensions in URLs
> >> and reserving an "/about/" URI's semantics -- things which are
> >> clearly violating the architecture of the WWW:
> >> (Sticking with the naivety:-) So, what's different there from how the
> >> base oauth draft registers client_id and shows how that can be used
> >> in a GET request? [1]
> >
> > Big difference. The base draft specifies its own endpoints as part of a
> complete API package for obtaining authorization. These parameters are
> scoped only for the endpoints defined and not for any others. There is no
> possibility of conflict because the specification defines the entire namespace.
> 
> I guess that might be a big difference, not sure. Where is that aspect (a
> complete API package) described in the oauth base spec or elsewhere?

http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-3

This section defines the two server and one client endpoints required by OAuth. Those opting to deploy these resources must abide by their syntax which completely defines their URI query parameters.

> I also don't recall mention of API packages in the other responses on this
> thread, so I'm not sure if that's a wide-spread opinion or if there's
> disagreement about it.

This should be pretty standard API approach, whereas the full scope of query parameters are defined as a set and are not expect to overlap with any others on the API resources. By adopting the API, the developer buys into the namespace definition. However, when using OAuth for authentication of existing API endpoints that have otherwise nothing to do with OAuth, there is a namespace collision.
 
> > OTOH, the bearer spec is applied to *any* web resources using OAuth
> authentication where some other namespace definition must exist.
> 
> Seems like a fair point. But like I said above, I'm unsure if that's just a matter
> of degree or not. (Maybe the base spec is "a little bit pregnant" in this
> respect? ;-)

This isn't a matter of degree. The basic assumption is that providers supporting OAuth bearer authentication will be required to understand this query parameter and therefore, cannot use it to avoid any client confusion.

EH
 
> >>>> Note: I'm not asking if access_token is a good or bad name for one
> >>>> of those, nor how exactly to standardise one well or badly, nor who
> >>>> are against the idea of standardising anything after the authority
> >>>> is a bad idea, and I don't get why exactly that might be the case.
> >>>>
> >>>> Thanks,
> >>>> S.
> >>>>
> >>>
> >>> --
> >>> Mark Nottingham
> >>> http://www.mnot.net/
> >>>
> >>>
> >>>
> >>>
> >>>

---

From: Mike Jones <[email-masked]>
Date: Mon, 16 Apr 2012 22:07:11 +0000

I'll note that RFC 5849, which defines two such query parameters:  oauth_token and oauth_verifier, doesn't seem to have created any problems in practice by doing so.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer
Sent: Monday, April 16, 2012 2:57 PM
To: Stephen Farrell
Cc: Pete Resnick; Mark Nottingham; Ned Freed; Apps Discuss; [email-masked]
Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

> >>> Because it's a name space that is managed and owned by the 
> >>> authority of
> >> abuse. If we continue allowing this kind of abuse, we'll have 
> >> little defence against things like standardising filename 
> >> extensions in URLs and reserving an "/about/" URI's semantics -- 
> >> things which are clearly violating the architecture of the WWW:
> >> (Sticking with the naivety:-) So, what's different there from how 
> >> the base oauth draft registers client_id and shows how that can be 
> >> used in a GET request? [1]
> >
> scoped only for the endpoints defined and not for any others. There is 
> no possibility of conflict because the specification defines the entire namespace.
> 
> I guess that might be a big difference, not sure. Where is that aspect 
> (a complete API package) described in the oauth base spec or elsewhere?

> I also don't recall mention of API packages in the other responses on 
> this thread, so I'm not sure if that's a wide-spread opinion or if 
> there's disagreement about it.

> Seems like a fair point. But like I said above, I'm unsure if that's 
> just a matter of degree or not. (Maybe the base spec is "a little bit 
> pregnant" in this respect? ;-)

EH
 
> >>>>> to dropping this nasty hack from the document, although perhaps 
> >>>> the authority is a bad idea, and I don't get why exactly that might be the case.
> >>>>
> >>>> Thanks,
> >>>> S.
> >>>>
> >>>
> >>> --
> >>> Mark Nottingham
> >>> http://www.mnot.net/
> >>>
> >>>
> >>>
> >>>
> >>>

---

From: Eran Hammer <[email-masked]>
Date: Tue, 17 Apr 2012 19:19:03 +0000

That has nothing to do with this issue. The protected resources API format was never part of OAuth at any time.

EH

From: Dick Hardt [mailto:[email-masked]]
Sent: Tuesday, April 17, 2012 9:50 AM
To: Eran Hammer
Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; [email-masked]; Apps Discuss
Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote:

If we had kept it all in one spec as it had originally been drafted, this would not be an issue, and it would be easier for implementers to understand. I don't know of anyone looking to implement the bearer spec independent of the base spec. (would be interested if anyone does know of an implementation)

---

From: Eran Hammer <[email-masked]>
Date: Wed, 18 Apr 2012 03:28:43 +0000

A site has a bunch of APIs. They want to use OAuth with Bearer tokens. They can no longer use the access_token parameter for their own use cases because the Bearer token specification creates a conflict. This conflict does not exist with the use of the header. It does exist with the use of the body if they have an access_token parameter already in use.

The API format has nothing to do with OAuth, but the use of a query parameter leaks into that namespace.

This isn't a critical issue. It is a hack - it has always been since it was introduced in OAuth 1.0. The issue raised was about web architecture in general and setting a precedence. I don't think it will likely to create real-world problems, but the same goes for not supporting this use case anymore (or at least explicitly marking it as deprecated, maybe even demoted to an appendix documenting historical use).

While the violation of the provider namespace is a significant principal, I want to make sure my view isn't coming off as some severe warning. Either way, it is not a big deal IMO.

EH

From: Dick Hardt [mailto:[email-masked]]
Sent: Tuesday, April 17, 2012 12:32 PM
To: Eran Hammer
Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; [email-masked]; Apps Discuss
Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

Please elaborate on what the issue is then as protecting API resources is what OAuth is all about.

On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote:

EH

From: Dick Hardt [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, April 17, 2012 9:50 AM
To: Eran Hammer
Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; [email-masked]<mailto:[email-masked]>; Apps Discuss
Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

---

From: Dick Hardt <[email-masked]>
Date: Tue, 17 Apr 2012 09:49:53 -0700

---

From: Dick Hardt <[email-masked]>
Date: Tue, 17 Apr 2012 09:52:57 -0700

On Apr 16, 2012, at 8:32 AM, William Mills wrote:

> Note that enterprise edge proxies that are doing SSL termination may well see this, but that could be considered "their problem".  I have seen apparent evidence of large companies using egress proxies that terminate all SSL outbound at their proxy (depressingly evil), and they frequently get stuff wrong in terms of proxy settings.

Bill: to address this issue, an implementation can issue short lived access_tokens which are refreshed with refresh_tokens. The refresh_token -> access_token exchange could be server to server and optionally as a header parameter so that it has stronger protection.

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Tue, 17 Apr 2012 12:31:35 -0700

---

From: William Mills <[email-masked]>
Date: Wed, 18 Apr 2012 08:50:09 -0700 (PDT)

OAuth 2.0 is different from 1.0(and a) in that it's an auth framework that deals with getting the tokens, but leaves the use of them to the companion specs.  I think this is what Eran is driving at, in the purest semantic sense.  The OAuth 2.0 API doesn't deal with protected resources at all though, and the discussion about query parameters is all about the protected resource.

> From: Dick Hardt <[email-masked]>
>To: Eran Hammer <[email-masked]> 
>Cc: Ned Freed <[email-masked]>; Apps Discuss <[email-masked]>; "[email-masked]" <[email-masked]>; Mark Nottingham <[email-masked]>; Pete Resnick <[email-masked]>; Dick Hardt <[email-masked]> 
>Sent: Tuesday, April 17, 2012 12:31 PM

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Apr 2012 11:59:47 -0700

On 18/04/2012, at 10:26 AM, Dick Hardt wrote:

> Thanks Eran, I think I understand.
> 
> To restate what you have said, specifying a query parameter as part of the spec is "bad" web architecture and potentially sets a precedent for other specifications to reserve a query parameter. Correct?
> 
> The reality is that the world is a messy place. Developers hack the architecture to accomplish goals not envisioned by the architects. The architects can accept the reality of the world, or ignore it and lose their relevance. In my opinion, putting the query parameter mechanism into an appendix is ignoring the reality of current implementations. Adding language to the spec that use of the query parameter is not architecturally ideal, but accepts the reality of the current web would be far more preferable.

… Except that AIUI that method has been identified as not good practice for entirely practical reasons, independent of the architectural reasons.

Putting that aside, there's a large difference between acknowledging and documenting broad practice that's bad and sanctioning its use to encourage further abuses.

Believe it or not, things like this *do* affect real people -- just not the "hackers" who are working on OAuth. It affects people who run real Web sites, because they have to consider what query parameters they can use in their apps without danger of colliding with OAuth or the future extensions that mimic it (do you *really* think this is going to be the Last Authentication Scheme in the World?). It affects the folks who have to figure out how to graft this mechanism onto existing systems that already use the parameter name you've chosen.

I really don't want to have to go through a list of 50 such "reserved" query parameters every time I write a new Web app in ten years. Sorry if having a perspective that's further out than my nose gets me out of the "hacker" bucket into the dreaded "architect" camp. Deploying and maintaining extremely large systems over a long period of time has taught me that it's a good idea. YMMV.

Thanks,

>  
> -- Dick
> 
> On Apr 17, 2012, at 8:28 PM, Eran Hammer wrote:
> 
>> This isn’t a critical issue. It is a hack – it has always been since it was introduced in OAuth 1.0. The issue raised was about web architecture in general and setting a precedence. I don’t think it will likely to create real-world problems, but the same goes for not supporting this use case anymore (or at least explicitly marking it as deprecated, maybe even demoted to an appendix documenting historical use).
>>  
>> While the violation of the provider namespace is a significant principal, I want to make sure my view isn’t coming off as some severe warning. Either way, it is not a big deal IMO.
>>  
>> EH
>>  

--
Mark Nottingham
http://www.mnot.net/

---

From: Eran Hammer <[email-masked]>
Date: Wed, 18 Apr 2012 20:00:11 +0000

A good example is the 'callback' query parameter used in JSONP.

OAuth 2.0 originally used a 'callback' parameter for its own APIs but we changed it after feedback from Facebook indicated there developers were confused by it and in some cases, that caused conflict with existing frameworks where 'callback' was always processed automatically. So while OAuth does not use JSONP, it had to renamed the parameter to 'redirect_uri' to avoid *potential* conflict.

EH

> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2012 12:00 PM
> To: Dick Hardt
> Cc: Eran Hammer; Stephen Farrell; Pete Resnick; Ned Freed; draft-ietf-oauth-
> [email-masked]; Apps Discuss
> > To restate what you have said, specifying a query parameter as part of the
> spec is "bad" web architecture and potentially sets a precedent for other
> specifications to reserve a query parameter. Correct?
> >
> > The reality is that the world is a messy place. Developers hack the
> architecture to accomplish goals not envisioned by the architects. The
> architects can accept the reality of the world, or ignore it and lose their
> relevance. In my opinion, putting the query parameter mechanism into an
> appendix is ignoring the reality of current implementations. Adding language
> to the spec that use of the query parameter is not architecturally ideal, but
> accepts the reality of the current web would be far more preferable.
> 
> ... Except that AIUI that method has been identified as not good practice for
> entirely practical reasons, independent of the architectural reasons.
> 
> Putting that aside, there's a large difference between acknowledging and
> documenting broad practice that's bad and sanctioning its use to encourage
> further abuses.
> 
> Believe it or not, things like this *do* affect real people -- just not the
> "hackers" who are working on OAuth. It affects people who run real Web
> sites, because they have to consider what query parameters they can use in
> their apps without danger of colliding with OAuth or the future extensions
> that mimic it (do you *really* think this is going to be the Last Authentication
> Scheme in the World?). It affects the folks who have to figure out how to
> graft this mechanism onto existing systems that already use the parameter
> name you've chosen.
> 
> I really don't want to have to go through a list of 50 such "reserved" query
> parameters every time I write a new Web app in ten years. Sorry if having a
> perspective that's further out than my nose gets me out of the "hacker"
> bucket into the dreaded "architect" camp. Deploying and maintaining
> extremely large systems over a long period of time has taught me that it's a
> good idea. YMMV.
> 
> Thanks,
> 
> >
> > -- Dick
> >
> >> A site has a bunch of APIs. They want to use OAuth with Bearer tokens.
> They can no longer use the access_token parameter for their own use cases
> because the Bearer token specification creates a conflict. This conflict does
> not exist with the use of the header. It does exist with the use of the body if
> they have an access_token parameter already in use.
> >>
> >> This isn't a critical issue. It is a hack - it has always been since it was
> introduced in OAuth 1.0. The issue raised was about web architecture in
> general and setting a precedence. I don't think it will likely to create real-
> world problems, but the same goes for not supporting this use case anymore
> (or at least explicitly marking it as deprecated, maybe even demoted to an
> appendix documenting historical use).
> >>
> >> While the violation of the provider namespace is a significant principal, I
> want to make sure my view isn't coming off as some severe warning. Either
> way, it is not a big deal IMO.
> >>
> >> EH
> >>
> >> Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; Ned
> >> Freed; [email-masked]; Apps Discuss
> >> draft-ietf-oauth-v2-bearer
> >>
> >> Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed;
> >> [email-masked]; Apps Discuss
> >> draft-ietf-oauth-v2-bearer
> >>
> >>
> >> If we had kept it all in one spec as it had originally been drafted,
> >> this would not be an issue, and it would be easier for implementers
> >> to understand. I don't know of anyone looking to implement the bearer
> >> spec independent of the base spec. (would be interested if anyone
> >> does know of an implementation)
> >
> 
> --
> Mark Nottingham
> http://www.mnot.net/
> 
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Apr 2012 14:11:08 -0700

On 18/04/2012, at 1:49 PM, Dick Hardt wrote:
> 
> Mark:
> 
> Would you point me to where this is bad practice as opposed to bad web architecture?

What are you looking for here?

> This is the only way to pass the parameter if doing JSONP -- there is no access to the headers. 
> 
> Many sites with substantial security expertise (Google, Facebook, LinkedIn, Foursquare) have chosen to use the query parameter as opposed to the header - both methods have been documented in the drafts since the beginning. Clearly from a practical point of view the implementors have chosen to use the query parameter. 
> 
> When I use the term hack, I am referring to people building things independent of specs because they are needing unspecified functionality. I am not talking about some hackers.
> 
> Having been building systems for some time, I fully appreciate the long term issues with name spaces, and having a query parameter is not the ideal solution, but given where the world is now, using a query parameter is what everyone is choosing -- and I have yet to hear a good reason why it is a bad solution -- and there is no known alternative to working with JSONP.
> 
> All the OAuth 2 deployments I have seen have been to fresh URLs where name collision with oath_token is a non issue. Calling it the parameter "token" would clearly be less than ideal, and lead to the issues that JSONP has with "callback"
> 
> Reserved words is one of those nasty gotchas that many languages have, that have been solved by prefix hacks such as leading underscores etc. or leading 'x-'

I understand all of that. This thread has been about the difference between documenting this kind of practice as a necessarily ~evil and recommending it (with the voice of the IETF).

> 
> -- Dick
> 
> On Apr 18, 2012, at 1:00 PM, Eran Hammer wrote:
> 

--
Mark Nottingham
http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Apr 2012 14:42:48 -0700

On 18/04/2012, at 2:33 PM, Dick Hardt <[email-masked]> wrote:

> 
> I have have read people proposing dropping it from the spec or pushing it to an Appendix. I agree the that the security issues need to be documented and the architectural issues called out. I think dropping it form the spec or pushing it to an appendix is a disservice to implementors and sends a message that the IETF is not in touch with the realities of the web.

I'm not sure why an appendix or separate document is a problem, but the heart of the current discussion is the language we put around it, not where it lives.

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Apr 2012 10:15:18 -0700

A useful distinction that I had not previously understood, thanks.

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Apr 2012 10:26:04 -0700

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Apr 2012 13:49:21 -0700

Eran:
For most JSONP frameworks, the callback query parameter is magically inserted, so it is not obvious to developers -> I agree it is a potential gotcha for developers. 

For OAuth the same could be true if using a library to insert the oauth_token query parameter that might conflict with an oauth_query parameter created by the developer. Much less likely given it is prefixed with "oath_". In JSONP, using "jsonp_callback" would have reduced the potential query name conflict.

Mark:

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Apr 2012 14:33:12 -0700

From your comment:

> AIUI that method has been identified as not good practice for entirely practical reasons, independent of the architectural reasons.

I looked through the thread and there was discussion comment about the security issue of the token being part of the URL and being in logs, caches etc. 

I was looking for the list or discussion or whatever where this method had been identified this as not a good practice. I apologize if it is somewhere obvious that I did not find. It would be a good basis for documentation per below.

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Apr 2012 14:51:59 -0700

> I'm not sure why an appendix or separate document is a problem, but the heart of the current discussion is the language we put around it, not where it lives.

Ease of understanding the RFC for implementers. Having the core spec and the bearer spec separate is already a speed bump. Harder to understand specifications are harder to implement correctly. Putting it in an appendix means people will likely miss it, and be confused when the widely available examples they see have a query parameter. Does that answer your question on "why"?

-- Dick