The OAuth 1.0 Protocol
RFC 5849

Note: This ballot was opened for revision 10 and is now closed.

(Lisa Dusseault) Yes

(Ron Bonica) No Objection

Lars Eggert No Objection

Comment (2009-12-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Is there a reason we're not publishing this as PS?

(Adrian Farrel) No Objection

Comment (2009-12-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Russ Housley) (was Discuss) No Objection

Comment (2009-12-02)
No email
send info
  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 website <>.

(Cullen Jennings) (was Discuss) No Objection

(Alexey Melnikov) No Objection

Comment (2009-12-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2009-12-02)
No email
send info
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

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.

(Dan Romascanu) (was Discuss) No Objection

(Robert Sparks) No Objection

Comment (2009-12-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Support Cullen's discuss.

(Magnus Westerlund) No Objection