Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token

[Brian Eaton <beaton at google.com>]

On Sat, Oct 3, 2009 at 10:46 PM, Eran Hammer-Lahav <eran at hueniverse.com> wrote:
> *** It would be helpful if other people chime in on this topic. This is a
> critical decision we need to make regarding new schemes. One proposal
> is to have different scheme for different type of access (direct vs. delegated).
> Another is to reusing existing scheme (with a new MAC-based one) for both
> usernames and tokens, and differentiating them on the server side using the
> credential structure (token or username) and on the client side using the
> realm parameter (and the header order). Of course, there are probably other
> proposals coming. ***

Here's how I'd divvy up the work.

1) Come up with some core set of mechanisms for authenticating a
single data request.

2) Make sure that those mechanisms are extensible, so that we can add
new cryptographic tools as necessary later.

3) Define protocol flows for combining them to cover things like
two-legged OAuth to authenticate calling applications, three-legged
OAuth, OAuth with assertions about both the identity of the calling
application and the user, etc...

For example, two-legged OAuth might look like this:

- send consumer key and secret to token issuing endpoint
- get back session token
- send session token to data endpoint
- session token expires periodically, needs to be renewed

Three-legged OAuth might look like this:

- send consumer key, consumer secret, and access token to token issuing endpoint
- get back session token
- send session token to data endpoint
- session token expires periodically, needs to be renewed

When someone invents something New and Complicated, the complexity
would get pushed to the token issuing endpoint like so:

- send New and Complicated stuff to token issuing endpoint
- get back session token
- send session token to data endpoint
- session token expires periodically, needs to be renewed

Cheers,
Brian