Another newbie question: what is the technical reason for NOT including an oauth protocol version number?
Including protocol versions numbering is the norm in most/all IETF protocols. Also exchange types, cipher types, etc. etc. /thomas/ ________________________________________ From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Rob Richards [rricha...@cdatazone.org] Sent: Monday, June 21, 2010 7:54 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Status update I still think that the issue of running both 1.0 and 2.0 on an resource endpoint needs to be addressed in the spec. It is unrealistic to think that a provider currently running 1.0 can just do a complete cutover to 2.0 and shut down 1.0 access, or providers arbitrarily making the decision what constitutes 1.0 and what constitutes 2.0. Personally I think that an oauth_version parameter should be required for the resource endpoint as it will definitely allow version to be determined and prevent this potential problem from any future versions as well. Others think that just by checking for non-existance of parameters would work, though it is only best guess at that point because it could be a 1.0 call requiring a 400 error to be returned. In either case, this really needs to be addressed in the spec so that all providers are doing the check in the exact same way to avoid ambiguity. Rob Eran Hammer-Lahav wrote: > > With the exception of extensibility, I consider draft -08 to be > feature complete. This means that the draft contains all the features > and components needed and other then editorial work is close to > finished. I plan to finish work on the -09 draft by Mon or Tue next > week which will include the extensibility text, additional editorial > work, and resolution of the proposal to simplify the end-user > authorization endpoint. At that point, I intend to ask for an interim > last-call on the normative language (i.e. the implementation details). > > Note that this last-call isn’t really a WG last call. The spec can > change after that. But it will be a useful milestone to figure out if > the draft’s implementation details are stable and can be considered > complete. > > All of this of course requires the approval of the chairs. > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
