OAuth is simply ensuring that both parties, requester and responder has the same reference to a user, 'the current user', and they both independently may authenticate the user (out of scope of oauth). What is the added value of OAuth here is that it allows you to do backchannel requests regarding a specifc user, 'the current user', without using a privacy-invasive identifier. And as a happy coincidence, the OAuth protocol is so simple, it can be implemented in a snap.
Trust model is partly out of scope of the OAuth protocol. Although it has some very useful hooks that allows you to do what you want.
First, it has provider key/secrets, which is a way of managing 'registered' consumers, that are allowed to communicate and talk to the oauth provider. You can imagine several ways of handling this:
- Self-registration of consumers (most common).
- Self-registration, but with ack from the provider administrator.
- Provider administrator configures the trusted consumers
When you have a list of consumers, you may setup access control per consumer. In this scenario you could also let the VO admin configure which consumer that are allowed to access what data.
In addition, OAuth gives you the ability to add user consent to release of VO information, and you can also give the user options about what data the consumer may retrieve in that particular session. Including user consent is not straight forward using SAML 2.0 AttributesQueries (backchannel).
To summarize, we may define an apprioriate trust model about registration of consumers and release of VO information - and then OAuth will much likely fit with that model.