OpenID?

Here's a wacky idea I just had.

So a big problem around Services/Clients is that you can't do automated stuff because that requires the client site (whether using Clients or not) to store the username and crucially the password in its database for the Services site.

The crypt blowfish module tries to solve this problem, but IIRC it has problems of its own.

My wacky idea is this: why not use OpenID? After all, this solves the same problem, in that if I use my Google ID to log into site foo.com, foo.com never sees my Google password.

What you'd need, I presume, is this:

- the Clients site is an OpenID provider
- the Services site has OpenID enabled, and an OpenID login service, which is set up to consider the Clients site to be a valid provider. This is perhaps analogous to how in Services you currently give a domain for the API key.
- when the Client logs into the Service site, it calls the OpenID login service with the same credentials that a human user gives the OpenID login form, that is, the URL to an OpenID provider, which is in fact *itself*.
- the Services site makes the appropriate request to the Clients site
- hmm here's the potentially wacky part: how does the Clients site know that what it's now getting is part of the chain of events it initiated, and not some random attempt at hacking? I don't know enough about OpenID to answer that. Though on reflection, does it actually matter? The Client site is never giving away access to itself.
- the Clients site confirms itself with the Services site, the same way that Google returns me to foo.com and foo.com logs me in.

So, doable, or total crack? ;)