Web 2.0 start page Netvibes released a developer preview of its new Universal Widget Architecture (UWA) today. The system combines a new widget format with small amounts of glue code that help the widget run in Google IG, Apple Dashboard, and soon Opera and standard web pages. The new universal widgets were compelling enough that I signed up for a Netvibes account after playing with it anonymously for about a year.

There is still a barrier to overcome, however, and it’s not Netvibes’ fault.The problem is that passwords are still required to bring in content from other web services. Netvibes has incredible integration — they have widgets for Gmail, Box.net, and a variety of other password-protected services — but trusting a site on the other side of the ocean with the password to my primary e-mail account seems foolhardy.

The solution to this is obvious: sites providing APIs need to issue throwaway keys to consumers of their web services. The concept of a “developer” or “API” key is central to many of the most popular APIs available today, but these can be just as vulnerable as handing over your authentication information, because they typically grant full read/write access to your data.

Instead, you should be able to visit a panel where you can control which services have access to your data, as well as fine-grained control of what forms of access they should have. This should transparently generate a temporary API key which gets delivered to the requesting service. Unlike existing services, each consumer would get its own key, making it trivial to revoke access to a particular application without affecting other clients.

This is not a novel idea; it’s obvious enough that Alex Bosworth and I independently developed essentially the exact same solution.

At the minimum, I’d like to see the following rights assignable and revokable on a per-service basis:

• List records
• Modify record metadata (categories, tags, sharing settings, etc.)
• Read contents from record
• Create new record
• Modify existing record
• Delete existing record

For Gmail, records would clearly be mail messages; other web services will have different opinions about what constitutes a record.

This sort of additional control shouldn’t add too much difficulty to an existing public API. I can’t imagine why it hasn’t been done more frequently, unless current providers are intentionally trying to cripple their services.

It couldn’t be that, though. That wouldn’t be in the spirit of openness.