Is there a reason we're not publishing this as PS?

Thank you for bringing this work for publication as an Informational
RFC, and for including the clear statement of origin and intent at the
end of Section 1.

  I think it would be better to remove the URI reference [1], and say
  in the introduction:

    The resulting OAuth protocol was stabilized at version 1.0 in
    October 2007 and published at the oauth.net website <http://oauth.net>.

After listening Cullen arguing with Lisa I have to say that I am with Lisa here. It is more important to publish and let the WG do OAuth 2.0 as a PS.

s/header/header field/g - to be more consistent with updated HTTPBis and email specs.

Section 1, paragraph 5
s/substitute the need/make it unnecessary/

Section 1.1
suggest adding a definition for "credentials" and noting that three classes (client, temporary, 
and token) are defined for OAuth

Sections 2.1 and 2.3

In sections 2.1 and 2.3, the attribute definitions do not specify REQUIRED or OPTIONAL.  (In
Section 2.2 the definition of oauth_token explicitly notes REQUIRED, and the list of attributes 
given in 3.1 are all REQUIRED excepting oauth_version which is OPTIONAL.)

Explicitly noting REQUIRED or OPTIONAL for oauth_callback (in the request in 2.1),
oauth_token, oauth_token_secret, and oauth_callback_confirmed (in the response in 2.1) and
oauth_verifier (in 2.3) would improve the clarity.

Section 2.3 states "The token credentials issued by the server MUST reflect the exact scope,
diration, and other attributes approved by the resource owner."

I find "reflect" ambiguous.  Are you suggesting that this information should be embedded
into the credentials, or simply maintained at the server?

Section 3.3, last sentence:  "Servers applying
   such a restriction SHOULD provide a way for the client to sync its
   clock with the server's clock, which is beyond the scope of this
   specification."

What if a client is associated with multiple servers?  Given the
level of synchronization required, isn't it a sufficient for both
clients and servers to synchronize with a trusted time source
of their own choice?

Section 4.3 states:

   When used with the "PLAINTEXT" method, the protocol makes no attempt
   to protect credentials from eavesdroppers or man-in-the-middle
   attacks.  The "PLAINTEXT" method is only intended to be used in
   conjunction with a transport-layer security mechanism such as TLS or
   SSL which does provide such protection.

This one is splitting hairs, I know, but please change "does" to "can" in the second
sentence.  In the context of machine-to-machine communication, TLS/SSL *will* provide
this protection.  However, it is quite possible to implement a man-in-the-middle attack
even with TLS with the involvement of users.

Support Cullen's discuss.