[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
On Thu, May 7, 2009 at 12:45 PM, Owen Evans owenmcev...@gmail.com wrote: 2009/5/8 Dirk Balfanz dirk.balf...@gmail.com You didn't like my the verification code matches the request token language? Dirk. IMHO that implies that the verification code value has some intrinsic link to the request token value, which is presumptuous about the implementation method. I think that any implementation that doesn't have such an intrinsic link (be it as an explicit link in a database, as a signature, or perhaps as an implicit link through some other means) is broken, hence my proposed language. It might be the case that the verification code matches the user that approved the request token is good enough - it seems to prevent the session fixation attack we identified. But I thought that for good measure, we should actually require the verification code to be bound to a particular request token, not just a particular user (I don't know what can happen if we allow a user to approve two different request tokens, and then swap the verifiers he got for the two before returning to the Consumer). All we want to say is that the verification code matches the expected verification code at the SP. Without implying how the SP saves or comes about the expected verification code. That, again, assumes that there are two verification codes - the expected one, and the actual one. If the way I'm implementing this is have my verification code be the DSA signature of the request token, then there is no way for me to calculate the expected verification code (re-doing the signature on the request token will yield a different signature). All I can do is check that the actual one is kosher (b/c it matches the request token, not some expected verification code). Dirk. O --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
On Tue, May 5, 2009 at 2:27 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: 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 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=svn993old=992r=993format=unidiffpath=%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 -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
On Tue, May 5, 2009 at 11:32 PM, Dirk Balfanz dirk.balf...@gmail.comwrote: On Tue, May 5, 2009 at 2:27 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: 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=svn993old=992r=993format=unidiffpath=%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 -~--~~~~--~~--~--~---
[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 e...@hueniverse.comwrote: 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:* oauth@googlegroups.com [mailto:oa...@googlegroups.com] *On Behalf Of *Dirk Balfanz *Sent:* Tuesday, May 05, 2009 11:33 PM *To:* oauth@googlegroups.com *Subject:* [oauth] Re: OAuth Core 1.0 Rev A, Draft 2 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. 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=svn993old=992r=993format=unidiffpath=%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 -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
On Tue, May 5, 2009 at 11:49 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: 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:* oauth@googlegroups.com [mailto:oa...@googlegroups.com] *On Behalf Of *Dirk Balfanz *Sent:* Tuesday, May 05, 2009 11:48 PM *To:* oauth@googlegroups.com *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 e...@hueniverse.com 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:* oauth@googlegroups.com [mailto:oa...@googlegroups.com] *On Behalf Of *Dirk Balfanz *Sent:* Tuesday, May 05, 2009 11:33 PM *To:* oauth@googlegroups.com *Subject:* [oauth] Re: OAuth Core 1.0 Rev A, Draft 2 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. 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=svn993old=992r=993format=unidiffpath=%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 -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
On Tue, May 5, 2009 at 1:20 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: 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=svn993old=992r=993format=unidiffpath=%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 -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
On Thu, Apr 30, 2009 at 5:28 PM, Josh Roesslein jroessl...@gmail.comwrote: Dirk, I see now what you are getting at. Yes I guess the SP could use a signature to generate the verifier, so it would not need to persist it. As long as the signature secrete changes ever so often, I don't think an attacker could compromise this method. But to me the wording of that section still doesn't state how the SP can verify the verifier. Well, the wording as it is now mentions two verification codes, and says that the SP MUST make sure that they are identical. That looks like a prescription for implementation to me. And not an implementation that I would choose :-) Dirk. Using the signature approach still does the same thing, makes sure the verifier matches. It might be a good idea to suggest this signature approach in the spec as an implementation tip. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
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.comwrote: 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=svn992old=991r=992format=unidiffpath=%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 -~--~~~~--~~--~--~---
[oauth] Re: http://apiwiki.twitter.com/Sign-in-with-Twitter
Is this Sign-in-with-Twitter supposed to be to sign into other sites using your twitter account, as in sign into myhealthrecord.com using your twitter account? I don't think that's secure - OAuth is not an authentication protocol. Dirk. On Thu, Apr 16, 2009 at 5:15 PM, Ben Clemens bclem...@currentmedia.comwrote: The nascar situation is akin to the difficulty in handling share (digg/facebook/email/myspace/buzz/etc/etc) options for content. Everyone has it on content pages, but it’s almost impossible to guess which subset of sharing sites you can show without overwhelming people (actually there is a hack to figure out which of them have been visited, but anyway...). Really all you can do is choose 3-5 of them that work well and provide a link for more. For choosing which identity providers, that means I’ll pick Google openid+oauth, Facebook, and Twitter to feature (and offer others secondarily). It’s unfair and leaves out major players, but at least I know those offer my users solid authentication and pass basic user attributes so I can make an account for them without a lot of trouble. Hopefully as people start to use these the most reliable, seamless experience will win and identity will settle around a few major players. On 4/16/09 4:21 PM, Chris Messina chris.mess...@gmail.com wrote: Just wanted to point out that Twitter is now offering sign-in with one's Twitter account using OAuth: http://apiwiki.twitter.com/Sign-in-with-Twitter And, as if we didn't have enough buttons for the NASCAR [1], you can now use Twitter's button: http://twibs.com/oAuthButtons.php Oh, and it might interest some folks that there are interesting conversation going on about Twitter's authorization interface: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/0a1739326384dac6?pli=1 Chris [1] http://tr.im/fj_openid_nascar ___ user-experience mailing list user-experie...@openid.net http://openid.net/mailman/listinfo/user-experience --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
