I agree it's not a huge deal, and people will probably realize that they don't have to store the verification code, but just to engage in some late-hour nit-picking: You don't have to calculate the verification code (i.e. signature) from the request token in order to verify it. Not all signature verification schemes take the signed message, calculate the legitimate signature, and then compare that to the supplied signature [1]. Generally, a signature verification scheme simply assumes that you input the signed message and the signature, and get Yes or No as the output. Dirk.
[1] For example, if you used DSA as the signature scheme, every time you run it, you get a different signature on the same message - so that calculate-signature-then-test-for-equality-with-supplied-signature method wouldn't work there. On Tue, May 5, 2009 at 11:37 PM, Eran Hammer-Lahav <[email protected]>wrote: > 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]> > 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]> wrote: > > > > On Tue, May 5, 2009 at 1:20 PM, Eran Hammer-Lahav <[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 -~----------~----~----~----~------~----~------~--~---
