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

[John Kemp <john at jkemp.net>]

On Oct 6, 2009, at 5:36 PM, Eran Hammer-Lahav wrote:

> How do people feel about defining two (syntactically identical)

What do you mean "syntactically identical"?

> schemes: Delegated and Direct.

I like this idea.

> Both will use the same method(s) of making authenticated requests

As in the same set of signing mechanisms can be used in either case?

> but Direct will mean use a username and password while Delegated  
> will mean use a token obtained from a delegation endpoint.

This sounds good to me.

- johnk

> Of course the other obvious option is to define a single scheme  
> Token and add a parameter but that is ugly.
>
> EHL
>
> From: John Panzer [mailto:jpanzer at google.com]
> Sent: Tuesday, October 06, 2009 2:21 PM
> To: Brian Eaton
> Cc: Eran Hammer-Lahav; oauth at ietf.org
> Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token
>
> I agree with beaton, but I have another argument against Basic  
> auth.  Unmodified client code and UIs will assume we're talking  
> about regular username and password and use that terminology (and a  
> separate realm would just confuse things).  If they're modified to  
> be OAuth aware this could be fixed, but if you assume OAuth aware  
> code you can use a new auth scheme just as easily.  And, it would be  
> less confusing.
>
> --
> John Panzer / Google
> jpanzer at google.com / abstractioneer.org / @jpanzer
>
>
>
> On Mon, Oct 5, 2009 at 11:48 AM, Brian Eaton <beaton at google.com>  
> wrote:
> 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. ***
>
> Eran points out that I've posted several times to this thread without
> actually answering the question he asked.  =)
>
> I don't think we should use basic auth to send tokens.  I'd rather see
> us use a new auth scheme.
>
> - basic auth has existing semantics for "realm".  They aren't the same
> semantics we need for OAuth.
> - using the basic auth scheme would cripple our ability to add new
> signature methods.
>
> It is in theory possible to treat a token as a username and a token
> secret as a password, but I don't think it would be a particularly
> useful thing to do.  If we want to use bearer tokens, we should just
> drop the token secret altogether.
>
> Cheers,
> Brian
> _______________________________________________
> OAuth mailing list
> OAuth at ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth at ietf.org
> https://www.ietf.org/mailman/listinfo/oauth