Re: [oauth] Charter Proposal v2

[Stephen Farrell <[e-mail]>]

Hi Hannes,

That's pretty good. A bunch of nits below.

Stephen.

Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Based on the feedback I have updated the charter text proposal
> 
> ----------
> 
> Open Authentication Protocol (oauth)
> 
> Last Modified: 2009-01-30
> 
> Chair(s):
> 
> TBD
> 
> Applications Area Director(s):
> 
> Chris Newman <[e-mail]>
> Lisa Dusseault <[e-mail]> 
> 
> 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

s/without/without necessarily/ esp. wrt identity, which may be
apparent from the URLs or lower-layer addresses involved.

> 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 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:

I think referring by name to draft-hammer-oauth would be better
there, so folks on the IETF list can more easily check it out later.

>   * Align OAuth with the Internet and Web architectures, best practices
> and terminology

Hmmm...that's very open-ended. I'd fear that this leaves a WG open to
people constantly carping that such-and-such isn't best practice.

Minimally, I think there is work on the terminology needed, but
I'm not sure what else you had in mind here. I'd suggest deleting
this bullet and adding one along the lines of:

   * Improve the terminology used

>   * Assure good security practice, or document gaps in its capabilities

s/Assure/Embody/ as-is, it claims we'll make sure that running
systems are "secure" which we can't do

>   * 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

s/It seems desirable to/The WG will/

I think there was a clear consensus on that at the BoF.

> 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

I'd argue to delete the last bullet above since that's implicit
in all IETF WGs and if specifically called out is yet another
place where people could quibble endlessly.

> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>