OAuth WRAP is very similar to cookies as deployed by major vendors. Google has just switched to HTTPS-by-default for all GMail sessions[1], and my understanding (per [2]) is that access to authenticated sessions (i.e., full GMail or Google Docs access versus just displaying "b...@gmail.com" on the page) is always negotiated with a secure cookie. Thus, Google has made decisions internally to secure the equivalent of both the Refresh and the Bearer token, short-lived assurances aside.
We're also entering an age where we have enough computing power to *factor* RSA-1024 in non-infinite-time; handheld devices that are realistically expected to use these protocols have sufficient computing power and battery life to encrypt HTTP requests and decrypt the responses (my phone already does this for all Twitter and email requests; yours probably does, too). As such, I can't see how *not* requiring SSL for unsigned requests could pass muster at an IETF security review. [1] http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html [2] http://googleonlinesecurity.blogspot.com/2009/06/https-security-for-web-applications.html 2010/1/14 John Kemp <j...@jkemp.net>: > > On Jan 14, 2010, at 1:05 AM, Eran Hammer-Lahav wrote: > > [...] >> >> 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)? > > I am still wavering on this. > > I think that using a bearer token with short lifetime and one-time use > semantics (for example) is probably sufficient security for many use-cases. > And using TLS/SSL (or even just signing and verifying a signed request) in > all cases may provide too much performance overhead for some of those cases. > > In other words, I think that it's not only channel security we need to > consider, but a combination of other measures that would, in some cases, > obviate the need for TLS. > > Regards, > > - johnk > > _______________________________________________ > 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
