Would OpenID or OAuth work for authorization/authentication on a distributed web service?

We're in the early stages of designing a RESTful/resource-oriented web service API for a computational lingustics application. Because many of the resources we plan to serve are rights-encumbered, a key design decision has been to specify the platform so that each resource provider can expose their own web service that complies with the API spec. This way, the rights owner maintains control over their content (and thus the ability to throttle or deny access at will) and a direct relationship with the consumer, while still being able to participate in in the collaborative network.

At the same time, to simplify the job of writing a client for this service, we want to allow a client access to the distributed service through one end-point, with the server handling content negotiation and retrieval from the appropriate providers.

Right now, we're at an impasse on authentication/authorization schemes. One of our number has argued for the (technical) simplicity of a central au开发者_JAVA技巧thentication registry, but others are concerned about the organizational complexity of such a scheme.

It seems to me, based on an albeit limited understanding of the technologies, that a combination of OpenID and OAuth would do the trick, with a client authenticating with the end-point via OpenID, and the server taking action on the user's behalf with the various content providers using OAuth.

I've only ever seen implementations (e.g. stackoverflow, twitter, etc.) where a human was present to intervene, and I still need to do more research on these technologies.

Would a scheme like this work for an automated web service, or would it make the client too difficult to implement and operate?

OpenID does assume the user is present to drive a web browser to interact with their OpenID provider and do that initial authentication. But you could have the user authenticate to the end-point with OpenID, and there get an OAuth authorization for their client's automated use.

You should be able to do this without making the client too difficult to implement, particularly if the client is on a platform that allows it to spawn a web browser to drive that initial OpenID bit.