Re: [oauth] OAUTH Charter Proposal

How is exchanging credentials equal to authentication?

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.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of George Fletcher
> Sent: Monday, February 02, 2009 5:47 AM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org
> Subject: Re: [oauth] OAUTH Charter Proposal
>
> Not wanting to start a huge debate... but within the OAuth community
> we've made the distinction between Authentication and Authorization,
> with OAuth being an API Authorization protocol and leaving
> Authentication out of scope.
>
> Is this charter planning to tackle authentication as well as
> authorization? The statement...
> > OAuth consist of:
> >   * A mechanism for exchanging a user's credentials for a token-
> secret pair
> >
> has me a little confused.  I would word this as...
>
> * A mechanism that allows a user to authorize API access via a
> token-secret pair
>
> Thanks,
> George
>
>
> Hannes Tschofenig wrote:
> > Hi all,
> >
> > After a chat with Lisa I got in touch with Eran to slightly revise
> the
> > charter text that Sam and Mark put together for the last IETF
> meeting.
> >
> > It should addresses some of the comments provided during the BOF.
> Your
> > feedback is welcome.
> >
> > Ciao
> > Hannes
> >
> > -------------------------------------
> >
> > Open Authentication Protocol (oauth)
> >
> > Last Modified: 2009-01-30
> >
> > Chair(s):
> >
> > TBD
> >
> > Applications Area Director(s):
> >
> > Chris Newman <chris.newman@sun.com>
> > Lisa Dusseault <lisa@osafoundation.org>
> >
> > Applications Area Advisor:
> >
> > TBD
> >
> > Mailing Lists:
> >
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > Description of Working Group:
> >
> > OAuth allows a user to grant a third-party Web site or application
> access to
> > their resources, without revealing their credentials, or even their
> > identity. For example, a photo-sharing site that supports OAuth would
> allow
> > its users to use a third-party printing Web site to access their
> private
> > pictures, without gaining full control of the user account.
> >
> > OAuth consist of:
> >   * A mechanism for exchanging a user's credentials for a token-
> secret pair
> > which can be used by a third party to access resources on their
> behalf
> >   * A mechanism for signing HTTP requests with the token-secret pair
> >
> > The Working Group will produce one or more documents suitable for
> > consideration as Proposed Standard, based upon the OAuth I-D, that
> will:
> >   * Align OAuth with the Internet and Web architectures, best
> practices and
> > terminology
> >   * Assure good security practice, or document gaps in its
> capabilities
> >   * Promote interoperability
> >
> > This specifically means that as a starting point for the working
> group the
> > OAuth 1.0 specification is used and the
> > available extension points are going to be utilized. It seems
> desireable to
> > profile OAuth 1.0 in a way that produces a specification that is a
> backwards
> > compatible profile, i.e. any OAUTH 1.0 and the specification produced
> by
> > this group must support a basic set of features to guarantee
> > interoperability.
> >
> > Furthermore, Oauth 1.0 defines three signature methods used to
> protect
> > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will
> work on
> > new signature methods in case the existing mechanisms do not fulfill
> the
> > security requirements. Existing signature methods will not be
> modified but
> > may be dropped as part of the backwards compatible profiling
> activity.
> >
> > In doing so, it should consider:
> >   * Implementer experience
> >   * Existing uses of OAuth
> >   * Ability to achieve broad impementation
> >   * Ability to address broader use cases than may be contemplated by
> the
> > original authors
> >   * Impact on the Internet and Web
> >
> > The Working Group is not tasked with defining a generally applicable
> HTTP
> > Authentication mechanism (i.e., browser-based "2-leg" scenerio), and
> should
> > consider this work out of scope in its discussions. However, if the
> > deliverables are able to be factored in such a way that this is a
> byproduct,
> > or such a scenario could be addressed by additional future work, the
> Working
> > Group may choose to do so.
> >
> > After delivering OAuth, the Working Group MAY consider defining
> additional
> > functions and/or extensions, for example
> > (but not limited to):
> >   * Discovery of authentication configuration
> >   * Message integrity
> >   * Recommendations regarding the structure of the token
> >
> > Goals and Milestones:
> >
> > 12/2009     Submit document(s) suitable for publication as standards-
> track
> > RFCs.
> >
> > _______________________________________________
> > oauth mailing list
> > oauth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> _______________________________________________
> oauth mailing list
> oauth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
oauth mailing list
oauth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth