Skip to main content

The OAuth 1.0 Protocol
draft-hammer-oauth-10

Revision differences

Document history

Date Rev. By Action
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Cullen Jennings
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2010-02-17
10 (System) IANA Action state changed to No IC from In Progress
2010-02-17
10 (System) IANA Action state changed to In Progress
2010-02-17
10 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-02-17
10 Cindy Morgan IESG state changed to Approved-announcement sent
2010-02-17
10 Cindy Morgan IESG has approved the document
2010-02-17
10 Cindy Morgan Closed "Approve" ballot
2010-02-17
10 Lisa Dusseault State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lisa Dusseault
2010-02-17
10 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2010-02-17
10 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2010-02-05
10 (System) New version available: draft-hammer-oauth-10.txt
2010-02-04
09 (System) New version available: draft-hammer-oauth-09.txt
2010-01-14
10 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2010-01-06
10 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2009-12-04
10 (System) Removed from agenda for telechat - 2009-12-03
2009-12-03
10 Lisa Dusseault State Changes to IESG Evaluation::AD Followup from IESG Evaluation::Revised ID Needed by Lisa Dusseault
2009-12-03
10 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2009-12-03
08 (System) New version available: draft-hammer-oauth-08.txt
2009-12-03
10 Alexey Melnikov
[Ballot comment]
After listening Cullen arguing with Lisa I have to say that I am with Lisa here. It is more important to publish and …
[Ballot comment]
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.
2009-12-03
10 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2009-12-03
10 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2009-12-03
10 Alexey Melnikov [Ballot comment]
s/header/header field/g - to be more consistent with updated HTTPBis and email specs.
2009-12-03
10 Robert Sparks [Ballot comment]
Support Cullen's discuss.
2009-12-03
10 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-12-03
10 Dan Romascanu
[Ballot discuss]
The practice followed by other WGs in such cases has been to approve such documents as Historical and to hold publication until the …
[Ballot discuss]
The practice followed by other WGs in such cases has been to approve such documents as Historical and to hold publication until the standards track document is published. I would like to understand why is not a similar path followed in this case.
2009-12-03
10 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2009-12-02
10 Cullen Jennings
[Ballot discuss]
I don't think we have consensus to publish this. When the WG was formed, it was clear people did not want the IETF …
[Ballot discuss]
I don't think we have consensus to publish this. When the WG was formed, it was clear people did not want the IETF to rubber stamp the existing thing but that is exactly what is happen here. I would have no object to this being published as historic with a normative reference to the standards track RFC is done and marked this as obsolete by the standards track work.  Publishing this now will harm interoperability with the eventual specification the WG is working on and cause future fragmentation in the implementations and deployments. As seen in the WG, there are changes that are needed to this for the IETF to have consensus to publish it.

I also feel there are technical issues with this specification as an IETF RFC but theses do not seem to be worth discussing given my larger point.
2009-12-02
10 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2009-12-02
10 Lars Eggert [Ballot comment]
Is there a reason we're not publishing this as PS?
2009-12-02
10 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-12-02
10 Tim Polk
[Ballot comment]
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, …
[Ballot comment]
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.
2009-12-02
10 Tim Polk
[Ballot discuss]
Section 4.13 references NIST's initial response to the Wang attack on SHA-1 (specified as
[SHA-COMMENTS], which dates to August 2004), which noted that …
[Ballot discuss]
Section 4.13 references NIST's initial response to the Wang attack on SHA-1 (specified as
[SHA-COMMENTS], which dates to August 2004), which noted that SHA-1 and algorithms of
similar strength would be phased out at the end of 2010. This statement was a little rushed,
and should have noted that SHA-1 would be phased out for use in digital signatures only. A
more recent statement from NIST can be found at

    http://csrc.nist.gov/groups/ST/hash/statement.html

This statement clarifies that the attacks on SHA-1 only impact the strength of functions
requiring collision resistance, such as the digital signatures generated with SHA1, and has
no impact on HMACs.  NIST expects the "HMAC-SHA1" signature method to remain secure
for another fifteen to twenty years.

Section 4.13 should be revised to reference "RSA-SHA1" signatures, point to the current
NIST statement, and clarify that NIST wants to phase out the use of SHA-1 *in digital
signatures* by 2010. Adding a sentence that notes the "HMAC-SHA1" signature method
are not at risk would also be helpful.
2009-12-02
10 Tim Polk
[Ballot comment]
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, …
[Ballot comment]
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.
2009-12-02
10 Tim Polk
[Ballot discuss]
Section 4.13 references NIST's initial response to the Wang attack on SHA-1 (specified as
[SHA-COMMENTS], which dates to August 2004), which noted that …
[Ballot discuss]
Section 4.13 references NIST's initial response to the Wang attack on SHA-1 (specified as
[SHA-COMMENTS], which dates to August 2004), which noted that SHA-1 and algorithms of
similar strength would be phased out at the end of 2010. This statement was a little rushed,
and should have noted that SHA-1 would be phased out for use in digital signatures only. A
more recent statement from NIST can be found at

    http://csrc.nist.gov/groups/ST/hash/statement.html

This statement clarifies that the attacks on SHA-1 only impact the strength of functions
requiring collision resistance, such as the digital signatures generated with SHA1, and has
no impact on HMACs.  NIST expects the "HMAC-SHA1" signature method to remain secure
for another fifteen to twenty years.

