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

How do people feel about defining two (syntactically identical) schemes: Delegated and Direct.

Both will use the same method(s) of making authenticated requests but Direct will mean use a username and password while Delegated will mean use a token obtained from a delegation endpoint.

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