2009/5/4 Eran Hammer-Lahav <[email protected]> > I think a single new/moved parameter is better than multiple parameters. > I agree that using a literal string as the callback value feels like a hack, > but it works well and very easy to explain. The bigger the spec change is, > the longer it takes to finish this work. >
Can all current users of pre-registered URLs pass such a URL in via the oauth_callback URL anyway, with the service providers indicating errors in cases where the supplied URL is not allowed? If so, then this can can be covered with only a single parameter and no endpoint change. I would find the small hack of the sentinel callback string preferable to the significant inconvenience of changing endpoints. I suspect I'm not alone here. Mike > > EHL > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Mike Fleming > *Sent:* Monday, May 04, 2009 9:46 AM > *To:* [email protected] > > *Subject:* [oauth] Re: New Flow, New Endpoints > > > > Would it be worth considering other parameter names, e.g. > "oauth_callback_preregistered", "oauth_callback_none", that when present > indicate one of the other three scenarios? > > I understand the concerns with the placeholder "oob" value, although am not > personally troubled by it. But it seems to me that alternate parameter names > would resolve this issue with less coordination and confusion than changing > endpoint URLs, albeit at some additional spec length. > > (my appologies if this idea has already been discussed and rejected, but I > have not seen it) > Mike > > On Mon, May 4, 2009 at 8:53 AM, Eran Hammer-Lahav <[email protected]> > wrote: > > The spec will not describe multiple endpoints, but if this is a practical > solution, it allows us to drop the ‘oob’ callback value as well as support > the case where the callback is pre-registered and that is what they client > would like to use. There are more than just 2 callback scenarios: > > > > - Callback provided in the oauth_callback parameter > > - Callback provided in the consumer registration process > > - No callback possible; verification code shown to user instead for manual > entry > > - No callback and no verification code (for some very limited consumers) > > > > If we only support the first case using the oauth_callback parameter and > the other three in the registration process for each consumer (which is > where it is today), we don’t need to add magic values, just so we can tell > this is the new flow (which requires the presence of the oauth_callback > parameter in the first step). > > > > Using different endpoints makes the current proposal even simpler and > shorter. > > > > EHL > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Mike Fleming > *Sent:* Monday, May 04, 2009 8:40 AM > *To:* oauth > *Subject:* [oauth] Re: New Flow, New Endpoints > > > > Versioned endpoints do strike me as a better way than version numbers to > make changes to the protocol that must be backwards incompatible. Obviously, > they have much clearer semantics than the version number. > > > > But I do have to say that, coming from a service provider prospective, I've > yet to see technical merit in changing the protocol version or changing the > endpoints. Since its possible for an SP to distinguish new clients from old, > the SP doesn't need the hint. As for consumers, they could track the state > of SPs they're interested in as a flag in their own SP database if they > desire. They probably would do this for an endpoint URL change anyway. > > > > Since there is no specified endpoint URL pattern, changing the endpoint > URLs would require coordination and communication. This may be manageable > but it certainly won't be convenient and it doesn't strike me as necessary > in this case. > > > > Mike > > 2009/5/3 Eran Hammer-Lahav <[email protected]> > > > We seem to be spending a lot of time on the question of how providers > supporting both flows can tell which flow is being used. If they simply > offer a new set of 3 endpoints: request token, authorize, and access token, > this entire problem goes away. It also removed the need to make the > oauth_callback mandatory in the new flow, or use literal strings to indicate > out-of-band. > > New flow endpoints - always requires verification code to get access token, > which is delivered using a callback is available (via the parameter or > registration), otherwise manually. > > Old flow endpoints - broken business as usual with scary language. > > This leaves all the actual API endpoints untouched, unchanged, unbroken. > Any existing code will need to change to use the new flow which means it can > as easily point to new endpoints. This is also consistent with how the > discovery proposal works (which shows it is not a new idea). > > New providers have no reason to support the old flow. This is really only > about 30 or so providers with OAuth endpoints *today*. > > Why not? > > 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 -~----------~----~----~----~------~----~------~--~---
