[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
For 1), the community needs to make a concious decision to turn our backs on a set of use cases for devices that can't take direct input. These include smart picture frames that come with a pre-generated request token on a piece of paper and instructions to go activate them (e.g. so you can give your parents a picture frame that shows your private picasa photos) and smart medical bracelets that connect to Google Health or similar services. This also includes things like the Roku box or other set-top boxes that don't have keyboard input. These are all real and useful cases that OAuth 1.0 supports, and I don't think we should break them capriciously. If the authorization page makes the user type in a manual token, it can provide extra warning messages like Make sure you got this directly from the device you're authorizing, which I think is above threshold for a secure and workable model. Can others chime in who feel strongly one way or the other here? For 2) the only way to tell 1.0 from 1.0A-with-no-callback is to use the special oob/none value. If we can't do better than this, so be it, but special values feel like a hack at best, so I'm hoping we can come up with some creative alternative that would allow the callback param to be motted entirely and still be able to tell 1.0 from 1.0a without explicit version numbers. For 3) the only requirement is for the SP to reconstruct the signature, so appending two tokens is no harder than appending an extra name/value pair when computing the signature. After the SP generates the verifier, it could store the token+verifier as the key to look up when granting an access token, and thus it wouldn't need to break them back up later. I don't feel super strongly about this, but I know for a fact it will make the libraries more complex and inconsistent if this one use case takes an extra param that none of the other (otherwise identical) invocations need... Thanks, js On Sat, May 2, 2009 at 10:32 AM, Josh Roesslein jroessl...@gmail.comwrote: 1.) Yes this is a small window for an attacker to pull off a session fixation, but I think it should still be closed. It just takes one successful attack to make oauth look insecure. It might be possible for this parameter to be optional for the SP (banks might want to use this, but less sensitive data sites might not need this extra security). 2.) We can tell during the request token request if this is a 1.0 A or 1.0 consumer. If no callback parameter is present, its 1.0. 1.0 A consumers must still set this parameter even if they are not setting a callback (oob, none, etc). 3.) I don't really like this combining of the tokens. We'll have to disjoin them on the SP to verify. I don't think it will be much of a deal changing the signature code to make this work. On Sat, May 2, 2009 at 12:01 PM, Joseph Smarr jsm...@gmail.com wrote: Erna-just getting to a detailed review of the diff now. Generally it looks good but here are a couple of things I think we should change: 1) If no oauth_token is provided on the authorization URL in 6.2.1 (e.g. the mobile/device case where the Consumer is unable to open a web browser directly), then I don't think the Provider should return an oauth_verifier to be enterered into the Consumer. Basically I'm suggesting we stick to OAuth 1.0 here, and the reasons are: a) the attack we're patching is much harder to pull off if you have to get the victim to go to a URL and then manually enter a request token, and b) many devices won't provide a way to enter text into them, so requiring the verifier be manually entered will exclude those valuable use cases. 2) I agree with commenters below that providing oob for oauth_callback feels dirty and ideally there would be a better way to distinguish 1.0A and 1.0 Consumers. I really don't want to change version numbers to accomplish this, but maybe if we think a bit harder, we can come up with a good situation. For instane, if the Consumer sends oauth_callback on the authorization page, but not in the request token call, you know it's 1.0. I guess the hard part is if they don't send oauth_callback in either place, and you still respond with the verifier, how do you know when to expect it back or not. Hmm... Which brings me to the discussion we had last week (but which I believe has NOT made it to the list) about how Providers can support both 1.0A and 1.0 simultaneously for a while (which many will have to do). I would suggest adding this as an appendix (much as OpenID has a section on supporting both 1.1 and 2.0): - When granting a request token, Provider stores oauth_callback along with its token info (if provided). - On authorization page, Provider checks if they got a signed oauth_callback with the request token. If not, display extra warning messages. - Provider should be able to always send back an oauth_verifier, even though 1.0 clients will ignore it. It can store this with the request token
[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
1.) Well we should really not use a three legged approach for these devices. Reason: these consumers are not going to have multiple users. I suggest a two legged approach instead. 2.) I don't see it as a hack. We are telling the SP hey, we don't want to use a callback. This parameter is required, so we must still include it. 3.) The SP still needs to break them up to look up the record in the DB. We can't use the combined value as the key. If we use this combined value as the key, we can not block brute force attacks for guessing the verifier. We need to limit the number of times a request token can be swapped. If the consumer gives us a bad token+verifier, we don't have a valid key. We would have to split the token and verifier and use the token as the key. Sure we can still make this idea of token+verifier work, but it just seems like a hack to save some time. To me this seems like a hours work at most to add another parameter to the access token request. On Sat, May 2, 2009 at 3:27 PM, Joseph Smarr jsm...@gmail.com wrote: For 1), the community needs to make a concious decision to turn our backs on a set of use cases for devices that can't take direct input. These include smart picture frames that come with a pre-generated request token on a piece of paper and instructions to go activate them (e.g. so you can give your parents a picture frame that shows your private picasa photos) and smart medical bracelets that connect to Google Health or similar services. This also includes things like the Roku box or other set-top boxes that don't have keyboard input. These are all real and useful cases that OAuth 1.0 supports, and I don't think we should break them capriciously. If the authorization page makes the user type in a manual token, it can provide extra warning messages like Make sure you got this directly from the device you're authorizing, which I think is above threshold for a secure and workable model. Can others chime in who feel strongly one way or the other here? For 2) the only way to tell 1.0 from 1.0A-with-no-callback is to use the special oob/none value. If we can't do better than this, so be it, but special values feel like a hack at best, so I'm hoping we can come up with some creative alternative that would allow the callback param to be motted entirely and still be able to tell 1.0 from 1.0a without explicit version numbers. For 3) the only requirement is for the SP to reconstruct the signature, so appending two tokens is no harder than appending an extra name/value pair when computing the signature. After the SP generates the verifier, it could store the token+verifier as the key to look up when granting an access token, and thus it wouldn't need to break them back up later. I don't feel super strongly about this, but I know for a fact it will make the libraries more complex and inconsistent if this one use case takes an extra param that none of the other (otherwise identical) invocations need... Thanks, js On Sat, May 2, 2009 at 10:32 AM, Josh Roesslein jroessl...@gmail.comwrote: 1.) Yes this is a small window for an attacker to pull off a session fixation, but I think it should still be closed. It just takes one successful attack to make oauth look insecure. It might be possible for this parameter to be optional for the SP (banks might want to use this, but less sensitive data sites might not need this extra security). 2.) We can tell during the request token request if this is a 1.0 A or 1.0 consumer. If no callback parameter is present, its 1.0. 1.0 A consumers must still set this parameter even if they are not setting a callback (oob, none, etc). 3.) I don't really like this combining of the tokens. We'll have to disjoin them on the SP to verify. I don't think it will be much of a deal changing the signature code to make this work. On Sat, May 2, 2009 at 12:01 PM, Joseph Smarr jsm...@gmail.com wrote: Erna-just getting to a detailed review of the diff now. Generally it looks good but here are a couple of things I think we should change: 1) If no oauth_token is provided on the authorization URL in 6.2.1 (e.g. the mobile/device case where the Consumer is unable to open a web browser directly), then I don't think the Provider should return an oauth_verifier to be enterered into the Consumer. Basically I'm suggesting we stick to OAuth 1.0 here, and the reasons are: a) the attack we're patching is much harder to pull off if you have to get the victim to go to a URL and then manually enter a request token, and b) many devices won't provide a way to enter text into them, so requiring the verifier be manually entered will exclude those valuable use cases. 2) I agree with commenters below that providing oob for oauth_callback feels dirty and ideally there would be a better way to distinguish 1.0A and 1.0 Consumers. I really don't want to change version numbers to accomplish this,
[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
I would prefer it to have a value - for .net the usual way of accessing the form and querystring parameters returns null if the parameter is not there or has no value. To implement an empty value we would have to make two checks to see if the key is present and then check to see if it has a value. I know it's not a big deal but it can lead to bad implementations. oob seems perfectly valid to me. I would prefer the version to be used to identify what flow is in use - have to agree with David Parry that it makes it a lot cleaner to identify if the consumer has sent a version 1.0 request or they are attempting an invalid 1.1/1.0a request. But to enforce this the spec would need to be updated to make the oauth_version parameter mandatory in all requests. I don't think this would be a big leap though as I would have thought that most implementations already include this parameter as standard. --~--~-~--~~~---~--~~ 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 Fri, May 1, 2009 at 9:07 AM, chris.s.ad...@googlemail.com chris.s.ad...@googlemail.com wrote: I would prefer it to have a value - for .net the usual way of accessing the form and querystring parameters returns null if the parameter is not there or has no value. To implement an empty value we would have to make two checks to see if the key is present and then check to see if it has a value. I know it's not a big deal but it can lead to bad implementations. oob seems perfectly valid to me. What if the oauth_callback value were optional on the request_token step (as Eran has written it in the modified spec)? Then the parameter is not there, so checking is only one step. b. --~--~-~--~~~---~--~~ 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
On 4/30/09 3:25 AM, Eran Hammer-Lahav wrote: 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. Looks fine! Nicely done. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ 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 9: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=svn992old=991r=992format=unidiffpath=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml Looks good! In addition (or instead of) requiring the token and verifier to be suitable for manual entry If the Service Provider knows a Consumer to be running on a mobile device or set-top box , wouldn't be a sensible thing to require that every time the oauth_callback is set to oob as that ought to be a safe way to tell the consumer able to receive a callback from those that will require manual operations? It may remove a bit of uncertainty when dealing with different kinds of consumers... This would impact: - The wording in 6.2.3: If the value of the oauth_callback parameter was oob, case sensitive, then the Service Provider SHOULD ensure that the generated Request Token is suitable for manual entry - The note in 6.2.1: If the the value of the oauth_callback parameter was oob, case sensitive, then the Service Provider SHOULD ensure that the User Authorization URL and Request Token are suitable for manual entry - And it could be added to 6.1.2: If the value of the oauth_callback parameter was oob, case sensitive, then the Service Provider SHOULD ensure that the generated Request Token is suitable for manual entry. what do you think? Luca --~--~-~--~~~---~--~~ 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
I believe oob stands for out-of-band here, meaning the consumer cannot handle callbacks so an out-of-band mechanism should be used. I think the modifs are clear enough, with a preference to leave the oauth_callback set to an empty string instead of oob (as Blaine indicated). One nitpick: a non-guessable value is not very precise. Why not saying something like a UUID (even though it may not have to be unique). Cheers, Hubert On Thu, Apr 30, 2009 at 2:02 PM, Morten Fangel fan...@sevengoslings.net wrote: I was say that 'oob' would mean that the new auth.-flow, which means that any callback received on the authentication-page would be ignored.. A non-'oob'/non-url/non-existing callback received in the request-token step means the usual flow, which means that callbacks received on the auth.-page should be respected.. This would preserve backwards compat, while plugging the hole for any new clients.. Or, that's how I understood the reason for the 'oob'-value? But why 'oob' ? it just reminds people of either noob or boob.. does it have any certain value or was it just chosen for fun? -Morten On Apr 30, 2009, at 1:19 PM, Blaine Cook wrote: Looks good, with the exception of the 'oob' value – why not just say that an empty OR absent callback parameter fulfills the same role as 'oob'? There are also plenty of service providers that require static configuration of the callback, and in those cases the callback parameter would be absent when obtaining the request token. b. On Thu, Apr 30, 2009 at 8: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=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: OAuth Core 1.0 Rev A, Draft 1
On Thu, Apr 30, 2009 at 2:29 PM, Hubert Le Van Gong hubert...@gmail.com wrote: One nitpick: a non-guessable value is not very precise. Why not saying something like a UUID (even though it may not have to be unique). because in those cases where it has to be manually inputted by the user it will have to be short enough (e.g. PIN-like) Luca --~--~-~--~~~---~--~~ 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
I was say that 'oob' would mean that the new auth.-flow, which means that any callback received on the authentication-page would be ignored.. A non-'oob'/non-url/non-existing callback received in the request-token step means the usual flow, which means that callbacks received on the auth.-page should be respected.. This would preserve backwards compat, while plugging the hole for any new clients.. Or, that's how I understood the reason for the 'oob'-value? But why 'oob' ? it just reminds people of either noob or boob.. does it have any certain value or was it just chosen for fun? -Morten On Apr 30, 2009, at 1:19 PM, Blaine Cook wrote: Looks good, with the exception of the 'oob' value – why not just say that an empty OR absent callback parameter fulfills the same role as 'oob'? There are also plenty of service providers that require static configuration of the callback, and in those cases the callback parameter would be absent when obtaining the request token. b. On Thu, Apr 30, 2009 at 8: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=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: OAuth Core 1.0 Rev A, Draft 1
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 Nice changes. A few points * oob: Can it be described at first use or renamed to something that makes immediate sense? * non-guessable is impossible to achieve... perhaps hard to guess instead? * In order to ensure that the User... can be simplified to To make sure the User Hans --~--~-~--~~~---~--~~ 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 4/30/09 7:19 AM, Blaine Cook wrote: Looks good, with the exception of the 'oob' value – why not just say that an empty OR absent callback parameter fulfills the same role as 'oob'? There are also plenty of service providers that require static configuration of the callback, and in those cases the callback parameter would be absent when obtaining the request token. I'm guessing Eran's concern was being able to differentiate between a 1.0 consumer vs. a 1.0A consumer. Having an absent callback parameter could be either. The rationale of sending a magic string like oob because we can't trust that the consumer and/or server's HTTP implementation to not be BROKEN when handling empty parameters irks me, but I didn't feel like arguing about it. If I were king, I'd say that an empty callback parameter is required for 1.0A consumers, and absent signifies 1.0 consumers. Really, why not bump the version to 1.1? Is there real magic behind the version number? What's the point of versioning the protocol if revving it is painful? -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ 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
Dossy Shiobara wrote: On 4/30/09 7:19 AM, Blaine Cook wrote: Looks good, with the exception of the 'oob' value – why not just say that an empty OR absent callback parameter fulfills the same role as 'oob'? There are also plenty of service providers that require static configuration of the callback, and in those cases the callback parameter would be absent when obtaining the request token. I'm guessing Eran's concern was being able to differentiate between a 1.0 consumer vs. a 1.0A consumer. Having an absent callback parameter could be either. Wouldn't that be the purpose of the oauth_version parameter? I also think it would be a good idea to include an appendix section that summarizes the changes between 1.0 and (1.0a or 1.1 whichever it be). Rob --~--~-~--~~~---~--~~ 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:38 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Also, do we need another value to indicate a desktop client that doesn't need the verifier? Will the revised protocol allow for (desktop) consumers who *don't need* the verifier or should the protocol ask for *manual input* of the verifier? If the former then maybe the attack could be done by using one of those clients who don't require the verifier ... Luca --~--~-~--~~~---~--~~ 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
That's a matter for how servers handle their consumer keys and registrations. If no oauth_callback is present in the first step (1.0a), a server can: 1. Reject the request 2. Allow the request but only for clients registered as desktop, and properly inform the user (An application running on your computer (not a web site) has requested access). 3. Show a big red warning that the user must not grant access unless they know where they came from, etc. Deciding what to do is up to each server based on its own security requirements. Making desktop applications use the verifier is bad user experience as it adds no real value there, but it does make the entire API more secure and more difficult to trick users. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Luca Mearelli Sent: Thursday, April 30, 2009 8:54 AM To: oauth@googlegroups.com Subject: [oauth] Re: OAuth Core 1.0 Rev A, Draft 1 On Thu, Apr 30, 2009 at 5:38 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Also, do we need another value to indicate a desktop client that doesn't need the verifier? Will the revised protocol allow for (desktop) consumers who *don't need* the verifier or should the protocol ask for *manual input* of the verifier? If the former then maybe the attack could be done by using one of those clients who don't require the verifier ... Luca --~--~-~--~~~---~--~~ 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 6:11 PM, Blaine Cook rom...@gmail.com wrote: No version changes required, no oob value for the callback parameter required, either. wouldn't it help with detecting the consumers that are able to follow the revised protocol even if unable to get the redirect? i.e. those able to close the loop passing the verifier code but requiring the user to input it since they cannot receive the callback. Luca --~--~-~--~~~---~--~~ 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:23 PM, Luca Mearelli luca.meare...@gmail.com wrote: wouldn't it help with detecting the consumers that are able to follow the revised protocol even if unable to get the redirect? i.e. those able to close the loop passing the verifier code but requiring the user to input it since they cannot receive the callback. Yes; that's a different thing, and maybe it makes sense to have some kind of out-of-band parameter for consumers that are unable to receive callbacks. However, I'd argue that this should happen not at the request token step, but beforehand, in the out-of-band configuration of consumers. That way if a downloadable consumer key / secret gets stolen (as they will), it's not possible for the attacker to use them on a website and avoid the verification key requirement. b. --~--~-~--~~~---~--~~ 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 7:02 PM, Mike Malone mjmal...@gmail.com wrote: oauth_callback in 2nd step: - Present and wasn't in 1st step - no verifier requirement if allowed by the server, potential stronger warning (should be deprecated eventually) ... So there's a loophole. A more draconian way would be to never take into consideration the oauth_callback sent in 2nd step, allowing as valid only callbacks sent in 1st step, the choice would be simpler for the SPs. From Eran's summary of the proposal there are three ways to close the loop: (1) Verifier + Callback (2) Verifier + Manual entry (3) No verifier + manual 'continue' The options for the SP would be: oauth_callback in 1st step: - Present with value - do (1) - Present with empty value - do (2) - Not included in request - do (3) oauth_callback in 2nd step: - Present and wasn't in 1st step - do (3) (or give error if deprecated) - Present in both 1st and 2nd steps - error - Not included in redirection - do (3) Luca --~--~-~--~~~---~--~~ 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
From Eran's summary of the proposal there are three ways to close the loop: (1) Verifier + Callback (2) Verifier + Manual entry (3) No verifier + manual 'continue' The options for the SP would be: oauth_callback in 1st step: - Present with value - do (1) - Present with empty value - do (2) - Not included in request - do (3) oauth_callback in 2nd step: - Present and wasn't in 1st step - do (3) (or give error if deprecated) - Present in both 1st and 2nd steps - error - Not included in redirection - do (3) This would break the web flow for 1.0 (non Rev. A) consumers. You could ask at consumer provisioning whether it's a web or desktop app. In that case this would essentially be the same as the disallow callbacks for desktop apps option. Mike --~--~-~--~~~---~--~~ 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:50 PM, Breno de Medeiros br...@google.com wrote: I do not see how an empty value is an improvement from a non-valid URI. It may not cause problems, but we don't know that. Let's play safe and if people are unhappy with 'oob', then say 'outofband' or something. Not included in request token request seems not an option for clients that expect a verifier, if we expect SPs will have a period of handling both flows. I maintain that whether a consumer is able to receive callbacks is something that should happen when the consumer key is issued, not when the request token is issued. To reiterate: 1. Attacker obtains consumer key and secret from the distributed consumer code. 2. Attacker obtains request token with callback pointing to a site that they control. 3. Attacker sends their target the authorization URL with the request token. 4. Target authorizes the application, and because a callback URL is present, no additional warnings are displayed to the user (since the verification code will be used to ensure that endpoint receiving the authorization was the one that initiated the flow). 5. Target is redirected to the attacker's site, verification code in hand. 6. Attacker is able to exchange the request token for a valid access token with rights to the target's account on the service provider. The only way to avoid this attack is to know in advance of issuing a request token that a consumer is a desktop application. In such cases, the user should be given a strict warning by the service provider about the conditions under which they should approve the application. In general, I disagree that applications can't handle callbacks. There is extensive support for custom protocol handlers in all major operating systems, and we should be encouraging application developers to think carefully about how their applications interact with the web. In cases where callbacks are not supported, there should never be the option to flip back and forth. Either the application supports callbacks, or it doesn't, end of story. b. --~--~-~--~~~---~--~~ 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
Eran, Great stuff, I like the direction of this fix. My only worry is calling it 1.0a. I'd rather see this called 1.1. Two arguments: 1) this is an important change to the protocol. 2) there needs to be a clear message for providers who have upgraded to the latest protocol. The difference between 1.0 and 1.0a is far too small in high-level discussions, it might go unnoticed. I realize this may cause issue with the oauth_version parameter... but I don't think this is a change that should go unnoticed, ever. -Ben On Apr 30, 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_... 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=992;... 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: OAuth Core 1.0 Rev A, Draft 1
On Thu, Apr 30, 2009 at 7:08 PM, Mike Malone mjmal...@gmail.com wrote: I don't know, is it? I was under the impression that the rev was designed to preserve backwards compatibility and leave the decision up to SPs. Right; (I think) the 1.0 consumers will only break if an SP has upgraded to 1.0a/1.1 or whatever we call the new version. b. --~--~-~--~~~---~--~~ 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
SP's could run both version at the same time to allow consumer time to upgrade to the new spec. The version being used can be detected with the oauth_version parameter. On Thu, Apr 30, 2009 at 1:22 PM, Blaine Cook rom...@gmail.com wrote: On Thu, Apr 30, 2009 at 7:08 PM, Mike Malone mjmal...@gmail.com wrote: I don't know, is it? I was under the impression that the rev was designed to preserve backwards compatibility and leave the decision up to SPs. Right; (I think) the 1.0 consumers will only break if an SP has upgraded to 1.0a/1.1 or whatever we call the new version. b. --~--~-~--~~~---~--~~ 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 7:55 PM, Blaine Cook rom...@gmail.com wrote: In cases where callbacks are not supported, there should never be the option to flip back and forth. Either the application supports callbacks, or it doesn't, end of story. agreed, this is the most secure way. Do you think this is something that belongs to the spec (as in: be the required behavior) ? Luca --~--~-~--~~~---~--~~ 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 8:08 PM, Mike Malone mjmal...@gmail.com wrote: On Thu, Apr 30, 2009 at 10:57 AM, Blaine Cook rom...@gmail.com wrote: On Thu, Apr 30, 2009 at 6:54 PM, Mike Malone mjmal...@gmail.com wrote: This would break the web flow for 1.0 (non Rev. A) consumers. I think that's the desired behaviour, though? So long as service providers continue to support 1.0 non Rev. A consumers, the vulnerability persists. b. I don't know, is it? I was under the impression that the rev was designed to preserve backwards compatibility and leave the decision up to SPs. hmm I would prefer simple upgrade with minimal disruption rather than backward compatibility (i.e. if we want to fix the problem i think that the web flow will need to be broken for those OAuth 1.0 cosumers expecting the callback parameter to work as before...) Luca --~--~-~--~~~---~--~~ 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
How 1.0a should deal with 1.0 is outside the scope of the spec. The only thing we need to make sure is that a 1.0a server can detect which flow the client is trying to use, and make its own decision on how to handle it. The best tool we have is the oauth_callback parameter in the first step. We need to accommodate 2 cases for it, callback and manual entry. Given the fact that people rarely actually read the authorization pages, I am reluctant to support a mode for no verifier, even if the server gives strong warnings about this being a desktop application. The two questions are: - How can a server know which flow is being used? The server looks for an oauth_callback in the 1st step. If one is present (regardless of value), it is the new flow. If non is present, it is the old flow. The server will need to decide what to do with an old flow and it will no be addressed by the specification (maybe in short appendix). - How can a server know if the verification token should be delivered via a callback or manually? The server looks for the value of the oauth_callback parameter in the first step. If the value is empty/some-string, it knows to deliver the verification code manually. The decision between an empty callback or a fixed string is still open and I would like to ask more people to chime in. EHL On 4/30/09 11:22 AM, Blaine Cook rom...@gmail.com wrote: On Thu, Apr 30, 2009 at 7:08 PM, Mike Malone mjmal...@gmail.com wrote: I don't know, is it? I was under the impression that the rev was designed to preserve backwards compatibility and leave the decision up to SPs. Right; (I think) the 1.0 consumers will only break if an SP has upgraded to 1.0a/1.1 or whatever we call the new version. b. --~--~-~--~~~---~--~~ 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: OAuth Core 1.0 Rev A, Draft 1
To me this wording makes sense. Basically it's saying the verification code the consumer submits to exchange for an access token must match the verifier the SP generated for the callback. This verifies the user returning to the consumer is the same user who authorized the consumer on the SP. The SP can't forget this value since they must verify it. Each request token will have a verification value bound to it. So the SP's access token verification process is: 1. Validate signature of access token request (make sure this is the consumer) 2. Is this request token bound to this consumer? 3. Does the verifier match the one we have on record for this request token? 4. Generate access token and send back to consumer Hope that clears up your question. On Thu, Apr 30, 2009 at 6:18 PM, Dirk Balfanz dirk.balf...@gmail.comwrote: 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: OAuth Core 1.0 Rev A, Draft 1
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. 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
Not incrementing the oauth_version for the new spec is a mistake imho. It seems kinda flaky to me to switch between the specs 1.0/1.0a purely based on whether the oauth_callback is sent when a consumer obtains a request token. --~--~-~--~~~---~--~~ 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
Proposed Google searches: jar+version+nightmare dll+version+nightmare development framework of choice+version+nightmare On Thu, Apr 30, 2009 at 7:17 PM, Josh Roesslein jroessl...@gmail.com wrote: How will calling this 1.1 slow down the upgrade process? All libraries need to change to cover the new spec, so it doesn't matter what we call it. SP's can still support older clients by running 1.0 and 1.1 specs. This allows for older clients to perform upgrades to 1.1 before cutting them off. SP checks the oauth_version string in the request token request and then uses the correct library version to complete the flow. On Thu, Apr 30, 2009 at 8:55 PM, Breno de Medeiros br...@google.com wrote: Since there is no discovery supported in OAuth, even if the version is incremented, there is no way to know if an SP or consumer has upgraded without actually running the flow. If you increment the version number, you will have to make a lot more code changes in each library to configure behavior, and will slow down adoption of the fix and complicate a transitional period where folks might want to support the older flow with some mitigation features/stronger warnings until it is safe to break compatibility. If we want better security, we go with the option that moves us forward fastest. The easiest way to abandon 1.0 flow is to get everybody upgraded to 1.0A. And developers are complaining that incrementing the version number will slow things down. On Thu, Apr 30, 2009 at 6:26 PM, David Parry devb...@gmail.com wrote: seriously, I don't understand the reluctance to increment oauth_version. The new implementation is going to require work from both SPs and consumers, and neither is really going to know if other has upgraded without actually running the flow. At least, by incrementing the version, both the SP and the Consumer definitively know the required flow. -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~-~--~~~---~--~~ 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
As a Service Provider, I want to be able to run both 1.0 and 1.0a (or 1.1) concurrently for a period of time while my consumers implement the new version. Then disable 1.0 and return an error if a consumer attempts to use the old version. At least to me, this provides the easiest and most fail safe migration path for all parties. --~--~-~--~~~---~--~~ 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
For what it's worth, this draft looks good to me. Agreed that oob is a bit obscure. The first hit for a google search on oob lists a page with a dozen possibilities (including the right one), and the other hits on the first page are red herrings. Some suggestions: oauth_callback=none oauth_callback=noturl But documenting what oob stands for is fine too. - Brian --~--~-~--~~~---~--~~ 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
Actually I kind of like none, but that might just be the python talking in me. none might make it more clear the parameter isn't used, but I would be fine with oob. On Thu, Apr 30, 2009 at 11:49 PM, Brian Slesinsky bslesin...@gmail.comwrote: For what it's worth, this draft looks good to me. Agreed that oob is a bit obscure. The first hit for a google search on oob lists a page with a dozen possibilities (including the right one), and the other hits on the first page are red herrings. Some suggestions: oauth_callback=none oauth_callback=noturl But documenting what oob stands for is fine too. - Brian --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
