On Tue, May 5, 2009 at 11:49 PM, Eran Hammer-Lahav <[email protected]>wrote:
> Can you live with the current language or do you still want to see it > change? > > Well I think the language is broken, but in the grand scheme of things I think I'll live. Dirk. > > > EHL > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Dirk Balfanz > *Sent:* Tuesday, May 05, 2009 11:48 PM > > *To:* [email protected] > *Subject:* [oauth] Re: OAuth Core 1.0 Rev A, Draft 2 > > > > 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 -~----------~----~----~----~------~----~------~--~---
