I think the discussion around the version number is completely misguided
because we don't have a basic agreement on what the hell the version is even
for. This means that based on your personal interpretation of what it means,
you come to a different conclusion. Just because we change the specification,
doesn't mean we should change the version - we need to first agree what it is
for. For those new here, at the OAuth Summit last year we had a wide consensus
not to change the oauth_version value, even with proposals to add new
parameters, error codes, etc. This is not much different.
---
There are 4 elements of the protocol with a version associated with them:
* The specification document - this tells readers that there is a new document.
* The authorization flow used to obtain an Access Token - this is what we are
changing (getting an Access Token).
* The authentication method - the way in which signed OAuth requests are made
and transmitted (using an Access Token).
* The signature method - the way in which the signature value is calculated.
The versioning of each of these must be addressed separately or we will be
breaking stuff for no reason (like 2-legged clients).
* The specification document - give it a new title (without overlapping with
any other version indicator). I have moved away from using version numbers for
specifications I write, and am now advocating using dates or revisions instead.
* The authorization flow used to obtain an Access Token - we don't have a way
to indicate which flow is being used, and the oauth_version parameter was not
put in the specification for this (I know because I put it there). There are
two obvious ways to address this: use different endpoints (with optional
discovery) or add a new parameter (something like oauth_flow) and simply name
different flows (or different versions of flow) with different names.
* The authentication method - this is what the current oauth_version is for. It
provides a version for the combination of parameter used (nonce, timestamp,
signature method, signature, token, etc.), as well as how OAuth parameters are
encoded, transmitted, and verified.
* The signature method - each method has a name and if we ever want to change
them or add new ones, we simply give it a new name.
---
The Core 1.0 specification structure is shit. It completely blur the lines
between these 4 elements which is why most of you are misguided in advocating
for a version change. If you read my editor's cut version of the specification,
you'll see that the oauth_version parameter is clearly part of how to make an
authenticated OAuth request and not about how to get an Access Token. The fact
the current document title uses the same indicator ("1.0") as the version of
the authentication method is also not helping.
We need to address two changes:
* A new document - I think a simple "Revision A" in the title is enough to
indicate that the specification language has changed. If you feel this is not
enough please suggest a stronger language that is not a new version number. We
cannot increment the document version number without also incrementing the
parameter value or we will completely confuse everyone. In the future, there
will not be a new document called OAuth Core with a new numerical version
number (like OAuth 2.0). And before you go and argue, take a look at HTTP 1.1 -
it has multiple (different) specifications (RFCs) with the same protocol
version number and no one seems confused...
* A new authorization flow - we are basically adding a new workflow to replace
the existing 3-steps flow. It is very easy to identify which flow is being used
(see below) and there is no *need* to add an explicit indicator that a new flow
is being used by a client. For this reason I suggest we don't add anything new
at this point. I would like to look into this further in the future and find
better ways to support multiple authorization flows, but this is probably not
the time to address it.
To identify which flow a client is using:
1. Use two different endpoint URLs! Developers will have to go and make code
changes and if they use a library, will have to reconfigure it to indicate
which flow they are using. No application is expected to use both flows. This
means providers supporting multiple versions for some time as part of their
transition can simply use different endpoints for each revision. In the future,
discovery will make this automated - and this is the exact direction the
discovery work has been advocating for multiple flows.
2. Use the presence of an oauth_callback parameter as indicator which version
is being used. If you are not going to support dynamic callbacks see #1.
3. Add your own flag. This is pointless and wasteful but if it makes you feel
better...
---
If it wasn't clear, my vote is to give the specification a new title (Revision
A) and leave the oauth_version unchanged. Changing the version breaks stuff and
so far no one has demonstrated any *real* value in doing so. "Confusing" is not
a technical argument and this is an technical document.
EHL
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
