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 <[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&format=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 -~----------~----~----~----~------~----~------~--~---
