On Wed, Jan 13, 2010 at 10:05 PM, Eran Hammer-Lahav <[email protected]> wrote: > Authentication Open Question #3: Should require using TLS/SSL/secure channel > for any request made without a signature?
Yes. Either TLS/SSL should be used or their should be an appropriate signature. I'll leave "secure channel" for others to define and argue about. ;) > WRAP got a lot of attention (mostly negative) to how it sends requests > without using signatures or a secure channel. WRAP only uses HTTPS for > obtaining tokens but does not mandate (or even suggests) using HTTPS for > making protected resources requests. Instead, WRAP recommends short lived > tokens that must be refreshed (using HTTPS). Speaking as an implementor (Facebook hat) we always saw WRAP as using HTTPS for making protected resources requests. Every protocol drawing we've drawn includes HTTPS on this step. We can see offering some APIs which work entirely with public data over HTTP, but in that case the access token would be a poor choice and really just acts as a consumer key for logging purposes. That said, the JavaScript profile has very different security characteristics than the other profiles when it comes to acquiring an access token. Access tokens acquired via this profile will be short lived and have more restricted scopes than those acquired via other (more secure) profiles. > In a recent thread [1] on this list we reach (very small) consensus that the > OAuth 1.0 protocol should mandate HTTPS for the PLAINTEXT method. The > community edition only recommends it. > > QUESTIONS: Are there any valid (such that will pass IETF security review > scrutiny) reasons for allowing unsigned requests to be sent in the clear > over an insecure channel? Are there use cases for this (regardless of their > security properties)? > > EHL > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00951.html > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
