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
