[oauth] Re: Desktop Application Callback Value

2009-05-02 Thread David Parry
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

[oauth] Re: Desktop Application Callback Value

2009-05-02 Thread Blaine Cook
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

[oauth] Re: Desktop Application Callback Value

2009-05-02 Thread Luca Mearelli
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

[oauth] Re: Desktop Application Callback Value

2009-05-01 Thread Breno de Medeiros
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

[oauth] Re: Desktop Application Callback Value

2009-05-01 Thread Manish Pandit
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:

[oauth] Re: Desktop Application Callback Value

2009-05-01 Thread Brian Eaton
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

[oauth] Re: Desktop Application Callback Value

2009-05-01 Thread Blaine Cook
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

[oauth] Re: Desktop Application Callback Value

2009-05-01 Thread Eran Hammer-Lahav
: 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

[oauth] Re: Desktop Application Callback Value

2009-05-01 Thread Luca Mearelli
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

[oauth] Re: Desktop Application Callback Value

2009-05-01 Thread Allen Tom
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