Re: [oauth] Last Call for Comments: OAuth Charter Text

No. 'extension points' mean the spec allowing new signature methods, parameter methods, etc. The ways in which the spec allows it to be extended. Not extension proposals.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of George Fletcher
> Sent: Tuesday, February 17, 2009 9:18 AM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: oauth@ietf.org
> Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text
>
> Just to clarify... does the following quote from the charter...
>
> "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."
>
> .... mean that all extensions either checked in at oauth.pbwiki.com,
> the
> svn repository, or the
> draft-dehora-farrell-oauth-accesstoken-creds-00.txt that Stephen
> mentions will all be considered?
>
> Or will only certain extensions be considered for inclusion into the
> 1.0
> version?
>
> Thanks,
> George
>
> Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> > Hi all,
> >
> > we have now discussed the charter text for some time and we got good
> > feedback. I have tried to reflect it in an appropriate way.
> >
> > I think it is about time to finish this part of the story. Please
> review
> > the current charter text and make a judgement whether we can move
> > forward with it.
> >
> > 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 consists of:
> >   * A mechanism for exchanging a user's credentials for a token-
> secret
> > pair that 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,
> > and propose a path forward for addressing the gap.
> >   * Promote interoperability.
> >   * Provide guidelines for extensibility.
> >
> > 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. an OAuth 1.0 implementation 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 and will describe the environments where new
> > security requirements justify their usage. Existing signature methods
> > will not be modified but may be dropped as part of the backwards
> > compatible profiling activity. The applicability of existing and new
> > signature methods to protocols other than HTTP will be investigated.
> >
> > 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:
> >
> > Apr 2009    Submit 'OAuth: HTTP Authorization Delegation Protocol' as
> > working group item
> >             (draft-hammer-oauth will be used as a starting point for
> > further work.)
> > Sep 2009    Start Working Group Last Call on 'OAuth: HTTP
> Authorization
> > Delegation Protocol'
> > Sep 2009    Discusion about OAUTH extensions the group should work on
> > Nov 2009    Submit 'OAuth: HTTP Authorization Delegation Protocol' to
> > the IESG for consideration as a Proposed Standard
> > Nov 2009    Prepare milestone update to start new work within the
> scope
> > of the charter
> > _______________________________________________
> > 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