Section 4.13 should be revised to reference "RSA-SHA1" signatures, point to the current
NIST statement, and clarify that NIST wants to phase out the use of SHA-1 *in digital
signatures" by 2010.
2009-12-02
10 Tim Polk
[Ballot comment]
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, …
[Ballot comment]
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.
2009-12-02
10 Tim Polk
[Ballot discuss]
Section 4.13 references NIST's initial response to the Wang attack on SHA-1 (specified as
[SHA-COMMENTS], which dates to August 2004), which noted that …
[Ballot discuss]
Section 4.13 references NIST's initial response to the Wang attack on SHA-1 (specified as
[SHA-COMMENTS], which dates to August 2004), which noted that SHA-1 and algorithms of
similar strength would be phased out at the end of 2010. This statement was a little rushed,
and should have noted that SHA-1 would be phased out for use in digital signatures only. A more recent statement from NIST can be found at

    http://csrc.nist.gov/groups/ST/hash/statement.html

This statement clarifies that the attacks on SHA-1 only impact the strength of functions requiring collision resistance, such as the digital signatures generated with SHA1, and has
no impact on HMACs.  NIST expects the "HMAC-SHA1" signature method to remain secure for another fifteen to twenty years.

Section 4.13 should be revised to reference "RSA-SHA1" signatures, point to the current
NIST statement, and clarify that NIST wants to phase out the use of SHA-1 *in digital
signatures" by 2010.
2009-12-02
10 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-12-02
10 Tim Polk
[Ballot comment]
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, …
[Ballot comment]
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.
2009-12-02
10 Tim Polk
[Ballot comment]
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, …
[Ballot comment]
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?
2009-12-02
10 Russ Housley
[Ballot comment]
I think it would be better to remove the URI reference [1], and say
  in the introduction:

    The resulting OAuth …
[Ballot comment]
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 .
2009-12-02
10 Russ Housley
[Ballot discuss]
Appendix A talks about "Differences from the Community Edition."
  Is there a stable reference that can be included in this Appendix?
  …
[Ballot discuss]
Appendix A talks about "Differences from the Community Edition."
  Is there a stable reference that can be included in this Appendix?
  If not, it might be good to repeat a few sentences from the
  Introduction about the origins of the "Community Edition."

  RFC 5208 has a similar history in that an original specification was
  developed outside the IETF, and then change control was given to the
  IETF for future versions.  I think the document should indicate that
  change control has been given to the IETF.  In RFC 5208, that was done
  with an IESG note.  I'm fine with other approaches too.
2009-12-02
10 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2009-12-02
10 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-12-02
10 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-12-01
10 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2009-12-01
10 Adrian Farrel
[Ballot comment]
Thank you for bringing this work for publication as an Informational
RFC, and for including the clear statement of origin and intent at …
[Ballot comment]
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.
2009-12-01
10 Adrian Farrel
[Ballot comment]
Thank you for bringing this work for publication as an Informational
RFC, and for including the clear statement of origin and intent at …
[Ballot comment]
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 Seciton 1.
2009-11-23
10 Lisa Dusseault Placed on agenda for telechat - 2009-12-03 by Lisa Dusseault
2009-11-23
10 Lisa Dusseault State Change Notice email list have been change to eran@hueniverse.com, stpeter@stpeter.im, romeda@gmail.com, draft-hammer-oauth@tools.ietf.org from eran@hueniverse.com, romeda@gmail.com, draft-hammer-oauth@tools.ietf.org
2009-11-23
10 Lisa Dusseault [Ballot Position Update] New position, Yes, has been recorded for Lisa Dusseault
2009-11-23
10 Lisa Dusseault Ballot has been issued by Lisa Dusseault
2009-11-23
10 Lisa Dusseault Created "Approve" ballot
2009-11-23
10 Lisa Dusseault State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lisa Dusseault
2009-11-23
07 (System) New version available: draft-hammer-oauth-07.txt
2009-11-20
06 (System) New version available: draft-hammer-oauth-06.txt
2009-11-16
10 Lisa Dusseault Genart review by Avshaloum Houri - resulted in new version (-04)
2009-11-16
05 (System) New version available: draft-hammer-oauth-05.txt
2009-11-15
04 (System) New version available: draft-hammer-oauth-04.txt
2009-11-06
10 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-10-16
10 Amanda Baber
IANA questions/comments:

We understand that this document does not request any IANA
actions.

Do the protocol values specified in sections 3.1 and 4.2 need a …
IANA questions/comments:

We understand that this document does not request any IANA
actions.

Do the protocol values specified in sections 3.1 and 4.2 need a
registry? What about the oauth_signature_method values mentioned
in section 3.3?
2009-10-09
10 Amy Vezza Last call sent
2009-10-09
10 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-10-09
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Hartman
2009-10-09
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Hartman
2009-10-08
10 Lisa Dusseault Last Call was requested by Lisa Dusseault
2009-10-08
10 Lisa Dusseault State Changes to Last Call Requested from Publication Requested by Lisa Dusseault
2009-10-08
10 (System) Ballot writeup text was added
2009-10-08
10 (System) Last call text was added
2009-10-08
10 (System) Ballot approval text was added
2009-09-29
10 Lisa Dusseault Draft Added by Lisa Dusseault in state Publication Requested
2009-09-22
03 (System) New version available: draft-hammer-oauth-03.txt
2009-03-23
02 (System) New version available: draft-hammer-oauth-02.txt
2009-03-09
01 (System) New version available: draft-hammer-oauth-01.txt
2008-11-11
10 Samuel Weiler Request for Early review by SECDIR Completed. Reviewer: Sam Hartman.
2008-10-21
10 Samuel Weiler Request for Early review by SECDIR is assigned to Sam Hartman
2008-10-21
10 Samuel Weiler Request for Early review by SECDIR is assigned to Sam Hartman
2008-09-30
00 (System) New version available: draft-hammer-oauth-00.txt