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
