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