On Sun, Oct 11, 2009 at 5:05 AM, Blaine Cook <romeda at gmail.com> wrote: > 2009/10/6 Eran Hammer-Lahav <eran at hueniverse.com>: >> There are three well-defined methods for obtaining a token: >> >> Many large providers I talked to would like to have #1 to get rid of the temporary credentials (request token). The vast majority of the temporary credentials are never used and waste resources. The 3-steps flow was created to address clients which are unable to receive redirections and therefore have no way to get the token back from the server. > > The wasted resources argument is a red herring. I'd like to see some > math supporting that argument, because frankly, in a world where > Google can afford to scan and host 10 million books using 10 MP > digital photos (that's ca. 1 billion 16 MB files), they (and Yahoo) > can (easily) afford to store a few million tokens. These tokens can be > safely expired within an hour. I have to agree with Blaine about the wasted resources issue. However anything that can be done to simplifying the process for developers without infringing on security is a step up. People are unfortunately still very confused about the 3 step process. So I would not mind this as the default implementation, but I'd probably still want the 3 step for when its a better fit. I am also completely against the username password approach. This goes completely against what OAuth is about. >> - Should we require use of HTTPS for token requests? > > It should remain as-is, a SHOULD, but those sites that cannot / will > not support HTTPS obviously need a way to use OAuth. I do prefer https, but as Blaine says we should leave it in. It would be a good idea to create an official list of best practices separate from the official standard. >> - How should a PK option work? What should be signed? How should it work over a secure channel? > > As far as I'm concerned, the fact that the PK option doesn't involve > signing the token secret was an oversight and should be corrected to > be the same as the HMAC-SHA1 flow. Agreed. How though. Adding it to the SBS? Doing a hmac signature first (- consumer secret) and then signing that with the key? BTW. Here is an interesting thread on the Twitter Dev list showing some of the issues developers perceive rightly or wrongly about OAuth: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/c4a8637359b25683 P -- http://agree2.com - Reach Agreement! http://extraeagle.com - Solutions for the electronic Extra Legal world http://stakeventures.com - Bootstrapping blog
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.