[oauth] Re: Desktop Application Callback Value
On May 2, 2:19 am, Brian Eaton bea...@google.com wrote: On Fri, May 1, 2009 at 1:43 AM, Blaine Cook rom...@gmail.com wrote: 1. None. Applications that cannot receive callbacks (or that have static callback endpoints) should be configured as such in an out-of-band flow, along with the service provider issues the consumer key and secret. Just because the callback is preregistered doesn't mean an application won't want to update it at runtime. For example, they might want to add session state information or language preference information. We allowed for this with our implementation by returning any additional Consumer query parameters that were provided in the authorize url. --~--~-~--~~~---~--~~ 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: Desktop Application Callback Value
Ok, thankfully it seems here we have much more consensus. I don't see anyone disagreeing that we want an 'oob' value for the callback. I would like to make the following changes to the (proposed) spec so that consumers (or service providers) aren't required to add an extra verification code entry step for desktop consumers: In 6.1.1: Change: oauth_callback: An absolute URL to which the Service Provider will redirect the User back when the Obtaining User Authorization step is completed. If the Consumer is unable to receive callbacks, the parameter value MUST be set to oob (case sensitive). To: oauth_callback: An absolute URL to which the Service Provider will redirect the User when the Obtaining User Authorization step is completed. This parameter is optional if the Consumer has provided, through alternate means, a static callback URL. If the consumer is unable to receive callbacks, the oauth_callback parameter is optional, but when present MUST be set to oob (case sensitive). and 6.2.3: Change: If no callback URL was provided (the value of the oauth_callback parameter was oob, case sensitive), ... To: If no callback URL was provided and the value of the oauth_callback parameter was oob (case sensitive), ... - end of changes Any concerns with moving forward with this wording? I believe it's important to continue supporting desktop applications that do not have support for entering verification codes, and this approach allows service providers to signal in strong terms to a user that they should only approve a request to verify a desktop application if they are actively trying to do so. 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: Desktop Application Callback Value
On Sat, May 2, 2009 at 12:17 PM, Blaine Cook rom...@gmail.com wrote: Any concerns with moving forward with this wording? I believe it's important to continue supporting desktop applications that do not have support for entering verification codes, and this approach allows service providers to signal in strong terms to a user that they should only approve a request to verify a desktop application if they are actively trying to do so. I do agree with what you propose, but I don't think the new wording vs the old is enough to keep working those desktop apps that do not have support for entering verification codes as the revised spec says: In order to ensure that the User granting access is the same User returning back to the Consumer to complete the process, the Service Provider MUST generate a verification code: a non-guessable value passed to the Consumer via the User and REQUIRED to complete the process. it seems that it doesn't allow closing the loop without the verification code being passed from consumer to service provider. (sorry if this sounds silly, I'm just trying to understand help and i don't want to start a new infinite discussion ...) 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: Desktop Application Callback Value
Version 3, where the string literal is supposed to be interpreted as manual entry or out-of-band exchange of the callback token. Version 1 is already supported. There is interest to support some form of manual entry (for instance, SPs could give less stern warnings for such desktop apps). On Fri, May 1, 2009 at 1:43 AM, Blaine Cook rom...@gmail.com wrote: We need to gain some consensus around the value (or lack thereof) that should be used for the oauth_callback parameter that is sent from the consumer to the service provider when obtaining the request token in the new flow. Our options: 1. None. Applications that cannot receive callbacks (or that have static callback endpoints) should be configured as such in an out-of-band flow, along with the service provider issues the consumer key and secret. 2. String literal none 3. String literal, other than none I have omitted oob explicitly since it seems as though there was a lot of confusion around it. However, there is the option for a different string literal. I'd also like to hear from library authors whose voices have not been present in the discussions over the past week. Please indicate your preferred option as soon as possible. b. -- --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: Desktop Application Callback Value
On May 1, 1:43 am, Blaine Cook rom...@gmail.com wrote: We need to gain some consensus around the value (or lack thereof) that should be used for the oauth_callback parameter that is sent from the consumer to the service provider when obtaining the request token in the new flow. Our options: 1. None. Applications that cannot receive callbacks (or that have static callback endpoints) should be configured as such in an out-of-band flow, along with the service provider issues the consumer key and secret. 2. String literal none 3. String literal, other than none I have omitted oob explicitly since it seems as though there was a lot of confusion around it. However, there is the option for a different string literal. I'd also like to hear from library authors whose voices have not been present in the discussions over the past week. Please indicate your preferred option as soon as possible. b. 3 for all the reasons Breno mentioned. --~--~-~--~~~---~--~~ 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: Desktop Application Callback Value
On Fri, May 1, 2009 at 1:43 AM, Blaine Cook rom...@gmail.com wrote: 1. None. Applications that cannot receive callbacks (or that have static callback endpoints) should be configured as such in an out-of-band flow, along with the service provider issues the consumer key and secret. Just because the callback is preregistered doesn't mean an application won't want to update it at runtime. For example, they might want to add session state information or language preference information. --~--~-~--~~~---~--~~ 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: Desktop Application Callback Value
On Fri, May 1, 2009 at 5:19 PM, Brian Eaton bea...@google.com wrote: On Fri, May 1, 2009 at 1:43 AM, Blaine Cook rom...@gmail.com wrote: 1. None. Applications that cannot receive callbacks (or that have static callback endpoints) should be configured as such in an out-of-band flow, along with the service provider issues the consumer key and secret. Just because the callback is preregistered doesn't mean an application won't want to update it at runtime. For example, they might want to add session state information or language preference information. Sorry, I didn't mean to bias the question; I just sought to clarify what the intent of the option was. Further to the point, I think in general it should be assumed that desktop applications should never be allowed to update the callback to point at an HTTP URI, since that means attackers need only steal consumer keys from an installed application to perform the attack we're trying to correct for here. My preference is actually Breno's proposal, which is somewhat different than any of the options I presented above, somewhere between #1 and #2. 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: Desktop Application Callback Value
Out of band is the correct term here and at least half the people here figured it out intuitively. I still like it better than other suggestions and think this would be a non-issue if the spec spells is out use 'oob' (out of bank). I think using a value to indicate oob is better than empty or no parameter because we *know* that will work. We are not sure yet about how the other options will affect different systems and we don't have time to fully find out. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of John Kemp Sent: Friday, May 01, 2009 10:27 AM To: oauth@googlegroups.com Subject: [oauth] Re: Desktop Application Callback Value On May 1, 2009, at 12:02 PM, Breno de Medeiros wrote: Version 3, where the string literal is supposed to be interpreted as manual entry or out-of-band exchange of the callback token. +1 - johnk Version 1 is already supported. There is interest to support some form of manual entry (for instance, SPs could give less stern warnings for such desktop apps). On Fri, May 1, 2009 at 1:43 AM, Blaine Cook rom...@gmail.com wrote: We need to gain some consensus around the value (or lack thereof) that should be used for the oauth_callback parameter that is sent from the consumer to the service provider when obtaining the request token in the new flow. Our options: 1. None. Applications that cannot receive callbacks (or that have static callback endpoints) should be configured as such in an out-of-band flow, along with the service provider issues the consumer key and secret. 2. String literal none 3. String literal, other than none I have omitted oob explicitly since it seems as though there was a lot of confusion around it. However, there is the option for a different string literal. I'd also like to hear from library authors whose voices have not been present in the discussions over the past week. Please indicate your preferred option as soon as possible. b. -- --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: Desktop Application Callback Value
On Fri, May 1, 2009 at 10:43 AM, Blaine Cook rom...@gmail.com wrote: 2. String literal none 3. String literal, other than none +1 for an explicit string (whether none or oob) 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: Desktop Application Callback Value
We either need an explicit string for the null callback, or we need to increment the version number, because the SP needs a way to determine which OAuth dialect the consumer is speaking as early on in the dance as possible. I believe that it's more pain than its worth to increment the version number, so we'll need a string literal. I vote for oob since it's as good as any, and its already in Draft 1. Allen Luca Mearelli wrote: On Fri, May 1, 2009 at 10:43 AM, Blaine Cook rom...@gmail.com wrote: 2. String literal none 3. String literal, other than none +1 for an explicit string (whether none or oob) 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 -~--~~~~--~~--~--~---
