On Tue, May 5, 2009 at 11:32 PM, Dirk Balfanz <dirk.balf...@gmail.com>wrote:
> > > On Tue, May 5, 2009 at 2:27 PM, Eran Hammer-Lahav <e...@hueniverse.com>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. > Just to be sure - we shouldn't prescribe that implementation (signature checking) in the spec either - just like we shouldn't prescribe the string-storing-and-equality-check implementation. Dirk. > > Dirk. > > >> >> What other flow do you have in mind? >> >> EHL >> >> >> >> On 5/5/09 2:04 PM, "Dirk Balfanz" <dirk.balf...@gmail.com> wrote: >> >> >> >> On Tue, May 5, 2009 at 1:20 PM, Eran Hammer-Lahav <e...@hueniverse.com> >> 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
