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=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 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 -~----------~----~----~----~------~----~------~--~---
