Application Secrets vs. Key Pairs

I was just reading about the new Google Storage API for US developers and I am wondering why we see application secrets so often?

Google is generating an application-id / "access key" and up to five application secrets for different projects a developer is working on. Fine. The developer has to sign each request to the storage API.
http://code.google.com/apis/storage/docs/getting-started.html#keys

I assume that Google might even generate code snippets for a given pair of access key and application secret to sign requests to make things really easy for the developer.

Does nobody fear that Google admins might misuse the developer credentials?
Does nobody fear that Google's database of developer credentials might be breached one day?

What is so hard in using key pairs for developers? I know that some people faint when you use the three letter word "RSA" or "DSA" or whatever smells like asymmetric crypto. But if I have to sign a request anyway then where is the difference between symmetric and asymmetric? Is performance really still an issue? gmail is now SSL which is good. So here security finally won.

Generating a keypair is really simple and using it to sign bytes is as simple as using a symmetric key. Yes you have to protect the private key but not more than you have to protect the symmetric key.

It is harder to autogenerate code snippets because the generator does not know the private key or how to access it. But is this the point?

With asymmetric crypto there is no database of keys that can be stolen because the private key is not on a central system. And the developer credentials can not abused by Google operators which is good for audits and Google's liability.

So why are symmetric keys so ubiquitous? They are nothing than passwords and share some of the problems passwords have.

oauth 2.0 scope is the new black

David's openid connect proposal uses oauth2.0 to get an access token to access the user's info API.
Openid connect does not define a new flow for oauth but uses a scope with value "openid" to signify that this kind of access token is requested.

What I am missing here is that there is no way for the client to specify which of the user's information it wants to access. The users might choose to release only a subset of their information at oauth-approval-time but they have no way to know what the client is requesting. I fear that the authorization server suggests to give away all user data and that the user will grant that access.

A quote from the openid connect proposal: "The (user info) server is free to add additional data to this response (such as Portable Contacts) so long as they do not change the reserved OpenID Connect keys."

This is the Facebook notion of privacy to give everything away by default.
I don't like that.

Even if the client does not want the data it now has access to it.

I am intentionally not suggesting a different proposal or new values for scope. But what I am thinking about here is probably obvious given the background I am coming from.