I'm probably confusing concepts, but I've been discussing on the web2py Google Group that they should implement digest-authentication.
With OAuth2, I'm thinking that the auth-key should be hashed and only sent within an authentication realm.
If it makes a difference, I'm using JavaScript client-side, interfaces are exposed with JSONRPC server-side, and OAuth2 is done with Facebook.
Should I negotiate OAuth2 inside a digest realm?
You are confusing things - there's no notion of digest realm in OAuth. There's also no such thing as an 'auth-key'. What you have is an auth-token, which represents a claim that you have been issued by a user/entity.
Since the token represents the [client_id, user, scope, expiration] tuple, it can not be used to produce a hash as that hash would be useless - the Resource Server cannot hash every possible combination in order to find the match.
If you want transport security, simply require SSL (not accounting for MiTM-attacks with valid certs and so on).
That said, protecting the credentials (the token) using a digest is pretty useless when the attacker is already in a position to intercept your traffic...
Also, to add something to the story behind OAuth2 - the reason it is so simple (relying on SSL for protection) is that this is something that is manageable by pretty much everyone.
The more complex something is, the higher the odds of something going wrong.