Skip to main content

The OAuth 1.0 Protocol
RFC 5849

Yes

(Lisa Dusseault)

No Objection

(Cullen Jennings)
(Dan Romascanu)
(Magnus Westerlund)
(Ron Bonica)

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

Lars Eggert No Objection

Comment (2009-12-02)
  Is there a reason we're not publishing this as PS?

(Lisa Dusseault; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (2009-12-01)
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.

(Alexey Melnikov; former steering group member) No Objection

No Objection (2009-12-03)
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.

(Cullen Jennings; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection (2009-12-03)
Support Cullen's discuss.

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2009-12-02)
  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>.

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection

No Objection (2009-12-02)
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.