Skip to main content

The OAuth 1.0 Protocol
draft-hammer-oauth-10

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.

Lisa Dusseault Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2009-12-01) Unknown
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 IESG member
No Objection
No Objection (2009-12-03) Unknown
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 IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection (2009-12-02) Unknown
  Is there a reason we're not publishing this as PS?
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (2009-12-03) Unknown
Support Cullen's discuss.
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2009-12-02) Unknown
  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 IESG member
(was No Record, Discuss) No Objection
No Objection (2009-12-02) Unknown
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.