Subject: [OAUTH-WG] Versioning

From: Rob Richards <[email-masked]>
Date: Thu, 01 Jul 2010 06:26:18 -0400

Versioning is still something that needs to be addressed before being 
being able to consider the draft core complete.
On this I'm still of the opinion that at the very minimum you will need 
to require an oauth_version parameter for the resource endpoints, if not 
also for the others as well.

Rob

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 09:35:32 -0700

Hi Rob,

> -----Original Message-----
> From: Rob Richards [mailto:[email-masked]]
> Sent: Thursday, July 01, 2010 3:26 AM
> To: OAuth WG ([email-masked]); Eran Hammer-Lahav
> Subject: Versioning
> 
> Versioning is still something that needs to be addressed before being being
> able to consider the draft core complete.

Versioning rarely works because when you define it, you have no idea what the requirements will be for the next version. A good example is the OAuth 1.0 version parameter. When we worked to revised 1.0 into 1.0a, we had a long debate on changing the protocol version number. We had a hard time agreeing on what the version meant and what was it a version *of*: the signature method or the token flow.

If this protocol will require significant changes in the future that go beyond its extensibility support, such a new version will need to use different endpoints (token or end-user authorization) and/or different HTTP authentication scheme.

If you want to discuss versioning, you must provide your requirements for such a feature, and clearly show how they are not served by the current extensibility proposal.

> On this I'm still of the opinion that at the very minimum you will need to
> require an oauth_version parameter for the resource endpoints, if not also
> for the others as well.

