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 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" <rbar...@bbn.com> wrote:
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
>
> On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote:
>
>> 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
>>
>> On 4/7/10 7:09 AM, "Richard Barnes" <rbar...@bbn.com> wrote:
>>
>>> 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:
>>>
>>>>
>>>>> 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?
>>>>
>>>> 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
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
