Re: [OAUTH-WG] RSA signing and web delegation

[Eran Hammer-Lahav <eran at hueniverse.com>]

What this means is that there really is just one scenario:

- Client obtains a set token credentials using some shared secret (symmetric or otherwise).
- If the resources are owned by someone other than the client, authorization must be obtained.
- Client uses the token credentials (alone) to access protected resources.

In case where there is sometimes a resource owner other than the client, the client can reuse the same shared secret for both tokens (self and resource owner). In cases where there is no resource owner other than the client (the simple client-server model), the client's shared secret (can be username/password) is used to obtain a token. 

Either way, there is always a token present and we are not attempting to directly replace the Basic auth flow.

This seems reasonable (and much easier) to me.

It does mean we need to define two sets of authentication methods, one for shared-secret based (symmetric or asymmetric) and one for token-based. We will be able to reuse some of the flow between the two, but it sounds to me like one will need to support more options (RSA) than the other (just HMAC and Plain).

Comments?

EHL


> -----Original Message-----
> From: Brian Eaton [mailto:beaton at google.com]
> Sent: Friday, November 06, 2009 1:34 PM
> To: Eran Hammer-Lahav
> Cc: John Panzer; oauth at ietf.org
> Subject: Re: [OAUTH-WG] RSA signing and web delegation
> 
> On Fri, Nov 6, 2009 at 12:16 PM, Eran Hammer-Lahav
> <eran at hueniverse.com> wrote:
> > The "Basic auth alternative" would be a single request flow with
> shared
> > secret (either symmetric or asymmetric). I am not sure how the flow
> below
> > applies (when compared to Basic auth).
> 
> I don't think a basic auth flow based on a single secret is all that
> interesting, or even possible to implement.  The problem is how you
> bootstrap the secret.
> 
> Is the secret the user's password?  That doesn't work with any
> well-designed password authentication system (See [1]).  It won't get
> deployed.
> 
> Is the secret a session cookie?  That could work, but you need an
> answer for bootstrapping the session cookie.
> 
> Is the secret an OAuth token?  That could also work, but you still
> need an answer for bootstrapping the token.
> 
> I think RSA is one of many possible answers to the bootstrapping
> problem.  Ideally we'll have a bunch of different ways to bootstrap a
> session secret, and then using the session secret will be easy.
> 
> Cheers,
> Brian
> 
> [1] http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-
> rainbow-tables-what-you-need-to-know-about-s.html