I think the difficulty of differentiating a 1.0 from a 2.0 protected resource request is exaggerated. As said before, you can tell the difference based on the presence of other parameter (oauth_signature_method), or by examining the provided token (assuming you issue different tokens for each version). The argument that a 2.0 request can also be a malformed 1.0 request is silly. I have yet to hear about that level of incompetence for a 1.0 developer (and I've heard about a lot) - omitting every other required parameter.

At most, I'm open to renaming the oauth_token parameter to something else (oauth_access_token, oauth.token, oauth-token, etc.) but I think even that is not needed.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 10:37:07 -0700

> If this protocol will require significant changes in the future that go beyond its extensibility support, such a new version will need to use different endpoints (token or end-user authorization) a…

I don't think the authz server endpoints are an issue, but the
protected resources. The auth scheme is very generic, "Token". So
either the scheme should be more specific, like "OAuth2", or a version
should be added as a parameter. Maybe a token type as Dick suggested.

Marius

---

From: "William Mills" <[email-masked]>
Date: Thu, 1 Jul 2010 10:49:18 -0700

My feeling on this is that versioning explicitly in the protocol adds
clarity and some small level of compatibility.  Different auth and token
endpoints are easy, what's harder is supporting multiple protocols on
the same protected resource.  It's on the protected resource I'd like to
see some clearer protocol version spec so I'm not having to figure out
from the variable names which protocol it is.

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Eran Hammer-Lahav
> Sent: Thursday, July 01, 2010 9:36 AM
> To: Rob Richards; OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Versioning
> 
> Hi Rob,
> 
> Versioning rarely works because when you define it, you have 
> no idea what the requirements will be for the next version. A 
> good example is the OAuth 1.0 version parameter. When we 
> worked to revised 1.0 into 1.0a, we had a long debate on 
> changing the protocol version number. We had a hard time 
> agreeing on what the version meant and what was it a version 
> *of*: the signature method or the token flow.
> 
> If this protocol will require significant changes in the 
> future that go beyond its extensibility support, such a new 
> version will need to use different endpoints (token or 
> end-user authorization) and/or different HTTP authentication scheme.
> 
> If you want to discuss versioning, you must provide your 
> requirements for such a feature, and clearly show how they 
> are not served by the current extensibility proposal.
> 
> > On this I'm still of the opinion that at the very minimum you will 
> > need to require an oauth_version parameter for the resource 
> endpoints, 
> > if not also for the others as well.
> 
> I think the difficulty of differentiating a 1.0 from a 2.0 
> protected resource request is exaggerated. As said before, 
> you can tell the difference based on the presence of other 
> parameter (oauth_signature_method), or by examining the 
> provided token (assuming you issue different tokens for each 
> version). The argument that a 2.0 request can also be a 
> malformed 1.0 request is silly. I have yet to hear about that 
> level of incompetence for a 1.0 developer (and I've heard 
> about a lot) - omitting every other required parameter.
> 
> At most, I'm open to renaming the oauth_token parameter to 
> something else (oauth_access_token, oauth.token, oauth-token, 
> etc.) but I think even that is not needed.
> 
> EHL
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "William Mills" <[email-masked]>
Date: Thu, 1 Jul 2010 10:51:26 -0700

+1
> I don't think the authz server endpoints are an issue, but 
> the protected resources. The auth scheme is very generic, 
> "Token". So either the scheme should be more specific, like 
> "OAuth2", or a version should be added as a parameter. Maybe 
> a token type as Dick suggested.

> On Behalf Of Marius Scurtescu
> Sent: Thursday, July 01, 2010 10:37 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> > Versioning rarely works because when you define it, you 
> have no idea what the requirements will be for the next 
> version. A good example is the OAuth 1.0 version parameter. 
> When we worked to revised 1.0 into 1.0a, we had a long debate 
> on changing the protocol version number. We had a hard time 
> I don't think the authz server endpoints are an issue, but 
> the protected resources. The auth scheme is very generic, 
> "Token". So either the scheme should be more specific, like 
> "OAuth2", or a version should be added as a parameter. Maybe 
> a token type as Dick suggested.
> 
> Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 10:56:52 -0700

> From: Marius Scurtescu [mailto:[email-masked]]
> Cc: Rob Richards; OAuth WG ([email-masked])
> > Versioning rarely works because when you define it, you have no idea
> what the requirements will be for the next version. A good example is the
> OAuth 1.0 version parameter. When we worked to revised 1.0 into 1.0a, we
> had a long debate on changing the protocol version number. We had a hard
> time agreeing on what the version meant and what was it a version *of*: the
> signature method or the token flow.
> >
> > If this protocol will require significant changes in the future that go beyond
> its extensibility support, such a new version will need to use different
> endpoints (token or end-user authorization) and/or different HTTP
> authentication scheme.
> 
> I don't think the authz server endpoints are an issue, but the protected
> resources. The auth scheme is very generic, "Token". So either the scheme
> should be more specific, like "OAuth2", or a version should be added as a
> parameter. Maybe a token type as Dick suggested.

HTTP Basic has no version, and I believe Digest doesn't have a version either (though it has been revised from 2069 to 2617). The Token scheme is generic, but also wide open. The only required parameter is 'token' (which makes sense for a Token scheme). I can't come up with a single requirement that would require an explicit version parameter.

Version discussions are almost always a waste of time because at the time they are debated, no one knows what the requirement for such a feature will be. Versioning usually makes sense in a follow-up revision where the protocol needs a way to differentiate itself from the previous version.

If anyone wants to propose a versioning of any parts of this protocol, they must present specific objectives. The vague objective of "allow future versions" isn't valid because it has failed for 1.0 (and many other protocols). Instead, I suggest people pay more attention to the extensibility and ensure that it offers enough support for future needs, without having the change the protocol.

We tried adding version support in OAuth 1.0 and failed. The version parameter does not help in any real way, is incompletely, and poorly defined. The quality of this new discussion is as low as that of the 1.0 attempt. Let's learn from our mistakes.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 10:59:58 -0700

Why is a version better than a new scheme name? Version is only helpful when the protocol is practically the same with some minor changes, and if that is the case, extensibility alone should be enough.

EHL 

> From: William Mills [mailto:[email-masked]]
> Sent: Thursday, July 01, 2010 10:49 AM
> To: Eran Hammer-Lahav; Rob Richards; [email-masked]
> Subject: RE: [OAUTH-WG] Versioning
> 
> My feeling on this is that versioning explicitly in the protocol adds clarity and
> some small level of compatibility.  Different auth and token endpoints are
> easy, what's harder is supporting multiple protocols on the same protected
> resource.  It's on the protected resource I'd like to see some clearer protocol
> version spec so I'm not having to figure out from the variable names which
> protocol it is.
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Eran Hammer-Lahav
> > what the requirements will be for the next version. A good example is
> > the OAuth 1.0 version parameter. When we worked to revised 1.0 into
> > 1.0a, we had a long debate on changing the protocol version number. We
> > had a hard time agreeing on what the version meant and what was it a
> > version
> > If this protocol will require significant changes in the future that
> > go beyond its extensibility support, such a new version will need to
> > use different endpoints (token or end-user authorization) and/or
> > different HTTP authentication scheme.
> >
> > If you want to discuss versioning, you must provide your requirements
> > for such a feature, and clearly show how they are not served by the
> > current extensibility proposal.
> >
> > I think the difficulty of differentiating a 1.0 from a 2.0 protected
> > resource request is exaggerated. As said before, you can tell the
> > difference based on the presence of other parameter
> > (oauth_signature_method), or by examining the provided token (assuming
> > you issue different tokens for each version). The argument that a 2.0
> > request can also be a malformed 1.0 request is silly. I have yet to
> > hear about that level of incompetence for a 1.0 developer (and I've
> > heard about a lot) - omitting every other required parameter.
> >
> > At most, I'm open to renaming the oauth_token parameter to something
> > else (oauth_access_token, oauth.token, oauth-token,

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 11:07:38 -0700

I was told that my last paragraph was greatly insulting. I want to apologize if it came off that way or if anyone perceived it as directed at them. I think the quality of the discussion about version for the past year has been of low quality. People did not present requirements or shows an actual need for versions, as well as lacked detail as to what is being versioned. The only argument made is that "it seems like a useful thing".

Again, please don't take my comments to imply anything personal and I am sorry for my tone.

EHL

> Sent: Thursday, July 01, 2010 10:57 AM
> To: Marius Scurtescu
> > On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav
> > <[email-masked]>
> > wrote:
> > > Hi Rob,
> > >
> > >> Versioning is still something that needs to be addressed before
> > >> being being able to consider the draft core complete.
> > >
> > version *of*: the signature method or the token flow.
> > >
> > > go beyond
> > its extensibility support, such a new version will need to use
> > different endpoints (token or end-user authorization) and/or different
> > HTTP authentication scheme.
> >
> HTTP Basic has no version, and I believe Digest doesn't have a version either
> (though it has been revised from 2069 to 2617). The Token scheme is generic,
> but also wide open. The only required parameter is 'token' (which makes
> sense for a Token scheme). I can't come up with a single requirement that
> would require an explicit version parameter.
> 
> Version discussions are almost always a waste of time because at the time
> they are debated, no one knows what the requirement for such a feature
> will be. Versioning usually makes sense in a follow-up revision where the
> protocol needs a way to differentiate itself from the previous version.
> 
> If anyone wants to propose a versioning of any parts of this protocol, they
> must present specific objectives. The vague objective of "allow future
> versions" isn't valid because it has failed for 1.0 (and many other protocols).
> Instead, I suggest people pay more attention to the extensibility and ensure
> that it offers enough support for future needs, without having the change
> the protocol.
> 
> We tried adding version support in OAuth 1.0 and failed. The version
> parameter does not help in any real way, is incompletely, and poorly defined.
> The quality of this new discussion is as low as that of the 1.0 attempt. Let's
> learn from our mistakes.
> 
> EHL
>

---

From: "William Mills" <[email-masked]>
Date: Thu, 1 Jul 2010 11:08:20 -0700

Why is using the string "Token" better than "OAuth2"?  1.0 used "Oauth".

If it's purely a question of aesthetics, I prefer "Oauth_2" to "Token"
because I feel it's clearer and more descriptive. 

> From: Eran Hammer-Lahav [mailto:[email-masked]] 
> Sent: Thursday, July 01, 2010 11:00 AM
> To: William Mills; Rob Richards; [email-masked]
> Why is a version better than a new scheme name? Version is 
> only helpful when the protocol is practically the same with 
> some minor changes, and if that is the case, extensibility 
> alone should be enough.
> 
> EHL 
> 
> > clarity and some small level of compatibility.  Different auth and 
> > token endpoints are easy, what's harder is supporting multiple 
> > protocols on the same protected resource.  It's on the protected 
> > resource I'd like to see some clearer protocol version spec 
> so I'm not 
> > having to figure out from the variable names which protocol it is.
> > 
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Eran Hammer-Lahav
> have no idea 
> > > what the requirements will be for the next version. A 
> good example 
> > > is the OAuth 1.0 version parameter. When we worked to revised 1.0 
> > > into 1.0a, we had a long debate on changing the protocol version 
> > > number. We had a hard time agreeing on what the version meant and 
> > > what was it a version
> future that 
> > > requirements for such a feature, and clearly show how 
> they are not 
> > > served by the current extensibility proposal.
> > >
> > > (oauth_signature_method), or by examining the provided token 
> > > (assuming you issue different tokens for each version). 
> The argument 
> > > that a 2.0 request can also be a malformed 1.0 request is 
> silly. I 
> > > have yet to hear about that level of incompetence for a 1.0 
> > > developer (and I've heard about a lot) - omitting every 
> other required parameter.
> > >

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 11:16:15 -0700

On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> Why is a version better than a new scheme name?

Sure, but then make the scheme more specific. What will the scheme
name be for OAuth 3?

When tokens are passed in the query string there is no scheme.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 11:19:48 -0700

I think HTTP authentication schemes should be generally useful. In this case, OAuth defines a few ways to obtain an token, and a few ways to use a token with HTTP resources. What it doesn't do is say anything useful about the token itself, or implies that the tokens are "OAuth tokens" (i.e. that the nature of the token is bound to the OAuth protocol).

I can envision use cases where someone wants to use existing tokens (obtained via other means than those provided by OAuth) to access protected resources. What about using a token as currently defined is OAuth-specific?

In other words, the scheme name is generic because OAuth tokens are generic and for the most part left undefined. Naming the scheme OAuth implies that there is a link between the token properties and how they are obtained, and the current protocol does not specify any such link. The same applies to using HTTP Basic for client credentials, not to log-in an end-user.

EHL

> Sent: Thursday, July 01, 2010 11:08 AM
> > Why is a version better than a new scheme name? Version is only
> > helpful when the protocol is practically the same with some minor
> > changes, and if that is the case, extensibility alone should be
> > enough.
> >
> > EHL
> >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 11:24:18 -0700

> Sent: Thursday, July 01, 2010 11:16 AM
> To: Eran Hammer-Lahav
> Cc: William Mills; Rob Richards; [email-masked]
> Sure, but then make the scheme more specific. What will the scheme name
> be for OAuth 3?

I don't think there should be a new scheme for OAuth 3. The only reason why we need to define a new scheme for OAuth 2 is that we so poorly defined the header for 1.0 and made it unworkable for new requirements. Reusing the OAuth scheme from 1.0 would result in something closer to a hack than a properly designed protocol, and the current cost of a new scheme is largely negligible.

If you would like to discuss a version for the header, please provide examples and requirements for what changes in the future you would like to support.

EHL

> >> resource I'd like to see some clearer protocol version spec so I'm
> >> not having to figure out from the variable names which protocol it is.
> >>
> >> > Versioning rarely works because when you define it, you have no
> >> > idea what the requirements will be for the next version. A good
> >> > example is the OAuth 1.0 version parameter. When we worked to
> >> > revised 1.0 into 1.0a, we had a long debate on changing the
> >> > protocol version number. We had a hard time agreeing on what the
> >> > version meant and what was it a version
> >> > If this protocol will require significant changes in the future
> >> > that go beyond its extensibility support, such a new version will
> >> > need to use different endpoints (token or end-user authorization)
> >> > and/or different HTTP authentication scheme.
> >> >
> >> > requirements for such a feature, and clearly show how they are not
> >> > > On this I'm still of the opinion that at the very minimum you
> >> > > will need to require an oauth_version parameter for the resource
> >> > endpoints,
> >> > protected resource request is exaggerated. As said before, you can
> >> > tell the difference based on the presence of other parameter
> >> > (assuming you issue different tokens for each version). The
> >> > argument that a 2.0 request can also be a malformed 1.0 request is
> >> > silly. I have yet to hear about that level of incompetence for a
> >> > 1.0 developer (and I've heard about a lot) - omitting every other
> required parameter.
> >> >

---

From: "William Mills" <[email-masked]>
Date: Thu, 1 Jul 2010 11:25:25 -0700

+1 on this.  Makes life interesting on the PR.

> Sure, but then make the scheme more specific. What will the 
> scheme name be for OAuth 3?
> 
> >> > 1.0 developer (and I've heard about a lot) - omitting 
> every other required parameter.
> >> >

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 11:28:06 -0700

> In other words, the scheme name is generic because OAuth tokens are generic and for the most part left undefined. Naming the scheme OAuth implies that there is a link between the token properties a…

Sure, but then I think the "Token" scheme needs its own standalone
spec and not be defined as part of the OAuth 2 spec.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 11:35:38 -0700

> If you would like to discuss a version for the header, please provide examples and requirements for what changes in the future you would like to support.

Not sure about the future, but looking at OAuth 1 vs OAuth 2. A
protected resource request filter may want to decide early what
protocol it deals with so it can call the appropriate handler, or to
enforce HTTPS for OAuth 2 for example. Sure, it can apply heuristics
right now, but it would be nice to have a more deterministic way which
can also be extended in the future. You can always embed the protocol
version inside the token I guess, so I don't think this is a huge
issue.

I was not part of the 1.0 vs 1.0a discussions, so not sure what was
the conclusion there.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 11:42:05 -0700

It was and this approach was rejected by this group as confusing. At this point, it's specification is so short, it can live anywhere.

EHL

> Sent: Thursday, July 01, 2010 11:28 AM
> To: Eran Hammer-Lahav
> > I think HTTP authentication schemes should be generally useful. In this
> case, OAuth defines a few ways to obtain an token, and a few ways to use a
> token with HTTP resources. What it doesn't do is say anything useful about
> the token itself, or implies that the tokens are "OAuth tokens" (i.e. that the
> nature of the token is bound to the OAuth protocol).
> >
> > I can envision use cases where someone wants to use existing tokens
> (obtained via other means than those provided by OAuth) to access
> protected resources. What about using a token as currently defined is
> OAuth-specific?
> >
> > In other words, the scheme name is generic because OAuth tokens are
> generic and for the most part left undefined. Naming the scheme OAuth
> implies that there is a link between the token properties and how they are
> obtained, and the current protocol does not specify any such link. The same
> applies to using HTTP Basic for client credentials, not to log-in an end-user.
> 
> Sure, but then I think the "Token" scheme needs its own standalone spec
> and not be defined as part of the OAuth 2 spec.
> 
> Marius
> 
> >
> > EHL
> >
> >> > > clarity and some small level of compatibility.  Different auth
> >> > > and token endpoints are easy, what's harder is supporting
> >> > > multiple protocols on the same protected resource.  It's on the
> >> > > protected resource I'd like to see some clearer protocol version
> >> > > spec
> >> > so I'm not
> >> > > > is the OAuth 1.0 version parameter. When we worked to revised
> >> > > > 1.0 into 1.0a, we had a long debate on changing the protocol
> >> > > > version number. We had a hard time agreeing on what the version
> >> > > > meant and what was it a version
> >> > > > use different endpoints (token or end-user authorization)
> >> > > > resource request is exaggerated. As said before, you can tell
> >> > > > the difference based on the presence of other parameter

---

From: Rob Richards <[email-masked]>
Date: Thu, 01 Jul 2010 14:42:58 -0400

> Version discussions are almost always a waste of time because at the time they are debated, no one knows what the requirement for such a feature will be. Versioning usually makes sense in a follow-…
Exactly. While it might be needed in the future, there is a need to 
differentiate OAuth 1.0 from 2.0 on resource endpoints right now. 
Outside of requiring an oauth_version parameter (or equivalent) all 
other suggestions leave versioning as a grey area, where things can be 
interpreted one way or another with no consistency. Grey areas in specs 
are a bad thing. You end up with different languages/libraries dealing 
with things in completely different and incompatible ways because 
something was not clearly spelled out.

Rob

---

From: "William Mills" <[email-masked]>
Date: Thu, 1 Jul 2010 11:42:02 -0700

> Sent: Thursday, July 01, 2010 11:36 AM
> To: Eran Hammer-Lahav
> > If you would like to discuss a version for the header, 
> please provide examples and requirements for what changes in 
> the future you would like to support.
> 
> Not sure about the future, but looking at OAuth 1 vs OAuth 2. 
> A protected resource request filter may want to decide early 
> what protocol it deals with so it can call the appropriate 
> handler, or to enforce HTTPS for OAuth 2 for example. Sure, 
> it can apply heuristics right now, but it would be nice to 
> have a more deterministic way which can also be extended in 
> the future. You can always embed the protocol version inside 
> the token I guess, so I don't think this is a huge issue.

Yeah, unfortunately early selection of a handler might require peeking into the post body.  

> 
> I was not part of the 1.0 vs 1.0a discussions, so not sure 
> what was the conclusion there.
> 
> Marius
> 
> >
> > EHL
> >
> >> >> My feeling on this is that versioning explicitly in the 
> protocol 
> >> >> adds clarity and some small level of compatibility.  Different 
> >> >> auth and token endpoints are easy, what's harder is supporting 
> >> >> spec so I'm not having to figure out from the variable 
> names which protocol it is.
> >> >>
> >> >> > that go beyond its extensibility support, such a new version 
> >> >> > will need to use different endpoints (token or end-user 
> >> >> > authorization) and/or different HTTP authentication scheme.
> >> >> >
> they are 
> >> >> > not served by the current extensibility proposal.
> >> >> >
> >> >> > protected resource request is exaggerated. As said 
> before, you 
> >> >> > can tell the difference based on the presence of 
> other parameter 
> >> >> > argument that a 2.0 request can also be a malformed 
> 1.0 request 
> >> >> > is silly. I have yet to hear about that level of incompetence 
> >> >> > for a 1.0 developer (and I've heard about a lot) - omitting 
> >> >> > every other
> >> required parameter.
> >> >> >

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 11:47:19 -0700

> Yeah, unfortunately early selection of a handler might require peeking into the post body.

Is anybody really using or needing this feature? Can we drop this option?

Marius

---

From: "William Mills" <[email-masked]>
Date: Thu, 1 Jul 2010 11:46:16 -0700

Perhaps it's enough if in the spec we make clear that we are also defining a scheme usable for other things.  I don't think that's quite spelled out.  Then other specs just refer to the specific section like we're pulling in the WWW-Authenticate part from another spec. 

> Sent: Thursday, July 01, 2010 11:42 AM
> To: Marius Scurtescu
> It was and this approach was rejected by this group as 
> confusing. At this point, it's specification is so short, it 
> can live anywhere.
> 
> EHL
> 
> > > I think HTTP authentication schemes should be generally 
> useful. In 
> > > this
> > case, OAuth defines a few ways to obtain an token, and a 
> few ways to 
> > use a token with HTTP resources. What it doesn't do is say anything 
> > useful about the token itself, or implies that the tokens 
> are "OAuth 
> > tokens" (i.e. that the nature of the token is bound to the 
> OAuth protocol).
> > >
> > implies that there is a link between the token properties 
> and how they 
> > are obtained, and the current protocol does not specify any 
> such link. 
> > The same applies to using HTTP Basic for client 
> credentials, not to log-in an end-user.
> > 
> Version is only 
> > >> > protocol adds
> > >> > > protected resource I'd like to see some clearer protocol 
> > >> > > version spec
> > >> > so I'm not
> > >> > > > version number. We had a hard time agreeing on what the

---

From: Justin Richer <[email-masked]>
Date: Thu, 1 Jul 2010 14:49:36 -0400

An easy fix here is to use oauth2_token instead of oauth_token here,
since that's the only place we seem to be using the oauth_ namespace
now. Makes figuring out the two completely deterministic since it's a
different parameter name when passed as a GET or POST variable, and a
different header name when passed as a header (using the current Token
scheme or an OAuth2 scheme or whatever).

 -- Justin

On Thu, 2010-07-01 at 14:25 -0400, William Mills wrote:
> > before, you can

---

From: Justin Richer <[email-masked]>
Date: Thu, 1 Jul 2010 15:07:15 -0400

OAuth tokens as a form-encoded element in a post body? Yes. Keep it.

 -- Justin

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 12:25:54 -0700

> OAuth tokens as a form-encoded element in a post body? Yes. Keep it.

Just curious. What use case would require that the access token is put
in the post body as opposed to an http header when accessing a
protected resource?

Marius

---

From: Rob Richards <[email-masked]>
Date: Thu, 01 Jul 2010 15:28:52 -0400

With this the spec needs to including some wording to explicitly define 
how to handle the case when running an endpoint supporting both OAuth 
1.0 and 2.0 and the oauth2_token is missing then the call is handled 
according to the OAuth 1.0/a spec. Whatever is decided, be it a version 
parameter, the use of oauth2_token or the check for the existence of the 
oauth_signature_method parameter, etc///, the spec needs to define and 
be explicit on how a resource endpoint determines between a 1.0 and 2.0 
call when both are supported.

Rob

Justin Richer wrote:
>>>>> not having to figure out from the variable names which 
>>>>>           
>>> protocol it is.
>>>       
>>>>>>> Versioning is still something that needs to be addressed
>>>>>>>               
>>>>>> before being
>>>>>>             
>>>>>> that go beyond its extensibility support, such a new 
>>>>>>             
>>> version will 
>>>       
>>>>>> need to use different endpoints (token or end-user 
>>>>>>             
>>> authorization) 
>>>       
>>>>>>> will need to require an oauth_version parameter for 
>>>>>>>               
>>> the resource
>>>       
>>>>>> endpoints,
>>>>>>             
>>>>>> argument that a 2.0 request can also be a malformed 1.0 
>>>>>>             
>>> request is 
>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 1 Jul 2010 15:38:50 -0400

> in the post body as opposed to an http header when accessing a

If nothing else, it parallels the use case of a GET-style query
parameter. It makes sense to have it be valid in both ways to allow
developers to put the token in with whatever other parameters they're
passing along. I've got plenty of use cases here for the query
parameters: it's needed for cases where your client can't get any deeper
into HTTP than "hey go fetch me this URL". 

What use case says we shouldn't do POST parameters like that? A server
wanting to do early-dispatch of a request was brought up, but that was
only in the case of handling OAuth 1 and 2 simultaneously as I
understood it. If a server's going to be doing dispatch on auth headers
and query parameters already, it seems that it's got the wherewithal to
parse a form-encoded body, too.

 -- Justin

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 12:47:41 -0700

> into HTTP than "hey go fetch me this URL".

You can still use query parameters with POST.

> parse a form-encoded body, too.

Parsing the body is not trivial. Some filters do not have access to it
(apache mod_redirect for example), some frameworks will allow you to
access it once and then commit to a format, a decision that cannot be
made by a filter (in Java see ServletRequest: getInputStream vs
getReader vs getParameter).

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 13:18:01 -0700

The rest of the parameters being in the body.

EHL

> Of Marius Scurtescu
> Sent: Thursday, July 01, 2010 12:26 PM
> To: Justin Richer
> Cc: [email-masked]
> Just curious. What use case would require that the access token is put in the
> post body as opposed to an http header when accessing a protected
> resource?
> 
> Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 14:24:25 -0700

[Replying to everything at once...]

> Not sure about the future, but looking at OAuth 1 vs OAuth 2. A protected
> resource request filter may want to decide early what protocol it deals with
> so it can call the appropriate handler, or to enforce HTTPS for OAuth 2 for
> example. Sure, it can apply heuristics right now, but it would be nice to have
> a more deterministic way which can also be extended in the future. You can
> always embed the protocol version inside the token I guess, so I don't think
> this is a huge issue.

First, this is limited to non-header methods. Look for 'oauth_signature_method'.

If it is not there, assume this is a 2.0 request. I don't buy the suggestion that in practice, developers are likely to omit *this* parameter in a malformed 1.0 requests. If an existing 1.0 provider can demonstrate how this is a problem from experience, I might reconsider.

> I was not part of the 1.0 vs 1.0a discussions, so not sure what was the
> conclusion there.

The conclusion was that beyond "this sounds like a good idea" we didn't know what the heck we were doing. Blaine at the time strongly opposed it and lost the argument to me. Since the 1.0a discussions, I have changed my view and am no decidedly against version parameters because they are impossible to design.

> Sent: Thursday, July 01, 2010 11:43 AM

> Outside of requiring an oauth_version parameter (or equivalent) all other
> suggestions leave versioning as a grey area, where things can be interpreted
> one way or another with no consistency. Grey areas in specs are a bad thing.
> You end up with different languages/libraries dealing with things in
> completely different and incompatible ways because something was not
> clearly spelled out.

This is an area that is clearly on the server side, not the client. Since the core specification leaves discovery out, client developers need to know what version of OAuth is supported by the server and use the right one. Without discovery, the client must know ahead of time what to do. With discovery, the client can choose the right protocol. Either way, the client never just sends a 1.0 or 2.0 requests and hopes for the best.

On the server side, the challenge isn't that significant. When not using a header, the server can use multiple methods to differentiate the version used by the client:

1. Token syntax
2. Presence of 'oauth_signature_method'
3. Presence of 'oauth_signature'
4. Presence of no other 'oauth_' parameter than 'oauth_token'

> With this the spec needs to including some wording to explicitly define how
> to handle the case when running an endpoint supporting both OAuth
> 1.0 and 2.0 and the oauth2_token is missing then the call is handled according
> to the OAuth 1.0/a spec. Whatever is decided, be it a version parameter, the
> use of oauth2_token or the check for the existence of the
> be explicit on how a resource endpoint determines between a 1.0 and 2.0 call
> when both are supported.

The damage done by interpreting a malformed 1.0 request (the odd attempt to use 1.0 by only including 'oauth_token') is at most returning an 'invalid-token' response. I hope every server developer understands that they should not share tokens between 1.0 and 2.0 with completely different security properties.

I think there are more issue with regard to 1.0 to 2.0 migration that should be addressed, and I have asked those who care about this to propose a draft. Given that such a draft will not be useful for a long time, given that the vast majority of OAuth implementation 1-2 years from now will be 2.0, I do not want to include it in the core specification.

In order for your argument to stand, you need to show how the current setup leads to interoperability problems. Given the 4 options above, and the fact that a malformed 1.0 request will still fail, I do not agree that interop is affected.

> From: Justin Richer [mailto:[email-masked]]
> Sent: Thursday, July 01, 2010 11:50 AM

> An easy fix here is to use oauth2_token instead of oauth_token here, since
> that's the only place we seem to be using the oauth_ namespace now.
> Makes figuring out the two completely deterministic since it's a different
> parameter name when passed as a GET or POST variable, and a different
> header name when passed as a header (using the current Token scheme or
> an OAuth2 scheme or whatever).

Yes, we can rename the 'oauth_token' parameter to something else. I might be included to support such an idea but not to 'oauth2_token', but to something that would use the same parameter name across the header and query/body. At the same time, I consider using the query/body parameters as hacks so I'm generally not sympathetic to changes there.

EHL

---

From: "William Mills" <[email-masked]>
Date: Thu, 1 Jul 2010 14:36:09 -0700

In re:

	1. Token syntax

We can certainly do better than this.  Yeah, the server should be smart
enough, but this seems unneccesary when we could be a lot simpler.

Can we require the presence of the Authorization header with "Token",
and if nothing else is there you have to go to the query params or post
body?

> Sent: Thursday, July 01, 2010 2:24 PM
> To: [email-masked]
> > version inside the token I guess, so I don't think this is 
> a huge issue.
> 
> If it is not there, assume this is a 2.0 request. I don't buy 
> the suggestion that in practice, developers are likely to 
> omit *this* parameter in a malformed 1.0 requests. If an 
> existing 1.0 provider can demonstrate how this is a problem 
> from experience, I might reconsider.
> 
> The conclusion was that beyond "this sounds like a good idea" 
> we didn't know what the heck we were doing. Blaine at the 
> time strongly opposed it and lost the argument to me. Since 
> the 1.0a discussions, I have changed my view and am no 
> decidedly against version parameters because they are 
> impossible to design.
> 
> 
> > interpreted one way or another with no consistency. Grey 
> areas in specs are a bad thing.
> This is an area that is clearly on the server side, not the 
> client. Since the core specification leaves discovery out, 
> client developers need to know what version of OAuth is 
> supported by the server and use the right one. Without 
> discovery, the client must know ahead of time what to do. 
> With discovery, the client can choose the right protocol. 
> Either way, the client never just sends a 1.0 or 2.0 requests 
> and hopes for the best.
> 
> On the server side, the challenge isn't that significant. 
> When not using a header, the server can use multiple methods 
> to differentiate the version used by the client:
> 
> 1. Token syntax
> > With this the spec needs to including some wording to explicitly 
> > define how to handle the case when running an endpoint 
> supporting both 
> > OAuth 1.0 and 2.0 and the oauth2_token is missing then the call is 
> > handled according to the OAuth 1.0/a spec. Whatever is 
> decided, be it 
> > a version parameter, the use of oauth2_token or the check for the 
> > existence of the oauth_signature_method parameter, etc///, the spec 
> > needs to define and be explicit on how a resource endpoint 
> determines 
> > between a 1.0 and 2.0 call when both are supported.
> 
> The damage done by interpreting a malformed 1.0 request (the 
> odd attempt to use 1.0 by only including 'oauth_token') is at 
> most returning an 'invalid-token' response. I hope every 
> server developer understands that they should not share 
> tokens between 1.0 and 2.0 with completely different security 
> properties.
> 
> I think there are more issue with regard to 1.0 to 2.0 
> migration that should be addressed, and I have asked those 
> who care about this to propose a draft. Given that such a 
> draft will not be useful for a long time, given that the vast 
> majority of OAuth implementation 1-2 years from now will be 
> 2.0, I do not want to include it in the core specification.
> 
> In order for your argument to stand, you need to show how the 
> current setup leads to interoperability problems. Given the 4 
> options above, and the fact that a malformed 1.0 request will 
> still fail, I do not agree that interop is affected.
> 
> 
> > since that's the only place we seem to be using the oauth_ 
> namespace now.
> > Makes figuring out the two completely deterministic since it's a 
> Yes, we can rename the 'oauth_token' parameter to something 
> else. I might be included to support such an idea but not to 
> 'oauth2_token', but to something that would use the same 
> parameter name across the header and query/body. At the same 
> time, I consider using the query/body parameters as hacks so 
> I'm generally not sympathetic to changes there.
> 
> EHL
> 
> 
> 
> 
>

---

From: "William Mills" <[email-masked]>
Date: Thu, 1 Jul 2010 14:40:24 -0700

I'm also fine with a note in the spec that says, something like "If you
need to support 1.0a and 2 on the same protected resource it is
RECOMMENDED that you always use the Authorization header variant." 

> On Behalf Of William Mills
> Sent: Thursday, July 01, 2010 2:36 PM
> To: Eran Hammer-Lahav; [email-masked]
> We can certainly do better than this.  Yeah, the server 
> should be smart enough, but this seems unneccesary when we 
> could be a lot simpler.
> 
> Can we require the presence of the Authorization header with 
> "Token", and if nothing else is there you have to go to the 
> query params or post body?
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Eran Hammer-Lahav
> > If it is not there, assume this is a 2.0 request. I don't buy the 
> > suggestion that in practice, developers are likely to omit *this* 
> > parameter in a malformed 1.0 requests. If an existing 1.0 
> provider can 
> > demonstrate how this is a problem from experience, I might 
> reconsider.
> > 
> > we didn't know what the heck we were doing. Blaine at the time 
> > strongly opposed it and lost the argument to me. Since the 1.0a 
> > discussions, I have changed my view and am no decidedly against 
> > version parameters because they are impossible to design.
> > 
> >

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 2 Jul 2010 12:21:13 +1000

> Why is a version better than a new scheme name?

YAY!
Using a new scheme name if/when we aren't using a bearer token is a great idea.

Today OAuth2 only defines how to access a protected resource with a bearer token [the "Token" scheme in section 5]. Assume this is standardized soon, then in 3 years time a MAC-based mechanism is defined. There is no way it would reuse the existing "Token" scheme by giving it totally different semantics -- in much the same way no one considered reusing the "BASIC" scheme to hold a nonce/timestamp/alg/signature. A new mechanism would simply pick its own scheme name, eg "MAC".

OAuth2 can easily prepare for this today by explicitly indicating which scheme a token is designed to be used with when it is issued. That is, include a "scheme" parameter in an access token response.

     {
       "access_token":"SlAV32hkKG",
       "scheme":"Token",
       "expires_in":3600,
       "refresh_token":"8xLOxBtZp8"
     }

The spec would say: "A client app MUST support the "Token" scheme"; "A client app MUST NOT use a token response if it does not support the listed scheme".

[We could make "scheme":"Token" the default if absent, but I think it is better to be explicit.]

Changing the scheme name from "Token" to, say, "Bearer" would help.

I also support changing the query parameter name from "oauth_token". How about "_authz"?
We want authentication/authorization to be orthogonal to the rest of the API. When we can't use the separate "Authorization" header for this purpose we need a parameter name that is somehow "orthogonal" to any params that are part of the API being protected. Starting the param name with "_" is a decent way to suggest this orthogonality to other "normal" API params. Suggestions: "_authz" or "_authz_bearer" (or "_authz_token" if the "Token" scheme is not renamed).

Eran argued that the "Token" scheme name deliberately does not include the "OAuth" label to be generic: it can hold a token obtained in any way, not necessarily using an OAuth flow. With this logic, the URI query parameter name holding a bearer token should also avoid the "OAuth" label. It is simply a URI-query variant of the HTTP "Token" scheme.

-- 
James Manger

---

From: Rob Richards <[email-masked]>
Date: Fri, 02 Jul 2010 07:04:37 -0400

> 4. Presence of no other 'oauth_' parameter than 'oauth_token'

Never said this was hard just that it needs to be documented.
> The damage done by interpreting a malformed 1.0 request (the odd attempt to use 1.0 by only including 'oauth_token') is at most returning an 'invalid-token' response. I hope every server developer…
Still the issue that different error codes returned which a client may 
handle differently.
> In order for your argument to stand, you need to show how the current setup leads to interoperability problems. Given the 4 options above, and the fact that a malformed 1.0 request will still fail,…
OAuth is a service that my company provides to other companies and we 
will need to run both versions in parallel for many of the customers. 
There are other companies out there who provide similar service, so this 
isn't just an isolated problem. We may be transitioning customers 
to/from our service and the behaviors of the systems need to be the same 
pre and post migration.
There is also the WTF factor for developers. If I make calls to 2 
providers (1.0 client), each of which is missing the oauth_signature, I 
would expect the same response back. An error that its missing a 
required signature. If one of the providers interprets a missing 
signature as meaning the call is a 2.0 based call then it will return 
back a different error code.

I would expect that if I implemented 2 independent systems based on a 
spec they would operate and behave the exact same way, otherwise you can 
just throw the spec in the pile with the rest of them that have 
ambiguous sections left to interpretation and cause for argument over 
who implemented what correctly in their system.

Rob

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Jul 2010 07:38:55 -0700

Hi Rob,

I agree with you that a migration spec is important - please write one.

As for every provider returning the same error code, I don't think that this will always be the case as some providers will return invalid-request on other security related errors to reduce the amount of information they return, or because they support different extensions, etc. The fact that both request fail is really the only significant consistency needed.

I don't agree that the 2.0 core specification needs to cover 1.0 issues. That includes migrating from 1.0 to 2.0, supporting both, etc.

EHL

> Sent: Friday, July 02, 2010 4:05 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> >> other suggestions leave versioning as a grey area, where things can
> >> be interpreted one way or another with no consistency. Grey areas in
> specs are a bad thing.
> > This is an area that is clearly on the server side, not the client. Since the
> core specification leaves discovery out, client developers need to know what
> version of OAuth is supported by the server and use the right one. Without
> discovery, the client must know ahead of time what to do. With discovery,
> the client can choose the right protocol. Either way, the client never just
> sends a 1.0 or 2.0 requests and hopes for the best.
> >
> > On the server side, the challenge isn't that significant. When not using a
> header, the server can use multiple methods to differentiate the version
> used by the client:
> >
> > 1. Token syntax
> >> define how to handle the case when running an endpoint supporting
> >> both OAuth
> >> according to the OAuth 1.0/a spec. Whatever is decided, be it a
> >> version parameter, the use of oauth2_token or the check for the
> >> needs to define and be explicit on how a resource endpoint determines
> > The damage done by interpreting a malformed 1.0 request (the odd
> attempt to use 1.0 by only including 'oauth_token') is at most returning an
> 'invalid-token' response. I hope every server developer understands that
> they should not share tokens between 1.0 and 2.0 with completely different
> security properties.
> >
> Still the issue that different error codes returned which a client may handle
> differently.
> > I think there are more issue with regard to 1.0 to 2.0 migration that should
> be addressed, and I have asked those who care about this to propose a draft.
> Given that such a draft will not be useful for a long time, given that the vast
> majority of OAuth implementation 1-2 years from now will be 2.0, I do not
> want to include it in the core specification.
> >
> > In order for your argument to stand, you need to show how the current
> setup leads to interoperability problems. Given the 4 options above, and the
> fact that a malformed 1.0 request will still fail, I do not agree that interop is
> affected.
> >
> >
> >
> OAuth is a service that my company provides to other companies and we will
> need to run both versions in parallel for many of the customers.
> There are other companies out there who provide similar service, so this isn't
> just an isolated problem. We may be transitioning customers to/from our
> service and the behaviors of the systems need to be the same pre and post
> migration.
> There is also the WTF factor for developers. If I make calls to 2 providers (1.0
> client), each of which is missing the oauth_signature, I would expect the
> same response back. An error that its missing a required signature. If one of
> the providers interprets a missing signature as meaning the call is a 2.0 based
> call then it will return back a different error code.
> 
> I would expect that if I implemented 2 independent systems based on a spec
> they would operate and behave the exact same way, otherwise you can just
> throw the spec in the pile with the rest of them that have ambiguous
> sections left to interpretation and cause for argument over who
> implemented what correctly in their system.
> 
> Rob

---

From: Rob Richards <[email-masked]>
Date: Sat, 03 Jul 2010 06:27:23 -0400

> I agree with you that a migration spec is important - please write one.

Like I didn't see that coming :)

> As for every provider returning the same error code, I don't think that this will always be the case as some providers will return invalid-request on other security related errors to reduce the amo…
I agree with you on the fact about being able to handle them differently 
based on requirements, but believe there still needs to be a known set 
baseline. Think of a web server. By default all web servers will return 
a 404 for resourses that are not found, but the administrator/developer 
is free to override them. Clients then know to expect a 404 error when 
things are not found. Change in this behavior is typically then done to 
fir a sever applications needs or just for other reasons in which case 
would probably be documented by the provider.
> I don't agree that the 2.0 core specification needs to cover 1.0 issues. That includes migrating from 1.0 to 2.0, supporting both, etc.

Although I still disagree here since there is nothing between the 1.0 
and 2.0 specs that concretely identify which version a resource call 
comes from, which really should be addressed in the spec iteself imo, I 
am willing to concede this point for now and just focus on the getting a 
migration spec written so that there is at least something official on 
this topic. On that note are there any guidelines, howtos, etc.. on 
writing a spec?

Rob

---

From: David Recordon <[email-masked]>
Date: Mon, 5 Jul 2010 09:42:01 -0700

I'm also of the opinion that a protected resource can use the request
parameters to differentiate between 1.0 and 2.0.

On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards <[email-masked]>wrote:

> On that note are there any guidelines, howtos, etc.. on writing a spec?
>

I'd recommend focusing on just writing the text and then making it spec like
later. Eran has been generally quite willing to take good text and edit it
into an actual spec. If you're interested in learning about the spec side of
it, you can take a look at
http://github.com/daveman692/OAuth-2.0/blob/master/draft-recordon-oauth-v2-ux.xmlwhich
is a pretty simple example.

--David

>>> handle
>>> will
>>> isn't
>>> providers (1.0

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 6 Jul 2010 21:54:16 -0700

> Like I didn't see that coming :)

I would like to help with this migration spec. Is this a good starting point:
http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html

Or, you had something else in mind?

Marius

---

From: "Stefanie Dronia" <[email-masked]>
Date: Thu, 08 Jul 2010 13:05:42 +0200

Hi,            

             I  took a look at the OAuth 1 Bridge Flow suggested by 
Marius, the thread "OAuth 1  Bridge Flow" and had some thoughts:            

             I  do not really see the necessity for such a flow.           

First of all, all participating parties have to be modified and  rolled 
out:            

-  the consumer's application to support (at least) the bridge flow (and 
OAuth 2  [1]),            

-  the authz server to provide OAuth 2  and additionally the bridge flow  
and            

-  the resource server to handle OAuth2.            

Then, sometime later, when at least the authz server doesn't support  OAuth 
1 anymore, the client application and the resource server should be  
cleared up - no more OAuth 1, only OAuth 2. Again a new version to roll  
out.            

             The only (small) benefit I see, is that the user will not be 
asked  for authorization again.            

But is it worth it to develop, implement and roll out a Bridge Flow?  I do 
not think so - too much expense for a small user  interaction.            

Better: directly go to OAuth 2, when it is  needed.            

             The other thing I'm missing, is how to migrate completely to 
OAuth 2  after performing the bridge flow. Issuing a refresh token in the 
response seems  necessary. But this issue was still mentioned (but not 
solved) in the thread  "OAuth 1 Bridge Flow" by Eran.            

                          Thanks,            

Steffi            

             [1] if OAuth 2 will not be supported, a new modified client 
has to be  rolled out at the latest, the resource server doesn't support 
OAuth 1  anymore.            

>             -------- Original-Nachricht --------
> Datum: Tue, 6 Jul 2010 21:54:16 -0700
> Von: Marius Scurtescu <[email-masked]>
> An: Rob Richards <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Betreff: Re: [OAUTH-WG] Versioning
> 
        
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 8 Jul 2010 11:26:27 -0700

The bridge flow was meant to be used in a mixed OAuth 1 and OAuth 2
environment, it allows the consumer to obtain a token using signatures
and then access protected resources with no signatures. Now that
signatures are re-introduced in OAuth 2 I don't think there is a need
for such an approach.

That being said, migration can be done very similarly, differences
from the bridge flow:
- an OAuth 2 refresh token is also returned
- optionally the OAuth 1 token is revoked

Such a migration flow would allow a consumer/client that has OAuth 1
access tokens saved for its users to convert all of them to OAuth 2
refresh tokens without involving the users.

Marius

On Thu, Jul 8, 2010 at 4:05 AM, Stefanie Dronia <[email-masked]> wrote:
> Hi,
>
>
>
> I took a look at the OAuth 1 Bridge Flow suggested by Marius, the thread
> "OAuth 1 Bridge Flow" and had some thoughts:
>
>
>
> First of all, all participating parties have to be modified and rolled out:
>
> - the authz server to provide OAuth 2  and additionally the bridge flow and
>
> Then, sometime later, when at least the authz server doesn't support OAuth 1
> anymore, the client application and the resource server should be cleared up
> - no more OAuth 1, only OAuth 2. Again a new version to roll out.
>
>
>
> The only (small) benefit I see, is that the user will not be asked for
> authorization again.
>
> The other thing I'm missing, is how to migrate completely to OAuth 2 after
> performing the bridge flow. Issuing a refresh token in the response seems
> necessary. But this issue was still mentioned (but not solved) in the thread
> "OAuth 1 Bridge Flow" by Eran.
>
>
>
>
>
> Thanks,
>
> Steffi
>
>
>
> [1] if OAuth 2 will not be supported, a new modified client has to be rolled
> out at the latest, the resource server doesn't support OAuth 1 anymore.
>
>
>

---

From: Stefanie Dronia <[email-masked]>
Date: Fri, 09 Jul 2010 13:27:57 +0200

Hallo Marius,

thanks for your statement.
Your idea of a migration flow is quite good and necessary.

But I still doubt, if the work and effort should be investigated to 
spare the user from some interaction (authentication and user consent).
Latest he will be asked for his consent at the time, the refresh token 
expired (as long as the refresh token has a limited validity period [1]) 
and a new one is requested.

With the additional aspects (OAuth 2 refresh token returned, OAuth 1 
access token revoked), the flow might only be performed once?
By the way, the revoke of the OAuth 1 token should not be optionally, 
but a must IMO. By that way, the consumer is enforced to process with 
OAuth 2 flows.

Have a nice weekend!
Steffi

[1] That a refresh token has a limited validity period is not defined in 
the spec. But the authz server should be able to invalidate it.
E.g. when the refresh token is issued, a long, but limited validity 
period is assigned to it. Each time, new access token(s) are requested 
with the refresh token as access grant, the refresh token's validity 
period is extended. If not, it gets invalid reaching the assigned limit. 
This flow represents the user's usage of the consumers application. 
(Quasi) Infinitely valid refresh token at continuous usage of the 
consumers application. Limited validity at rare or no usage. Revocation 
of the granted access is done automatically w/o user intervention.

Am 08.07.2010 20:26, schrieb Marius Scurtescu:
> On Thu, Jul 8, 2010 at 4:05 AM, Stefanie Dronia<[email-masked]>  wrote:
>    
>> Hi,
>>
>>
>>
>> Von: Marius Scurtescu<[email-masked]>
>> An: Rob Richards<[email-masked]>
>> CC: "[email-masked]"<[email-masked]>
>> On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards<[email-masked]>
>> wrote:
>>      
>>> Eran Hammer-Lahav wrote:
>>>        
>>>> Hi Rob,
>>>>

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 9 Jul 2010 08:40:26 -0700

See comments bellow...

On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia <[email-masked]> wrote:
> But I still doubt, if the work and effort should be investigated to spare
> the user from some interaction (authentication and user consent).

It all depends for how many users does the client have OAuth 1 tokens.
Asking users to re-approve will confuse them and I guess many will not
do it,

> expired (as long as the refresh token has a limited validity period [1]) and
> a new one is requested.

That's authz implementation specific, but in most cases I think
refresh tokens (or OAuth 1 access tokens) never expire.

> With the additional aspects (OAuth 2 refresh token returned, OAuth 1 access
> token revoked), the flow might only be performed once?

Yes, I see this as a one time migration.

> By the way, the revoke of the OAuth 1 token should not be optionally, but a
> must IMO. By that way, the consumer is enforced to process with OAuth 2
> flows.

Yes, the consumer has to switch over to OAuth 2.

>
> Have a nice weekend!
> Steffi
>
> [1] That a refresh token has a limited validity period is not defined in the
> spec. But the authz server should be able to invalidate it.

It sure does. Also, I assume that most authz servers will give this
option to the end user, some page where they can see all the refresh
tokens issued for them and where they can revoke them.

> E.g. when the refresh token is issued, a long, but limited validity period
> is assigned to it. Each time, new access token(s) are requested with the
> refresh token as access grant, the refresh token's validity period is
> extended. If not, it gets invalid reaching the assigned limit. This flow
> represents the user's usage of the consumers application. (Quasi) Infinitely
> valid refresh token at continuous usage of the consumers application.
> Limited validity at rare or no usage,  Revocation of the granted access is
> done automatically w/o user intervention.

An interesting idea. I guess it is up to the authz server to implement
something like this.

Marius

---

From: Rob Richards <[email-masked]>
Date: Wed, 14 Jul 2010 14:46:06 -0400

Finally getting a chance to catchup and respond to this thread.

> Asking users to re-approve will confuse them and I guess many will not

I think the user should not be excluded from this interaction and should 
be required to re-approve. IMO they should be involved as its also 
informational to know that the client they have previously authorized is 
now requesting new credentials under a different security scheme. The 
user should be the one to decide whether or not they want to allow this.

When it comes right down to it the only concrete thing I can think of 
when migrating from 1.0 to 2.0 is the need to determine which version is 
being used at the resource endpoint. For most clients moving from 1.0 to 
2.0 they will most likely just create the next version of their 
client/app with 2.0 support and completely drop 1.0 support rather than 
going through any migration flow. More work that they don't need to deal 
with so why would they. I can envision a SP providing support for both 
1.0 and 2.0 with an end of life to 1.0 support. This will give the 
client developers enough time to migrate and distribute their client/apps.

As far as the version determination on the endpoint, this is really just 
a paragraph of text and seems a bit overkill to put into its own 
proposal when it could easily be handled even as an appendix in the core 
2.0 spec.

Rob

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 14 Jul 2010 15:15:37 -0700

Already in -10. 

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 14 Jul 2010 15:33:27 -0700

On Wed, Jul 14, 2010 at 11:46 AM, Rob Richards <[email-masked]> wrote:
> I think the user should not be excluded from this interaction and should be
> required to re-approve. IMO they should be involved as its also
> informational to know that the client they have previously authorized is now
> requesting new credentials under a different security scheme. The user
> should be the one to decide whether or not they want to allow this.

Why would you re-prompt the user? The only thing that really changes
is the underlying protocol, something most end users are not made
aware of. How would the new approval page be any different from the
initial one? The user granted a client access to some of its
resources, that stays the same. If the authorization server makes it
explicit on the approval page that OAuth 1 is used, then yes, a
re-approval is needed, but I don't think this normally happens.

> When it comes right down to it the only concrete thing I can think of when
> migrating from 1.0 to 2.0 is the need to determine which version is being
> used at the resource endpoint. For most clients moving from 1.0 to 2.0 they
> will most likely just create the next version of their client/app with 2.0
> support and completely drop 1.0 support rather than going through any
> migration flow.

That depends on the client. If the client is a web site that has
several thousand users, and it stores OAuth 1 access tokens for all
these users, then migration totally makes sense. If the client is an
iPhone app with only one user, then maybe you are right. Even in this
case, I am sure the app would prefer not to annoy the user and just
silently move to OAuth 2. If you are the app developer and your app
has a large install base, would you risk losing even a small
percentage of those users simply because you presented them with a
confusing approval page?

Marius

---

From: Rob Richards <[email-masked]>
Date: Fri, 16 Jul 2010 05:33:38 -0400

On 7/14/10 6:33 PM, Marius Scurtescu wrote:
> On Wed, Jul 14, 2010 at 11:46 AM, Rob Richards<[email-masked]>  wrote:
>>> On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia<[email-masked]>  wrote:
>>>
>>>> Hallo Marius,
>>>>
As a user I would say yes, I want to be re-prompted or at least 
explicitly request the migration of my tokens rather than having 
something done silently, behind the scenes and unbeknownst to me. The 
underlying protocol has changed, whether or not I know it, and for all 
purposes could be the most insure protocol out there. When something 
this fundamental changes, I would want to have to re-authorize the 
application because I could just as easily at this point decline. 
Perhaps I went and read the changelog, the change was made known on the 
site, or someone discovered the change and made it public. As you can 
probably tell I lean way more towards the side of the user and 
personally think it is more responsible of the app or web site in 
question here to require the re-authorization and risk losing some users 
(if that is the case then clearly the application is not worth the users 
time in the first place) than to silently change the protocol on me.

Rob

---

From: Rob Richards <[email-masked]>
Date: Fri, 16 Jul 2010 05:48:59 -0400

Outside of what happens based on the newly refreshed conversation 
about this, currently this point should be moved to 5.1 rather than 
5.1.1 as its not specific to the Authorization header.

Rob

On 7/14/10 6:15 PM, Eran Hammer-Lahav wrote:
> Already in -10.
>
> EHL
>
>
>
> On Jul 14, 2010, at 14:46, Rob Richards<[email-masked]>  wrote:
>

---

From: "William Mills" <[email-masked]>
Date: Fri, 16 Jul 2010 09:13:20 -0700

For token migration from Oauth 1 to 2 are we ever really going to need
to do that silently for a user in a client?  It's reasonable when the
user gets a new client install that supports a new protocol for them to
have to re-authenticate.  Where I see this happening is in a big server
migration where you're integrating with somone like Google IMAP and you
already have a huge store of tokens for IMAP and you want yo convert to
Oauth 2 but you don't want to prompt all your users.

Do I have this right? 

> On Behalf Of Rob Richards
> Sent: Friday, July 16, 2010 2:34 AM
> To: Marius Scurtescu
> Cc: [email-masked]
> >>> Asking users to re-approve will confuse them and I guess 
> many will 
> >>> not do it,
> >>>
> >> I think the user should not be excluded from this interaction and 
> >> should be required to re-approve. IMO they should be 
> involved as its 
> >> also informational to know that the client they have previously 
> >> authorized is now requesting new credentials under a different 
> >> security scheme. The user should be the one to decide 
> whether or not they want to allow this.
> >> when migrating from 1.0 to 2.0 is the need to determine 
> which version 
> >> is being used at the resource endpoint. For most clients 
> moving from 
> >> 1.0 to 2.0 they will most likely just create the next version of 
> >> their client/app with 2.0 support and completely drop 1.0 support 
> >> rather than going through any migration flow.
> As a user I would say yes, I want to be re-prompted or at 
> least explicitly request the migration of my tokens rather 
> than having something done silently, behind the scenes and 
> unbeknownst to me. The underlying protocol has changed, 
> whether or not I know it, and for all purposes could be the 
> most insure protocol out there. When something this 
> fundamental changes, I would want to have to re-authorize the 
> Perhaps I went and read the changelog, the change was made 
> known on the site, or someone discovered the change and made 
> it public. As you can probably tell I lean way more towards 
> the side of the user and personally think it is more 
> responsible of the app or web site in question here to 
> require the re-authorization and risk losing some users (if 
> that is the case then clearly the application is not worth 
> the users time in the first place) than to silently change 
> the protocol on me.
> 
> Rob
>

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 16 Jul 2010 09:36:51 -0700

> Oauth 2 but you don't want to prompt all your users.

I think so.

I don't think we have to decide if silent upgrade should always be
used or not, just that it is a valid option.

Marius