Subject: Re: [oauth] OAuth Charter Text (15th April 2009)

From: Paul Madsen <[email-masked]>
Date: Wed, 13 May 2009 09:13:24 -0400

the wording of the example below seems to imply that the photo-sharing 
site would necessarily support OAuth, but not the printing site

paul

Hannes Tschofenig wrote:
> Open Authentication Protocol (oauth)
>
> Last Modified: 2009-04-15
>
> Chair(s):
>
> TBD
>
> Applications Area Director(s):
>
> Alexey Melnikov <[email-masked]>
> Lisa Dusseault <[email-masked]> 
>
> 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
> the user's resources, without necessarily revealing the user's credentials,
> or even the user's identity. For example, a photo-sharing site that supports
> OAuth would allow its users to use a third-party printing Web site to access
> the user's 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,
> which can be used by a third party to access resources on the user's 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 that will:
>   * Improve the terminology used.
>   * Embody good security practice, or document gaps in its capabilities, and
> propose a path forward for addressing the gaps.
>   * Promote interoperability.
>   * Provide guidelines for extensibility.
>
> This specifically means that as a starting point for the working group OAuth
> 1.0 (i.e., draft-hammer-oauth-00.txt), which is a copy of the original OAuth
> specification in IETF draft format, is used and the available extension
> points are going to be utilized. In completing its work to profile OAuth 1.0
> to become OAuth 1.1, the group will strive to retain backward compatibility
> with the OAuth 1.0 specification. However, changes that are not backward
> compatible might be accepted if the group determines that the changes are
> required to meet the group's technical objectives and the group clearly
> documents the reasons for making them.
>
> 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 backward compatible profiling
> activity. The applicability of existing and new signature methods to
> protocols other than HTTP will be investigated.
>
> The Working Group should consider:
>   * Implementer experience.
>   * The end-user experience, including internationalization.
>   * Existing uses of OAuth.
>   * Ability to achieve broad implementation.
>   * Ability to address broader use cases than may be contemplated by the
> original authors.
>
> After delivering OAuth 1.1, the Working Group may consider defining
> additional functions and/or extensions, for example (but not limited to):
>  * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0.
>  * Comprehensive message integrity, e.g.,
> http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html.
>  * Recommendations regarding the structure of the token.
>  * Localization, e.g.,
> http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/2/sp
> ec.html.
>  * Session-oriented tokens, e.g.,
> http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html.
>  * Alternate token exchange profiles, e.g.,
> draft-dehora-farrell-oauth-accesstoken-creds-00.
>
> The work on extensions is within the scope of the working group charter, but
> requires consensus within the group to add new milestones. 
>
> The Working Group will also define a generally applicable HTTP
> authentication mechanism (i.e., browser-based "2-leg" scenario).
>
> 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.)
> Jul 2009    Submit a document as a working group item providing the
> functionality of the 2-legged HTTP authentication mechanism 
> Jul 2009    Start of discussion about OAuth extensions the group should work
> on
> Oct 2009    Start Working Group Last Call on 'OAuth: HTTP Authorization
> Delegation Protocol'
> Nov 2009    Submit 'OAuth: HTTP Authorization Delegation Protocol' to the
> IESG for consideration as a Proposed Standard 
> Nov 2009    Start Working Group Last Call on the 2-legged HTTP
> authentication mechanism document
> Nov 2009    Prepare milestone update to start new work within the scope of
> the charter
> Dec 2009    Submit 2-legged HTTP authentication mechanism document to the
> IESG for consideration as a Proposed Standard 
>
> _______________________________________________
> oauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: James Aylett <[email-masked]>
Date: Wed, 13 May 2009 14:59:54 +0100

> site would necessarily support OAuth, but not the printing site

That's not how I read it at all; I read it as saying that the
photo-sharing site would support OAuth to allow 3rd party sites access
to the photos, and the printing site would implement OAuth to get
that. Anything symmetric is out of scope of the example, but can
easily be imagined.

J

-- 
  James Aylett

  talktorex.co.uk - xapian.org - uncertaintydivision.org