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
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, yo
That looks fine to me.
On Apr 8, 2010, at 2:06 AM, Eran Hammer-Lahav wrote:
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 sendi
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:
Usi
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
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. P
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 utiliz
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 s
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
On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav
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 an
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 wr
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 su
> Allen Tom
> Sent: Tuesday, April 06, 2010 11:27 AM
> To: oauth@ietf.org
> 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
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 s
On Tue, Apr 6, 2010 at 12:39 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi Blaine,
>
> 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
++
Igor
Torsten Lodderstedt wrote:
Hi Blaine,
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 warn
Sent: Tuesday, April 06, 2010 11:27 AM
To: oauth@ietf.org
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
Hi Blaine,
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
I don't understand y
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 fla
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 servi
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 <
tors...
+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
On Tue, Apr 6, 2010 at 11:26 AM, Allen Tom wrote:
> 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
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
24 matches
Mail list logo
