Subject: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

From: Allen Tom <[email-masked]>
Date: Tue, 06 Apr 2010 11:26:39 -0700

One of the biggest differences between OAuth2 and WRAP is that OAuth2
requires that Protected Resources be accessed using HTTPS if no signature is
being used. Bullet Point #2 in Section 1.2 says:

   4.  Don't allow bearer tokens without either SSL and/or signatures.
       While some providers may offer this ability, they should be out
       of spec for doing so though technically it won't break the flows.

While I personally think that requiring SSL is a fantastic idea, and it¹s
very hard for me to argue against it, however....

One of the goals for WRAP was to define a standard AuthZ interface for APIs
which matched what we currently have on the Web. WRAP protected APIs are
intended to be a replacement for screen scraping.

On the web, almost all websites implement Cookie Auth. Specifically, when
you log into a website, the browser is issued a bearer token, called a
Cookie, and the browser is able to access Protected Resources by using the
Cookie as the credential.

The WRAP access token is intended to be a direct replacement for the HTTP
Cookie. A client should be able to present its bearer token (a WRAP Access
Token or an HTTP Cookie) without having to sign the request.

While I certainly think that requiring SSL would be a huge improvement in
internet security, HTTP does not require SSL, and since WRAP was intended to
be a replacement for HTTP Cookie Auth, then OAuth2 should also not require
HTTPS.

Yes, dropping the SSL requirement isn¹t optimal, but again the intent with
WRAP was to replace HTTP Cookie auth, and it should be up to the service
provider to require HTTPS when applicable.

Allen

---

From: Evan Gilbert <[email-masked]>
Date: Tue, 6 Apr 2010 11:42:29 -0700

On Tue, Apr 6, 2010 at 11:26 AM, Allen Tom <[email-masked]> wrote:

> While I personally think that requiring SSL is a fantastic idea, and it’s
> Yes, dropping the SSL requirement isn’t optimal, but again the intent with

I tend to agree that this is a SHOULD and not a MUST. There is a wide range
of types of protected resources, and many of these resources are already
available over HTTP connections. It probably should be a choice by the
authorization endpoint whether to allow non-HTTPS access.

> Allen
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 06 Apr 2010 20:48:52 +0200

+1  for the standard should recommand HTTPS or comparable means of 
transport protection but not require it.

This requirement does not result in any benefit for the specification by 
itself (e.g. simplification). Therefore, the decision to use HTTPS or 
any other means should be up to the service providers based on its 
security considerations.
> requires that Protected Resources be accessed using HTTPS if no 
> signature is being used. Bullet Point #2 in Section 1.2 says:
>
> While I personally think that requiring SSL is a fantastic idea, and 
> it's very hard for me to argue against it, however....
>
> One of the goals for WRAP was to define a standard AuthZ interface for 
> APIs which matched what we currently have on the Web. WRAP protected 
> APIs are intended to be a replacement for screen scraping.
>
> On the web, almost all websites implement Cookie Auth. Specifically, 
> when you log into a website, the browser is issued a bearer token, 
> called a Cookie, and the browser is able to access Protected Resources 
> by using the Cookie as the credential.
>
> The WRAP access token is intended to be a direct replacement for the 
> HTTP Cookie. A client should be able to present its bearer token (a 
> WRAP Access Token or an HTTP Cookie) without having to sign the request.
>
> While I certainly think that requiring SSL would be a huge improvement 
> in internet security, HTTP does not require SSL, and since WRAP was 
> intended to be a replacement for HTTP Cookie Auth, then OAuth2 should 
> also not require HTTPS.
>
> Yes, dropping the SSL requirement isn't optimal, but again the intent 
> with WRAP was to replace HTTP Cookie auth, and it should be up to the 
> service provider to require HTTPS when applicable.
>
> Allen
>
>

---

From: Raffi Krikorian <[email-masked]>
Date: Tue, 6 Apr 2010 11:51:38 -0700

even though i was one who advocated for HTTPS for these tokens, i think i
agree it should be a SHOULD and not a MUST.  over the public internet,
twitter would require HTTPS, but inside our data center we would probably
just allow HTTP.

On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> itself (e.g. simplification). Therefore, the decision to use HTTPS or any
> other means should be up to the service providers based on its security
> considerations.
>
> [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: John Panzer <[email-masked]>
Date: Tue, 6 Apr 2010 11:54:24 -0700

My $.02:  SHOULD is okay, as long as all clients MUST support HTTPS.  E.g.,
SHOULD for service providers, MUST support for clients.

Otherwise, you will end up with clients that don't support https or don't do
it properly.  (E.g., don't bother to check certificates.)  Which hurts
security for service providers that do want SSL.

---

From: Blaine Cook <[email-masked]>
Date: Tue, 6 Apr 2010 12:04:44 -0700

My take on this is that MUSTs MAY be ignored. ;-)

To echo John's concerns here, the worst-case scenario is that client
libraries implement "no SSL present" as a gentle reminder warning with
a flag (possibly the default) to disable those HTTPS warnings. Clients
that behave in that way should be flagged as non-compliant and
publicly humiliated. If we just write SHOULD for HTTPS/secure channel
support, then those clients are acting "properly."

If WRAP is aiming to just be a replacement for Cookie auth, then why
don't we just add a redirection profile for issuing cookies? They work
now, refreshing them is built-in, etc, etc. Instead, what we're trying
to do is build something better, more secure, and more aligned with
the sorts of behaviours we see and want to encourage on the web.

b.

On 6 April 2010 11:54, John Panzer <[email-masked]> wrote:
> On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt
> <[email-masked]> wrote:
>>
>> APIs which matched what we currently have on the Web. WRAP protected APIs
>> are intended to be a replacement for screen scraping.
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 06 Apr 2010 21:39:20 +0200

Hi Blaine,
> a flag (possibly the default) to disable those HTTPS warnings. Clients
I don't understand your objections. If a resource provider decides to 
support HTTPS only, no client w/o HTTPS support can connect thus 
circumventing this policy.
> publicly humiliated.
agreed :-)
> If we just write SHOULD for HTTPS/secure channel
Why not explicitly state in the spec that HTTPS support is a MUST HAVE 
for libraries?
> the sorts of behaviours we see and want to encourage on the web.
There are a variety of deployment scenarios for OAuth2 (e.g. internet 
small/large, intranet) as well as replay countermeasures (encryption, 
short-living tokens, restricted permissions, ...). Can we really 
anticipate/consider all of them and select HTTPS as the only solution? 
Even the spec for BASIC-Authentication 
(http://www.ietf.org/rfc/rfc2617.txt) does not force a certain mean of 
transport protection. It just recommends to consider security enhancements:

---- from http://www.ietf.org/rfc/rfc2617.txt

    The Basic authentication scheme is not a secure method of user
    authentication, nor does it in any way protect the entity, which is
    transmitted in cleartext across the physical network used as the
    carrier. HTTP does not prevent additional authentication schemes and
    encryption mechanisms from being employed to increase security or the
    addition of enhancements (such as schemes to use one-time passwords)
    to Basic authentication.

    The most serious flaw in Basic authentication is that it results in
    the essentially cleartext transmission of the user's password over
    the physical network. It is this problem which Digest Authentication
    attempts to address.

    Because Basic authentication involves the cleartext transmission of
    passwords it SHOULD NOT be used (without enhancements) to protect
    sensitive or valuable information.

----
HTTPS is state of the art and should from in my opinion be the 
_recommended_ option. This leaves implementors enough freedom to use 
other security measures where neccessary/sufficient/applicable.

regards,
Torsten.
> b.
>
> On 6 April 2010 11:54, John Panzer<[email-masked]>  wrote:
>

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 6 Apr 2010 19:50:28 +0000

I'm not sure if you are coming from the user or service perspective. So if a user asks for HTTPS do you have to support HTTPS? If a service asks for HTTPS do you have to support it? Or  do you just fail?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Allen Tom
Sent: Tuesday, April 06, 2010 11:27 AM
To: [email-masked]
Subject: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

One of the biggest differences between OAuth2 and WRAP is that OAuth2 requires that Protected Resources be accessed using HTTPS if no signature is being used. Bullet Point #2 in Section 1.2 says:

While I personally think that requiring SSL is a fantastic idea, and it's very hard for me to argue against it, however....

One of the goals for WRAP was to define a standard AuthZ interface for APIs which matched what we currently have on the Web. WRAP protected APIs are intended to be a replacement for screen scraping.

On the web, almost all websites implement Cookie Auth. Specifically, when you log into a website, the browser is issued a bearer token, called a Cookie, and the browser is able to access Protected Resources by using the Cookie as the credential.

The WRAP access token is intended to be a direct replacement for the HTTP Cookie. A client should be able to present its bearer token (a WRAP Access Token or an HTTP Cookie) without having to sign the request.

While I certainly think that requiring SSL would be a huge improvement in internet security, HTTP does not require SSL, and since WRAP was intended to be a replacement for HTTP Cookie Auth, then OAuth2 should also not require HTTPS.

Yes, dropping the SSL requirement isn't optimal, but again the intent with WRAP was to replace HTTP Cookie auth, and it should be up to the service provider to require HTTPS when applicable.

Allen

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 06 Apr 2010 15:58:35 -0400

++

Igor

Torsten Lodderstedt wrote:
>>>> signature is

---

From: John Panzer <[email-masked]>
Date: Tue, 6 Apr 2010 13:26:46 -0700

> circumventing this policy.

It is possible to 'support' HTTPS but not check certificates.  Would that be
acceptable to servers supporting HTTPS only?  (No.)

> Why not explicitly state in the spec that HTTPS support is a MUST HAVE for
> libraries?

This would also mirror the existing de facto situation for web browsers, all
of which support HTTPS on demand.

> anticipate/consider all of them and select HTTPS as the only solution? Even
> the spec for BASIC-Authentication (http://www.ietf.org/rfc/rfc2617.txt)
> does not force a certain mean of transport protection. It just recommends to
> consider security enhancements:
>
> _recommended_ option. This leaves implementors enough freedom to use other
> security measures where neccessary/sufficient/applicable.
>
> regards,
> Torsten.
>
>  b.
>>
>>>> any
>>>> it’s
>>>> APIs
>>>> when
>>>> HTTP
>>>> in

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Apr 2010 14:29:10 -0700

IETF standards can do one of two things: they can set a high level of
security or they can clearly point out where they are insecure. If we do not
require HTTPS for bearer tokens, we will have to put a big disclaimer that
doing so without some other protections is insecure.

The choice is between setting a higher bar and letting those who don't use
HTTPS be called 'not in compliance', or set a low bar and put a SHOULD with
a strongly worded warning.

I strongly believe we have a responsibility to improve internet security.
The only tool we are given in this working group is calling an
implementation 'not in compliance'. Calling something insecure does not
deter developers from doing stupid things (hence the wide use of Basic auth
where it clearly must not be used per the spec). Calling something
in-compliance when it is not falls under false marketing...

At the end, you are free to deploy whatever you want. But if you are going
to deploy OAuth in an insecure way (regardless of how insecure your other
interfaces are), you don't get say it is compliant. Is anyone here naïve
enough to think that the first time such an insecure OAuth token is stolen
and abused, people will care that it was ignoring the SHOULD? The company
will say that their implementation is in compliance and move the blame on to
OAuth.

Go implement whatever you want. But the spec should set the highest
practical bar it can, and requiring HTTPS is trivial.

As a practical note, if the WG reaches consensus to drop the MUST, I would
ask the chairs to ask the security area and IESG to provide guidance whether
they would approve such document. The IESG did not approve OAuth 1.0a for
publication as an RFC until this was changed to a MUST (for PLAINTEXT) among
other comments, and that with a strong warning.

There is also an on going effort to improve cookie security. Do we really
want OAuth to become the next weakest link?

EHL

---

From: Allen Tom <[email-masked]>
Date: Tue, 06 Apr 2010 16:00:47 -0700

Hi Tony,

I¹m suggesting that the Service Provider determine whether its services are
available via HTTPS, HTTP, or both.

This is exactly how it is today. AFAIK, there are no standard interoperable
APIs that use Oauth. All (or practically all) APIs that use Oauth are
completely proprietary. For proprietary interfaces, it¹s really up to the
Service Provider to determine if their data and services are valuable enough
to justify using HTTPs.

(I personally think that everything should use HTTPS, however I don¹t think
that Service Providers should be required to implement HTTPS if they don¹t
think their proprietary API requires it)

I do hope that there are standard interoperable interfaces that are built on
top of OAuth2  however it¹s up to the authors of these interfaces to
determine whether SSL is required or not.

The issue with specifying whether the SP should require HTTPS is very
similar to the problem with specifying how the the user authenticates with
the SP.   Should the user have a strong password? Should the SP implement
CAPTCHA or other anti-password cracking mechanisms? Maybe users should have
multi-factor auth? 

I recommend that the spec does not require HTTPS  this decision is really
up to the Service Provider if they¹re providing a proprietary interface.
Future standard interfaces that are built on top of Oauth should determine
for themselves whether or not HTTPS is required.

Allen

On 4/6/10 12:50 PM, "Anthony Nadalin" <[email-masked]> wrote:

> I¹m not sure if you are coming from the user or service perspective. So if a
> user asks for HTTPS do you have to support HTTPS? If a service asks for HTTPS
> do you have to support it? Or  do you just fail?
>  
> 
> One of the biggest differences between OAuth2 and WRAP is that OAuth2 requires
> that Protected Resources be accessed using HTTPS if no signature is being
> used. Bullet Point #2 in Section 1.2 says:
> 
> While I personally think that requiring SSL is a fantastic idea, and it¹s very
> hard for me to argue against it, however....
> 
> On the web, almost all websites implement Cookie Auth. Specifically, when you
> log into a website, the browser is issued a bearer token, called a Cookie, and
> the browser is able to access Protected Resources by using the Cookie as the
> credential. 
>

---

From: Leif Johansson <[email-masked]>
Date: Wed, 07 Apr 2010 13:20:13 +0200

> want OAuth to become the next weakest link?

I emphatically agree.

I suspect that a lot of confusion on this thread is caused by confusing 
implementation requirements with deployment requirements btw.

	Cheers Leif

---

From: Richard Barnes <[email-masked]>
Date: Wed, 7 Apr 2010 10:09:12 -0400

To re-iterate and clarify Leif's second point, I would be in favor of  
making TLS:

-- REQUIRED for implementations to support (== MUST)
-- RECOMMENDED for deployments to use (== SHOULD)

This a pretty universal pattern in IETF protocols.

--Richard

On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote:

> I suspect that a lot of confusion on this thread is caused by  
> confusing implementation requirements with deployment requirements  
> btw.
>
> 	Cheers Leif

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Apr 2010 16:21:56 -0700

We are looking at this all wrong.

There are two kinds of protected resources OAuth supports:

* http://
* https://

OAuth provides two kinds of token authentication modes:

* bearer token
* token + signature

I don't know how to translate your statement below into text I can put in
the draft to answer:

When you access/serve an http:// protected resource you do what?
When you access/serve an https:// protected resource you do what?

It is not about requiring SSL for bearer token. It is about what you
can/should do when accessing an http:// resource.

EHL

---

From: Dick Hardt <[email-masked]>
Date: Wed, 7 Apr 2010 18:24:59 -0700

Eran

Richard and Lief are describing the same point we had in the past where Peter surmised the discussion that an *implementation* MUST support TLS is required for bearer tokens to be compliant, and that TLS is recommended for *deployment*

-- Dick

---

From: Richard Barnes <[email-masked]>
Date: Wed, 7 Apr 2010 21:42:40 -0400

You guys are both right: The recommendation I made before is basically  
saying that you SHOULD only use tokens without signing on HTTPS  
resources.

--Richard

On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote:

> Eran
>
> Richard and Lief are describing the same point we had in the past  
> where Peter surmised the discussion that an *implementation* MUST  
> support TLS is required for bearer tokens to be compliant, and that  
> TLS is recommended for *deployment*
>
> -- Dick
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Apr 2010 23:06:23 -0700

How about something like this:

When accessing resources using the http URI scheme, clients SHOULD NOT use and servers SHOULD NOT accept bearer token requests (unsigned requests) as such a request is equal to sending unprotected credentials in the clear. Instead, clients SHOULD obtain and utilize an access token with a matching secret by sending a signed request. Servers MUST accept signed requests for protected resources using the http URI scheme.

EHL

On 4/7/10 6:42 PM, "Richard Barnes" <[email-masked]> wrote:

--Richard

---

From: Allen Tom <[email-masked]>
Date: Thu, 08 Apr 2010 11:27:42 -0700

Using a bearer token without a signature over HTTP is not equivalent to HTTP
Basic Auth in the clear.

A bearer token is far less powerful than the user¹s password.  In most
cases, a MITM who steals the user¹s password would be able to change the
user¹s password, locking the user out his account. Passwords are not scoped
and allow full access to the user¹s account.

A bearer token (for all reasonable implementations) would never let the
holder change the user¹s password. Although we have not standardized on the
concept of scope, presumably, many implementers will issue Access Tokens
that do not grant access to the entirety of the user¹ account.

Another important difference between OAuth2 Access Tokens and HTTP Basic
Auth is that Access Tokens can have a limited lifetime, so a MITM would only
be able to hijack an Access Token for a short duration.

My recommendation is that the spec recommend that Service Providers use
HTTPS for enhanced security, however in the cases where using HTTPS is not
feasible or desirable, Services Providers should do one or more of the
following:

1. Issue access tokens that are less powerful than the user¹s password
2. Use signatures 
3. Issue access tokens with a short lifetime, and use the Refresh workflow

Allen

On 4/7/10 11:06 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

> When accessing resources using the http URI scheme, clients SHOULD NOT use and
> servers SHOULD NOT accept bearer token requests (unsigned requests) as such a
> request is equal to sending unprotected credentials in the clear. Instead,
> clients SHOULD obtain and utilize an access token with a matching secret by
> sending a signed request. Servers MUST accept signed requests for protected
> resources using the http URI scheme.
> 
> EHL
> 
>  
> 
>

---

From: John Kemp <[email-masked]>
Date: Thu, 8 Apr 2010 15:45:25 -0400

On Apr 8, 2010, at 2:27 PM, Allen Tom wrote:

> Using a bearer token without a signature over HTTP is not equivalent to HTTP Basic Auth in the clear. 

+1

> 
> A bearer token is far less powerful than the user’s password.

s/is/should be/ and I agree ;)

>  In most cases, a MITM who steals the user’s password would be able to change the user’s password, locking the user out his account. Passwords are not scoped and allow full access to the user’s account.
> 
> A bearer token (for all reasonable implementations) would never let the holder change the user’s password.

Yes, so we need security considerations that encourage "reasonable" implementations. 

> Although we have not standardized on the concept of scope, presumably, many implementers will issue Access Tokens that do not grant access to the entirety of the user’ account.

More will do it if we construct text to encourage them to do so. 

> 
> Another important difference between OAuth2 Access Tokens and HTTP Basic Auth is that Access Tokens can have a limited lifetime, so a MITM would only be able to hijack an Access Token for a short duration. 
> 
> My recommendation is that the spec recommend that Service Providers use HTTPS for enhanced security, however in the cases where using HTTPS is not feasible or desirable, Services Providers should do one or more of the following:
> 
> 	• Issue access tokens that are less powerful than the user’s password

Right, apply the principle of least authority (http://en.wikipedia.org/wiki/Principle_of_least_privilege). The scope of an issued token should be limited to that necessary to complete the requested task. 

> 	• Use signatures
> 	• Issue access tokens with a short lifetime, and use the Refresh workflow

These would be fine security considerations for the specification, if they aren't already documented in the security considerations document? 

Regards,

- johnk

---

From: Richard Barnes <[email-masked]>
Date: Thu, 8 Apr 2010 16:58:49 -0400

The scope argument doesn't really hold any water, since OAuth isn't  
defining the scope that tokens have -- authorization servers could  
issue tokens that have the same power as passwords.  Not all  
implementors are "reasonable" :)

--Richard

On Apr 8, 2010, at 2:27 PM, Allen Tom wrote:

> A bearer token is far less powerful than the user’s password.  In  
> most cases, a MITM who steals the user’s password would be able to  
> change the user’s password, locking the user out his account.  
> Passwords are not scoped and allow full access to the user’s account.
>
> A bearer token (for all reasonable implementations) would never let  
> the holder change the user’s password. Although we have not  
> standardized on the concept of scope, presumably, many implementers  
> will issue Access Tokens that do not grant access to the entirety of  
> the user’ account.
>
> Another important difference between OAuth2 Access Tokens and HTTP  
> Basic Auth is that Access Tokens can have a limited lifetime, so a  
> MITM would only be able to hijack an Access Token for a short  
> duration.
>
> My recommendation is that the spec recommend that Service Providers  
> use HTTPS for enhanced security, however in the cases where using  
> HTTPS is not feasible or desirable, Services Providers should do one  
> or more of the following:
>
>> When accessing resources using the http URI scheme, clients SHOULD  
>> NOT use and servers SHOULD NOT accept bearer token requests  
>> (unsigned requests) as such a request is equal to sending  
>> unprotected credentials in the clear. Instead, clients SHOULD  
>> obtain and utilize an access token with a matching secret by  
>> sending a signed request. Servers MUST accept signed requests for  
>> protected resources using the http URI scheme.
>>
>> EHL
>>
>>
>>
>>
>>> >> I don't know how to translate your statement below into text I  
>>> can
>>> >> put in
>>> >> the draft to answer:
>>> >>
>>> >>> To re-iterate and clarify Leif's second point, I would be in  
>>> favor
>>> >>> of
>>> >>> making TLS:
>>> >>>
>>> >>>>> As a practical note, if the WG reaches consensus to drop the  
>>> MUST,
>>> >>>>> I would
>>> >>>>> they would approve such document. The IESG did not approve  
>>> OAuth
>>> >>>>> 1.0a for
>>> >>>>> There is also an on going effort to improve cookie security.  
>>> Do we
>>> >>>>> really

---

From: Richard Barnes <[email-masked]>
Date: Thu, 8 Apr 2010 16:59:02 -0400

That looks fine to me.

On Apr 8, 2010, at 2:06 AM, Eran Hammer-Lahav wrote:

> unprotected credentials in the clear. Instead, clients SHOULD obtain  
> and utilize an access token with a matching secret by sending a  
> signed request. Servers MUST accept signed requests for protected

---

From: John Kemp <[email-masked]>
Date: Thu, 8 Apr 2010 17:20:07 -0400

On Apr 8, 2010, at 4:58 PM, Richard Barnes wrote:

> The scope argument doesn't really hold any water, since OAuth isn't defining the scope that tokens have -- authorization servers could issue tokens that have the same power as passwords.  Not all implementors are "reasonable" :)

Indeed, you can't ever stop people doing stupid things. 

But the "scope argument" (and expiration time) does certainly hold water. Bearer tokens that have appropriate limitations on usage are well-known to be useful (see one-time use, or time-limited URLs -- for confirming email subscriptions, for example). Such conditions on usage are useful irrespective of whether you believe that tokens should be sent only over SSL/TLS. 

Regards,

- johnk

>> A bearer token is far less powerful than the user’s password.  In most cases, a MITM who steals the user’s password would be able to change the user’s password, locking the user out his account. Passwords are not scoped and allow full access to the user’s account.
>> 
>> A bearer token (for all reasonable implementations) would never let the holder change the user’s password. Although we have not standardized on the concept of scope, presumably, many implementers will issue Access Tokens that do not grant access to the entirety of the user’ account.
>>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 8 Apr 2010 17:56:20 -0400

Certainly it should be recommended that bearer tokens have limited  
scope, but because the notion of "limited scope" isn't well-defined,  
you can't really say that "bearer tokens MUST have limited scope".   
When it comes to the *normative* text (i.e., the stuff in capital  
letters), we need to cover the general case, which requires the "MUST  
implement security, SHOULD use security" pattern.  Language about  
scope is complementary to this.

--Richard

On Apr 8, 2010, at 5:20 PM, John Kemp wrote:

> But the "scope argument" (and expiration time) does certainly hold  
> water. Bearer tokens that have appropriate limitations on usage are  
> well-known to be useful (see one-time use, or time-limited URLs --  
> for confirming email subscriptions, for example). Such conditions on  
> usage are useful irrespective of whether you believe that tokens  
> should be sent only over SSL/TLS.
>
> Regards,
>
> - johnk
>
>>
>> --Richard
>>
>>
>>
>>> Using a bearer token without a signature over HTTP is not  
>>> equivalent to HTTP Basic Auth in the clear.
>>>
>>> A bearer token (for all reasonable implementations) would never  
>>> let the holder change the user’s password. Although we have not  
>>> standardized on the concept of scope, presumably, many  
>>> implementers will issue Access Tokens that do not grant access to  
>>> the entirety of the user’ account.
>>>
>>> My recommendation is that the spec recommend that Service  
>>> Providers use HTTPS for enhanced security, however in the cases  
>>> where using HTTPS is not feasible or desirable, Services Providers  
>>> should do one or more of the following:
>>>
>>>> When accessing resources using the http URI scheme, clients  
>>>> SHOULD NOT use and servers SHOULD NOT accept bearer token  
>>>> requests (unsigned requests) as such a request is equal to  
>>>> sending unprotected credentials in the clear. Instead, clients  
>>>> SHOULD obtain and utilize an access token with a matching secret  
>>>> by sending a signed request. Servers MUST accept signed requests  
>>>> for protected resources using the http URI scheme.
>>>>
>>>> EHL
>>>>
>>>>
>>>>
>>>>
>>>>>>>>>> As a practical note, if the WG reaches consensus to drop  
>>>>>>>>>> the MUST,
>>>>>>>>>> I would
>>>>>>>>>> There is also an on going effort to improve cookie  
>>>>>>>>>> security. Do we
>>>>>>>>>> really