The OAuth 1.0 Protocol
RFC 5849
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
10 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2015-10-14
|
10 | (System) | Notify list changed from eran@hueniverse.com, stpeter@stpeter.im, romeda@gmail.com, draft-hammer-oauth@ietf.org to romeda@gmail.com, stpeter@stpeter.im |
|
2015-04-06
|
Naveen Khan | Posted related IPR disclosure: Kirsten Aldrich's Statement about IPR related to RFC 5849 | |
|
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-04-21
|
10 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2010-04-21
|
10 | Amy Vezza | [Note]: 'RFC 5849' added by Amy Vezza |
|
2010-04-20
|
10 | (System) | RFC published |
|
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 <http://oauth.net>. |
|
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 |