Mike Asks Joe If He Could Count the Money in His Bank, PNC

Here is the OAuth story:

Mike asks Joe if he could count the money in his bank, PNC.

Terminology is not that standard for what to call the 3 parties, so I'll choose my own.

Mike is a user - he is sitting at a computer. It is his money in PNC.

Joe is a service provider. He will count people's money

PNC is a resource provider.

So starting over...

At some point, Joe contacted PNC and requests

PNC knows that Joe is someone who counts money. Joe pre-registered in the past.

1) Mike ask Joe if he could count the money in PNC

2) Joe alerts PNC that he is to count money for a client.

3) PNC gives mike a keyword "feather" and tells Joe to have his client come to the office to give permission for Joe to count his money. "Feather" is the "request token".

4) Joe responds to Mike's request in (1), saying to go to the bank and tell them "feather" (a URL redirection with the request token in the URL), and when he is done with the bank, then call him at a special number (i.e. a separate callback URL)

5) Mike goes to the bank, and says he wants to give permission for Joe to access his money, and says the keyword "feather". He also includes Joe's special number. This is only so that PNC can remind him of the special number later when it is time to talk to Joe again.

6) PNC asks Mike to give evidence that he is Mike

7) Mike shows his picture ID (i..e. ID and password)

8) PNC authenticates Mike, and asks what kind of permissions he wants to give Joe

9) Mike says permission to count his money

10) PNC replies saying to tell Joe at his "special number", "feather"

11) Mike calls Joe's special number and says "feather" (I.e. uses the callback URL and passes the request token. At this point it is an authorized request token since Mike has gone through the authentication process.)

12) Joe contacts PNC and says "feather" again.

13) PNC sends back "tomato" which Joe is to use for all future accesses to Mike's account. (Tomato is the access token)

14+) Whenever Joe wants to access PNC to get and count Mike's money, he uses "tomato". This will work until Mike contacts PNC and tells them to revoke Joe's use of "tomato".

There are a lot of decent resources:

The google/Youtube one I sent yesterday

http://hueniverse.com/oauth/

http://drupal.org/node/349516

Now the next interesting trick is to implement this without any hashing, signing, and encryption so they just get this "three-legged protocol".

Perhaps

- We do PNC, they do Mike and Joe

- We assign teams of two. One does PNC, the other does Mike and Joe

- We assign teams of three. PNC, Mike, Joe

Is there a state machine involved?

There could be in all 3 players, no? It is possible to do without, but more robust would be for all to have a state machine to check that the request they are getting makes sense relative to what is happened in the past. Also, we can impose the ability to recover from things going wrong (perhaps without starting completely over).

I've played with simple ideas of doing a simple AOuth-like protocol, without hashes, signatures, and encryption. But even without that, it is a very complex problem which doesn't seem like a good idea at this time.

For example, the resource manager requires the functionality to:

- register a user/password

- login

+ add a resource

- login and give permission for a domain to have access to the resource

+ return the resource token and the URL of the granted-access method of the service manager

- give a resource token when requested

- when presented with a resource token, after having that token authenticated, return an access token

The service manager has to:

- receive the request from the user to access the user's resource in the resource manager

+ contact the resource manager to get a request token

+ return a URL with the request token and a redirect to the login-for-permission function of the resource manager

- receive the granted-access token

+ contact the resource manager with the authenticated request token, and get an access token

+ store the access token

- receive request to get resource from the resource manager, and return to user.

This might not look too daunting, so I started hacking it out. Then I ran into a problem of where to store persistent data for the resource manager. As a kluge, I thought I could use instance variables in the servlet, but then that would require only having one servlet. And I had started planning out several: registerUser, updateResource, login, logout, etc. And I don't want to further kluge-it by having only one servlet and all these as some sort of "method" in that servlet.