Re: [oauth] OAUTH Charter Proposal

Of course you are authenticating the credentials, but the spec does not tell you how to do it. Following this logic, every spec in the world with dependency on authentication will fall under this category...

OAuth says "go get yourself authenticated and come back with something useful". The method in which the user authenticate against the Service Provider is completely out of scope. But obviously OAuth includes authentication in other areas such as authenticating tokens and potentially the identity of the Consumer and Service Provider (see Sam's review).

This continues debate regarding authz/n is silly. OAuth currently does not specify how to authenticate the end user. But it might (not likely in core) in the future, for example, if it supports structured tokens with self signing capabilities (the user can produce tokens and hand them over to the Consumer without SP involvement, but the ability to authenticate them). In this case the user technically authenticate itself via a certificate and the verification is delegated on from the Consumer to the Service Provider.

We need to separate the marketing from the technical architecture.

EHL

> -----Original Message-----
> From: Blaine Cook [mailto:romeda@gmail.com]
> Sent: Monday, February 02, 2009 8:43 AM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org
> Subject: Re: [oauth] OAUTH Charter Proposal
>
> On Mon, Feb 2, 2009 at 4:15 PM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> > How is exchanging credentials equal to authentication?
>
> By exchanging the credentials in a verifiable way (i.e., with secrets
> & signing), you're authenticating the consumer as acting on behalf of
> the user. If we weren't trying to do *authenticated* requests, then
> there wouldn't be any point in hiding (or having) secrets.
>
> > I would not want to use the term API in the charter. While this is
> the current use case, I view OAuth as part of the 2617 family, and can
> be used for any HTTP request. I do not think most people consider every
> HTTP request an API call.
>
> +1 - perhaps the more general "Interface" makes sense? I think OAuth
> is actually a bit more general than 2617, in that it's possible to use
> it across transport protocols (though in general we should be
> targeting HTTP first).
>
> b.
_______________________________________________
oauth mailing list
oauth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth