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

[Aaron Stone <[e-mail]>]

Hi Hannes and WG,

The middle paragraphs are pretty choppy and unclear to me. I think I get
what's going on well enough not to complain (that is, "The Charter Looks
Good Enough To Me (TM)"), but below are some suggested changes to clarify.

Cheers,
Aaron


On Tue, 17 Feb 2009 11:35:17 +0200, "Tschofenig, Hannes (NSN - FI/Espoo)"
<[e-mail]> wrote:
> Btw, I should also indicate a deadline for providing comments. 
> 
> Please have your comments in no later than February 27th. 
> 
> Thanks. 

[snip]
>>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:

Here we start with the OAuth I-D...

Suggested replacement text: "The Working Group will produce one or more
documents suitable for consideration as Proposed Standard. The Working
Group will begin with the independently published OAuth 1.0 specification,
and 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 

What are "available extension points" ?

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

...here we talk about OAuth 1.0. What's the difference from the OAuth I-D
in the previous paragraph?

Suggested replacement paragraph: "As best as possible, the Working Group
will produce a specification that is a backwards compatible profile of
OAuth 1.0, i.e. an OAuth 1.0 implementation and the specification(s)
produced by this group will support a basic set of features to assure
interoperability. The Working Group will also consider existing OAuth 1.0
extensions for interoperability with the updated specification(s)."

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

s/ it / the Working Group /

For me, "In doing so" refers to signature methods and applicability of
signature methods to protocols other than HTTP. Is that correct? If not,
let's replace "In doing so" with what we'd be so doing ;)

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

[cut]