The parameter has to be there because it is the only way to know this is the new flow. I didn't use an empty value because I think some platforms and library will have a problem sending or telling if the parameter was there empty.
If people think this will work with sending an empty value, I am fine with that. Also, do we need another value to indicate a desktop client that doesn't need the verifier? EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Blaine Cook > Sent: Thursday, April 30, 2009 4:20 AM > To: [email protected] > Subject: [oauth] Re: OAuth Core 1.0 Rev A, Draft 1 > > > 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 > <[email protected]> wrote: > > > > Please review: > > > > http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core- > 1_0a.html > > > > I did my best to keep the changes to a bare minimum and to avoid any > editorial changes to make comparison trivial: > > > > > http://code.google.com/p/oauth/source/diff?spec=svn992&old=991&r=992&fo > rmat=unidiff&path=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml > > > > Some notes: > > > > 1. This is not ready for code! Please wait for a second draft before > you start making changes to libraries or your implementations. Given > the small scope of this change, I think it will be stable in the next > draft. > > > > 2. Since this change is small, I would like to give it a short review > period before another draft. Please submit all your comments by May > 8th. > > > > 3. This draft is missing a few new Security Consideration sections. > It will be added in the next draft but might be shared earlier on the > list. > > > > 4. This revision does not change the value of the oauth_version > parameter which remains '1.0'. The reason for that is that the version > has nothing to do with the authorization workflow. It is specific to > the signature methods and parameter delivery methods. Telling the > difference between the two revisions is very simple: look for an > oauth_callback parameter in the Request Token step. > > > > 5. The reason why the oauth_callback parameter is now required with a > 'oob' value for manual entry is because the presence of the > oauth_callback parameter in the first step is the only indication which > flow is being used. Since some platforms have problem with empty > parameters (they are dropped or not sent on the wire), I decided to try > and define a non-URL value (also made the URL absolute). > > > > NOTE: Do no suggest ANY editorial changes that are not specific to > the changed sections. This is NOT an opportunity to improve the > specification. If you want to improve the specification in general, > please provider feedback to the Editor's Cut version. > > > > Tomorrow, I will post an updated Editor's Cut version as well as an > update to the IETF draft to include these changes. > > > > EHL > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
