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 -~----------~----~----~----~------~----~------~--~---
