In Eran's post http://www.hueniverse.com/hueniverse/2009/03/oauth-core-10-reborn.html the unofficial OAuth Core 1.0 Editor's cut was announced which gives some really good points on different areas. My questions about timestamp and nonce regarding the draft's suggested mechanism are also on the post and now I am putting them here for further discussion.
Section 3.2 states: To avoid the need to retain an infinite number of nonce values for future checks, servers MAY choose to restrict the time period after which a request with an old timestamp is rejected. Server applying such restriction SHOULD provide a way for the client to sync its clock with the server's clock. This mechanism for syncing the client and server clock should be elaborated further. If SP chooses to transfer the timestamp to it's consumer when this timestamp diff. occurs then this communication could also be violated like a DOS attack by repeating such invalidated timestamp requests to the SP. One more thing to consider is that how do we transfer the timestamp unless we are sure that the Consumer is valid and this validity can only be made if the verification succeeds, which cannot, unless the timetamp is valid. So we have a circular dependency over here. However, I think that syncing timestamp request should work correctly in invalidated mode. I'm planning to include it in my SP implementation because we don't want to restrict our consumers to be on the same (similar) time. (Note that I'm trying to implement 1.0a along with suggestions in this draft and posts) I am exposing another call for exchanging server's time to the consumers and this call is not verified. Consumers ask for the timestamp and they can then use the synced time in further oauth calls. Please share your thoughts/feedback on this mechanism, whether there is any oversight in this or I can go ahead safely with this. Much thanks, --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
