Section 6.3.2: "The verification code received from the Consumer is identical to the verification code provided to the User via the redirection or manually."
I'm not sure this is the right way to describe what the SP needs to do. When they redirect the User back to the Consumer in step 6.2.3, they presumably - remember that the request toke is bound to the User - associate the verifier with the request token (which implicitly associates it with the Consumer) Then, in step 6.3.2, they get a request token and a verifier from the Consumer. What does it mean, at this point, to verify that the "verification code is identical" to the one handed out to "the User"? Shouldn't this rather say something like "The verification code received from the Consumer is identical to the verification code associated with the request token in step 6.2.3". Or even better: "The verification code received from the consumer matches the request token" - because an SP can implement this in a way where it's ok to "forget" what verifier they handed out to the User. For example, the verifier could be a signature on the request token. If it's implemented that way, the SP doesn't need to remember what verifier they handed out to which user, so language requiring an equality check doesn't make sense. Dirk. On Thu, Apr 30, 2009 at 12:25 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote: > > Please review: > > > http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core-1_0a.html > > I did my best to keep the changes to a bare minimum and to avoid any > editorial changes to make comparison trivial: > > > http://code.google.com/p/oauth/source/diff?spec=svn992&old=991&r=992&format=unidiff&path=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml > > Some notes: > > 1. This is not ready for code! Please wait for a second draft before you > start making changes to libraries or your implementations. Given the small > scope of this change, I think it will be stable in the next draft. > > 2. Since this change is small, I would like to give it a short review > period before another draft. Please submit all your comments by May 8th. > > 3. This draft is missing a few new Security Consideration sections. It will > be added in the next draft but might be shared earlier on the list. > > 4. This revision does not change the value of the oauth_version parameter > which remains '1.0'. The reason for that is that the version has nothing to > do with the authorization workflow. It is specific to the signature methods > and parameter delivery methods. Telling the difference between the two > revisions is very simple: look for an oauth_callback parameter in the > Request Token step. > > 5. The reason why the oauth_callback parameter is now required with a 'oob' > value for manual entry is because the presence of the oauth_callback > parameter in the first step is the only indication which flow is being used. > Since some platforms have problem with empty parameters (they are dropped or > not sent on the wire), I decided to try and define a non-URL value (also > made the URL absolute). > > NOTE: Do no suggest ANY editorial changes that are not specific to the > changed sections. This is NOT an opportunity to improve the specification. > If you want to improve the specification in general, please provider > feedback to the Editor's Cut version. > > Tomorrow, I will post an updated Editor's Cut version as well as an update > to the IETF draft to include these changes. > > 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 -~----------~----~----~----~------~----~------~--~---
