It seems that the basic problem here is that we have a monolithic
version number for API calls and the handshake/dance protocol. There
are a couple of possible solutions that result if we use two
identifiers, one for the signature protocol and another for the
handshake protocol.
Option #1 -- oauth_version varies by request.
One way to indicate that we are using the new handshake protocol is by
incrementing the oauth_version parameter for handshake requests, and
leave it at 1.0 for api requests.
oauth_version=1.1 handshake requests
oauth_version=1.0 API requests
Option #2 -- oauth_version with split out signature/handshake versioning
If we anticipate that signature methods change over time independently
of handshake versioning then we might want to consider a multi-part
version that contains the signature version first followed by the
handshake version. For non-handshake requests the handshake version
is omitted:
oauth_version=1.0/1.1 handshake requests.
oauth_version=1.0 api requests.
Option #3 -- Separate oauth_handshake_version parameter
If we want full clarity we could introduce a new parameter that tracks
the handshake protoocol:
oauth_version=1.0&oauth_handshake_version=1.1 handshake request
oauth_version
=1.0 api
request
Personally I'm not in favor of using heuristics to determine protocol
versioning -- this leads to a lot of complexity and confusion for
server and client side implementations and reminds me way to much of
browser/capability sniffing in javascript.
Paul
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
