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
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
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
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 oauth.net website <http://oauth.net>.
(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
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
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 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.
(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
send info
Support Cullen's discuss.