Which my language implies. The server has to retrieve the verification code to compare it. It can do that from a database or by calculating it. I think you are reading too much into this. The draft does not prevent this kind of implementation. My first draft used something like 'the server must verify that the verification code is valid' but I think the current language is easier for developers to understand, and doesn't prevent more sophisticated implementations.
EHL From: [email protected] [mailto:[email protected]] On Behalf Of Dirk Balfanz Sent: Tuesday, May 05, 2009 11:33 PM To: [email protected] Subject: [oauth] Re: OAuth Core 1.0 Rev A, Draft 2 On Tue, May 5, 2009 at 2:27 PM, Eran Hammer-Lahav <[email protected]<mailto:[email protected]>> wrote: I'm not following. The server shows the user a string which the client has to provide back to the server. The string the server gives the user must be the same as the string the client gives back to the server. This assumes that the server remembers the string it gave to the user, so it can compare that one to the string it's receiving in Step 6.3.2. I think an easier implementation would be if the verification code was a signature on the request token (then the server doesn't have to remember the verification code). In that case, the server doesn't have two strings to compare for equality in Step 6.3.2. Instead, the SP would simply check that the verification code is a valid signature on the request token. Dirk. What other flow do you have in mind? EHL On 5/5/09 2:04 PM, "Dirk Balfanz" <[email protected]<http://[email protected]>> wrote: On Tue, May 5, 2009 at 1:20 PM, Eran Hammer-Lahav <[email protected]<http://[email protected]>> wrote: Please review: http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/2/oauth-core-1_0a.html Change log: http://code.google.com/p/oauth/source/diff?spec=svn993&old=992&r=993&format=unidiff&path=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml The changes are minimal: 1. Define 'oob' as out-of-band 2. Clarify that 'oob' is for any out-of-band configuration, not delivery of verification code 3. Minor language tweak 4. Correct reference to first step 5. Clarify that verification code should be displayed when no callback is configured, not just via the oauth_callback parameter Deadline for feedback is still May 8th. If you provided feedback to draft 1 which was not incorporated and still believe it should, please let me know. In Section 6.3.2, there is still language that assumes that the SP has two verification codes at that point: * The verification code received from the Consumer is identical to the verification code provided to the User via the redirection or manually. I believe that presupposes/dictates a particular implementation, which is not what we should be doing in the spec. Proposed change: "The verification code matches the Request Token". Dirk. If no changes are needed by Friday, I will promote this to an implementer draft at which point developers will be encouraged to change their code. If no changes are identified by developers, we will declare this draft final 5/25. EHL --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
