It's going to be interesting to see how all this plays out as the shiny, happy API days fade.

Trust is the issue though. The big networks (MySpace, FB), and the ones with high profiles (LinkedIn, Twitter) will see this problem get really bad, really fast, if they don't act quickly.

Google is another ID vendor that needs to get its act together quickly; their OpenID support isn't moving fast enough.

This is one area where enterprise pwns consumer web.

Some of the things they call for is a national online authentication system either public or private and companies who don't comply will have to assume a higher level of risk (i.e. be charged more for transactions) online.

One of the best demos I've seen for OpenID had a one time use SMS message tied to authenticating a new account. The use case was that you could use your username and password over and over again for sites you've authenticated to in the past, but as soon as you try and authenticate to a new site they sent a text message to your phone with a unique password to make sure it was you. They also profiled where you logged in from i.e. an OSX machine through Firefox in Portland between 7am and 12pm. When you fell outside your normal range through a configurable set of factors it would send you a one time use password again to authenticate that new machine / profile to your account.

They also gave you other less secure means if you didn't have a cell, or it was dead that you could use to override the system. Really cool stuff.

(OK, enough IdM geekery)

I agree that OAuth helps the problem because it'll prompt me to agree to authenticate the site to use the different pieces of the API, but the average user is going to check all the boxes and not think. If I decide to be a malicious developer I already have the authorization to modify your account privs.

There has been some big discussions on the Twitter developer group about adding OAuth which they don't think will really solve the problems. As with anything security related its always a cat and mouse game and the standards are ever evolving. The next step in the process is going to be risk and pattern based profiling presenting people with secondary forms of authentication when they fall out of the box.

We all hate remembering strong passwords, but that's a start, no?

I don't think this is really a huge deal. It probably does raise a valid concern about privacy using HTTP basic authentication on an API in general, since one could use this to access the status messages of a user with a non-public timeline. If I understand OAuth (and I've had a bad week on that front), it would help with this problem because the javascript on the non-Twitter site wouldn't have access to the proper token value to access the API. However, Twitter would have to stop allowing Basic authentication for the API entirely to avoid what we see in this example and I don't see that happening in the near future.