[OAUTH-WG] TLS 1.2

[Rob Richards]

The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2). Based 
on a thread about this from last year I was under the impression that it 
was going to be relaxed to a SHOULD with most likely TLS 1.0 (or 
posssibly SSLv3) as a MUST. I think it's a bit unrealistic to require 
1.2 when many systems out there can't support it. IMO this is going to 
be a big stumbling block for people to implement a compliant OAuth 
system. Even PCI doesn't require 1.2.


Rob
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TLS 1.2

[Rob Richards]

I wanted to follow up on this and see if there was any consideration to 
relaxing this requirement. Can someone actually point me to a compliant 
implementation using TLS 1.2 because after looking at a number of them, 
I have yet to find one that does.


Rob

On 8/12/11 3:56 PM, Rob Richards wrote:
The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2). Based 
on a thread about this from last year I was under the impression that 
it was going to be relaxed to a SHOULD with most likely TLS 1.0 (or 
posssibly SSLv3) as a MUST. I think it's a bit unrealistic to require 
1.2 when many systems out there can't support it. IMO this is going to 
be a big stumbling block for people to implement a compliant OAuth 
system. Even PCI doesn't require 1.2.


Rob
___
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

Re: [OAUTH-WG] TLS 1.2

[Rob Richards]

After dealing with a few companies' security teams over the spec, I 
don't think it should be allowed too much room for interpretation and 
needs to be spelled out clearly. They would most likely interpret that 
as requiring the latest version of TLS at the time of implementation.


Maybe something more along the lines of:

The authorization server SHOULD support TLS 1.2 as defined in [RFC5246] 
but at a minimum MUST support TLS 1.0 as defined in [RFC2246], and MAY 
support additional transport-layer mechanisms meeting its security 
requirements.


On 8/16/11 4:04 PM, Peter Saint-Andre wrote:

How's this?

The authorization server MUST support Transport Layer Security
(at the time of this writing, the latest version is specified in
[RFC5246]). It MAY support additional transport-layer mechanisms
meeting its security requirements.

On 8/16/11 1:55 PM, Eran Hammer-Lahav wrote:

We should relax it. Just need someone to propose new language.

EHL


-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Justin Richer
Sent: Tuesday, August 16, 2011 12:49 PM
To: Rob Richards
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] TLS 1.2

As I recall, the logic of the group here was something like:

"We want transport-layer encryption, so let's grab the latest version of that
around, which looks to be TLS 1.2"

With that logic in mind, this relaxation makes sense to me. Does anyone
remember this requirement differently?

  -- Justin
 (who admittedly couldn't tell the difference between SSL and TLS)

On Tue, 2011-08-16 at 15:36 -0400, Rob Richards wrote:

I wanted to follow up on this and see if there was any consideration
to relaxing this requirement. Can someone actually point me to a
compliant implementation using TLS 1.2 because after looking at a
number of them, I have yet to find one that does.

Rob

On 8/12/11 3:56 PM, Rob Richards wrote:

The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2).
Based on a thread about this from last year I was under the
impression that it was going to be relaxed to a SHOULD with most
likely TLS 1.0 (or posssibly SSLv3) as a MUST. I think it's a bit
unrealistic to require
1.2 when many systems out there can't support it. IMO this is going
to be a big stumbling block for people to implement a compliant
OAuth system. Even PCI doesn't require 1.2.

Rob
___
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


___
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




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TLS 1.2

[Rob Richards]

On 8/18/11 2:31 PM, Eran Hammer-Lahav wrote:

-Original Message-
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Tuesday, August 16, 2011 1:34 PM
The authorization server SHOULD support TLS 1.2 as defined in [RFC5246] but
at a minimum MUST support TLS 1.0 as defined in [RFC2246], and MAY
support additional transport-layer mechanisms meeting its security
requirements.

How about:

The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD support TLS 
1.2 ([RFC5246]) and its future replacements, and MAY support additional 
transport-layer mechanisms meeting its security requirements.

EHL




That works

Rob
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

[Rob Richards]

Please refer to this thread about the problem with requiring anything 
more than TLS 1.0

http://www.ietf.org/mail-archive/web/oauth/current/msg07234.html

You will end up with a spec that virtually no one can implement and be 
in conformance with. I still have yet to find an implementation out in 
the wild that supports anything more than TLS 1.0


Rob

On 11/17/11 3:41 AM, Barry Leiba wrote:

The OAuth base doc refers in two places to TLS versions (with the same
text in both places:

OLD
The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
support additional transport-layer mechanisms meeting its security
requirements.

In both the shepherd review and the AD review, this was called into question:
1. MUST for an old version and SHOULD for the current version seems wrong.
2. Having specific versions required locks us into those versions (for
example, all implementations will have to support TLS 1.0, even long
after it becomes obsolete, unless we rev the spec.

I have suggested the following change, as doc shepherd:

NEW
The authorization server MUST implement the current version of TLS
(1.2 [RFC5246] at the time of this writing), and SHOULD implement the
most widely deployed previous version (1.0 [RFC2246] at the of this
writing), unless that version is deprecated due to security
vulnerabilities.  It MAY also implement additional transport-layer
mechanisms that meet its security requirements.

I believe this also gives us the effect we want, without the two
problems above.  There was consensus in the meeting for accepting this
text.  Confirming on the list:

Please respond to this thread if you *object* to this change, and say
why.  Please respond by 2 Dec 2011.

Barry, as document shepherd
___
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

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

[Rob Richards]

I'm saying that it's very difficult for someone to implement an AS that 
implements TLS 1.2. TLS 1.2 is not supported in the a good number of 
systems people deploy on. For example, the use of Apache and OpenSSL 
accounts for a good number of web servers out there. The only way to 
deploy a conforming AS is to use a not yet released version of openssl, 
1.0.1, and rebuild or use a different crypto library and rebuild. The 
barrier for entry to use OAuth 2.0 has just became to high for the 
majority of people out there. I have already hit a scenario where the 
security group for a company has balked at OAuth 2.0, prior to the 
change relaxing TLS 1.2 usage, because the deployed system did not 
support TLS 1.2 and it's against policy to use non-vendor approved 
versions of packages. Requiring TLS 1.2 is going to cause the majority 
to release non-conforming deployments of OAuth 2, just as it was before 
the previous change.


Rob

On 11/17/11 6:18 AM, Barry Leiba wrote:

Please refer to this thread about the problem with requiring anything more
than TLS 1.0
http://www.ietf.org/mail-archive/web/oauth/current/msg07234.html

You will end up with a spec that virtually no one can implement and be in
conformance with. I still have yet to find an implementation out in the wild
that supports anything more than TLS 1.0

Are you saying that there's some difficulty in *implementing* TLS 1.2
?  If so, please explain what that difficulty is.

If you're saying that TLS 1.2 is not widely deployed, and so it's hard
to find two implementations that will actually *use* TLS 1.2 to talk
to each other, I have no argument with you.  But that's not the point.
  If everyone implements only TLS 1.0, we'll never move forward.  And
when TLS 1.2 (or something later) does get rolled out, OAuth
implementations will be left behind.  If everyone implements 1.2 AND
1.0, then we'll be ready when things move.

I'm pretty sure there'll be trouble getting through the IESG with a
MUST for something two versions old, and a SHOULD for the current
version.

Barry



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

[Rob Richards]

On 11/28/11 10:39 PM, Barry Leiba wrote:

The OAuth base doc refers in two places to TLS versions (with the same
text in both places:

OLD
The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
support additional transport-layer mechanisms meeting its security
requirements.

In both the shepherd review and the AD review, this was called into question:
1. MUST for an old version and SHOULD for the current version seems wrong.
2. Having specific versions required locks us into those versions (for
example, all implementations will have to support TLS 1.0, even long
after it becomes obsolete, unless we rev the spec.

The comments I've gotten on this show a clear consensus against the
change I suggest, and against any attempt to require a version of TLS
other than 1.0.  I still, though, am concerned that locking this spec
into TLS 1.0 is limiting.  So let me propose an alternative wording,
which again tries to make the version(s) non-normative, while making
it clear which version(s) need to be implemented to get
interoperability:

NEW

The authorization server MUST implement TLS.  Which version(s)
ought to be implemented will vary over time, and depend on
the widespread deployment and known security vulnerabilities at
the time of implementation.  At the time of this writing, TLS version
1.2 [RFC5246] is the most recent version, but has very limited
actual deployment, and might not be readily available in
implementation toolkits.  TLS version 1.0 [RFC2246] is the
most widely deployed version, and will give the broadest
interoperability.

Servers MAY also implement additional transport-layer
mechanisms that meet their security requirements.


Comments on this version?

Barry



Text is neutral enough for me as it's not mandating anything that isn't 
readily available. Only comment is whether or not there is a need to 
even talk about the specific versions or if just the following is enough:


The authorization server MUST implement TLS. Which version(s) ought to 
be implemented will vary over time, and depend on the widespread 
deployment and known security vulnerabilities at the time of implementation.


Servers MAY also implement additional transport-layer mechanisms that 
meet their security requirements.


Rob

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

[Rob Richards]

I am fine with it

Rob

On 12/9/11 1:30 PM, Mike Jones wrote:

It looks to me like there is consensus for Barry's text (below).  Agreed?

-- Mike

NEW

The authorization server MUST implement TLS.  Which version(s) ought to be 
implemented will vary over time, and depend on the widespread deployment and 
known security vulnerabilities at the time of implementation.  At the time of 
this writing, TLS version 1.2 [RFC5246] is the most recent version, but has 
very limited actual deployment, and might not be readily available in 
implementation toolkits.  TLS version 1.0 [RFC2246] is the most widely deployed 
version, and will give the broadest interoperability.

Servers MAY also implement additional transport-layer mechanisms that meet 
their security requirements.


-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Peter 
Saint-Andre
Sent: Thursday, December 01, 2011 12:59 PM
To: Stephen Farrell
Cc: Barry Leiba; oauth WG
Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

On 12/1/11 1:57 PM, Stephen Farrell wrote:


On 12/01/2011 08:10 PM, Peter Saint-Andre wrote:

On 12/1/11 1:09 PM, Rob Richards wrote:

On 11/28/11 10:39 PM, Barry Leiba wrote:

The OAuth base doc refers in two places to TLS versions (with the
same text in both places:

OLD
The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
support additional transport-layer mechanisms meeting its security
requirements.

In both the shepherd review and the AD review, this was called
into
question:
1. MUST for an old version and SHOULD for the current version
seems wrong.
2. Having specific versions required locks us into those versions
(for example, all implementations will have to support TLS 1.0,
even long after it becomes obsolete, unless we rev the spec.

The comments I've gotten on this show a clear consensus against the
change I suggest, and against any attempt to require a version of
TLS other than 1.0.  I still, though, am concerned that locking
this spec into TLS 1.0 is limiting.  So let me propose an
alternative wording, which again tries to make the version(s)
non-normative, while making it clear which version(s) need to be
implemented to get
interoperability:

NEW

The authorization server MUST implement TLS.  Which version(s)
ought to be implemented will vary over time, and depend on the
widespread deployment and known security vulnerabilities at the
time of implementation.  At the time of this writing, TLS version
1.2 [RFC5246] is the most recent version, but has very limited
actual deployment, and might not be readily available in
implementation toolkits.  TLS version 1.0 [RFC2246] is the most
widely deployed version, and will give the broadest
interoperability.

Servers MAY also implement additional transport-layer mechanisms
that meet their security requirements.


Comments on this version?

Barry


Text is neutral enough for me as it's not mandating anything that
isn't readily available. Only comment is whether or not there is a
need to even talk about the specific versions or if just the
following is
enough:

The authorization server MUST implement TLS. Which version(s) ought
to be implemented will vary over time, and depend on the widespread
deployment and known security vulnerabilities at the time of
implementation.

Servers MAY also implement additional transport-layer mechanisms
that meet their security requirements.

That seems fine to me.

FWIW, I think I'd prefer Barry's as Rob's would be more likely to
generate discusses and we do know that there are some security
advantages to TLS 1.2 vs. 1.0. (BTW, has anyone considered how or if
the BEAST attack might affect oauth? Be good to know if someone's done
that analysis.)

However, as AD, I could live with either, since lots of other specs
just say TLS. (But you need to point to the latest RFC as normative or
that will I bet generate discusses.)

Agreed.

Peter

--
Peter Saint-Andre
https://stpeter.im/


___
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



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Rob Richards]

I think you nailed it which that statement. Up until now it as been back 
and forth about one or the other. Personally I prefer to used layered 
security and not relying on a single point of attack. It's unrealistic 
to say everyone is going to want/need/be able to use (take your pick) 
signed/encrypted JWT. MAC at least offers an alternative, less 
complicated solution.


Rob

On 8/10/12 10:41 AM, Richer, Justin P. wrote:

What about security in depth? Signing + TLS is more secure than either alone, 
isn't it?

  -- Justin

On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote:


Hi Bill,

thanks for the feedback. Let's have a look at this use case:

You need to provide me a bit more information regarding your use case. Could 
you please explain

1) Who is authenticated to whom?
2) What plaintext connection are you talking about?
3) What is the problem with encrypted connections? Is this again the "TLS has so bad 
performance" argument?
4) Since you are talking about cookies and making them more secure are you 
trying to come up with a general solution to better cookie security - a topic 
others are working on as well.
5) What is the threat you are concerned about?

Ciao
Hannes

PS: I would heavily argue against standardize a security mechanism that offers weaker 
protection than bearer when the entire argument has always been "Bearer is so 
insecure and we need something stronger."

On Aug 9, 2012, at 9:43 PM, William Mills wrote:


OK, I'll play and start documenting the use cases.

Use case #1: Secure authentication in plain text connections:

Some applications need a secure form authorization, but do not want or need the 
overhead of encrypted connections.  HTTP cookies and their ilk are replayable 
credentials and do not satisfy this need.   the MAC scheme using signed HTTP 
authorization credentials offer the capability to securely authorize a 
transaction, can offer integrity protection on all or part of an HTTP request, 
and can provide replay protection.

-bill

From: John Bradley 
To: William Mills 
Cc: Dick Hardt ; "oauth@ietf.org" 
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

In Vancouver the question was asked about the future of the MAC spec due to it 
no linger having a editor.

The Chair and AD indicated a desire to have a document on the use-cases we are 
trying to address before deciding on progressing MAC or starting a new document.

Phil Hunt is going to put together a summery of the Vancouver discussion and we 
are going to work on the use-case/problem description document ASAP.

People are welcome to contribute to the use-case document.

Part of the problem with MAC has been that people could never agree on what it 
was protecting against.

I think there is general agreement that one or more proof mechanisms are 
required for access tokens.
Security for the token endpoint also cannot be ignored.


John B.

On 2012-08-09, at 1:53 PM, William Mills wrote:


MAC fixes the signing problems encountered in OAuth 1.0a, yes there are 
libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model and 
will provide for a single codepath for sites that want to use both Bearer and 
MAC.

From: Dick Hardt 
To: William Mills 
Cc: "oauth@ietf.org" 
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01


On Aug 9, 2012, at 9:52 AM, William Mills wrote:


I find the idea of starting from scratch frustrating.  MAC solves a set of 
specific problems and has a well defined use case.  It's symmetric key based 
which doesn't work for some folks, and the question is do we try to develop 
something that supports both PK and SK, or finish the SK use case and then work 
on a PK based draft.

I think it's better to leave them separate and finish out MAC which is *VERY 
CLOSE* to being done.

Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.

For my projects, I prefer the flexibility of a signed or encrypted JWT if I 
need holder of key.

Just my $.02

-- Dick



___
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

___
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



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests

[Rob Richards]

Wouldn't it make sense to require the oauth_version parameter under 2.0 
for resource calls so that the two versions can be distinguished?


Rob

Paul Lindner wrote:
If you're routing requests with a load balancer it's not so trivial.   
Instead of a substring match you're talking about a regex with 
negative lookahead matching -- that's why the presence of the 
signature param is essential to distinguishing between 2.0/1.0a.


On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav 
mailto:e...@hueniverse.com>> wrote:


But in that case, all the other oauth_* parameters are missing.
It's trivial.

EHL

> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com
]
> Sent: Thursday, June 10, 2010 10:39 AM
> To: Paul Lindner
> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org
)
> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests
>
> I run into the same issue. In section "4.2. URI Query
Parameter", it would
> help if the parameter name, oauth_token, was different from OAuth 1.
>
> Marius
>
>
>
> On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner mailto:lind...@inuus.com>> wrote:
> > I am talking about the resource server. Specifically I want to
be able
> > to quickly determine if an incoming request is 1.0a vs 2.0.
 And since
> > this is a library it can't make a lot of assumptions about the
> > specific environment it's running in.
> > At first I thought I would check the oauth_version parameter.  It
> > turns out the 1.0a spec says that it is optional.  The only
one that
> > is required for 1.0a is oauth_signature_method.
> > Sadly we're long past time to change the spec to optimize for
this use-case.
> >  (It would have been better to have a parameter for oauth 2.0
that is
> > distinct from 1.0a)  At the very least this message will live
on in
> > the mailing list archives -- at best we document the proper way to
> > distinguish between the two versions somewhere.
> > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav
> > mailto:e...@hueniverse.com>>
> > wrote:
> >>
> >> The request is very different on the resource server. On the
> >> authorization server, why would you use the same endpoint?
> >>
> >>
> >>
> >> EHL
> >>
> >>
> >>
> >> From: oauth-boun...@ietf.org 
[mailto:oauth-boun...@ietf.org ] On
> >> Behalf Of Paul Lindner
> >> Sent: Thursday, June 10, 2010 8:24 AM
> >> To: OAuth WG (oauth@ietf.org )
> >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests
> >>
> >>
> >>
> >> Hi,
> >>
> >>
> >>
> >> As I've been working through our oauth2 implementation I've
noticed
> >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API
calls based
> >> on the request parameters alone.   Based on some
investigative at the
> >> Shindig project it appears that the only standard way to to
determine
> >> 1.0a vs 2.0 is by checking for the oauth_signature_method
> parameter.  More info here:
> >>
> >>
> >>
> >> https://issues.apache.org/jira/browse/SHINDIG-1361
> >>
> >>
> >>
> >> Has anyone else considered this use case?  How did you solve it?
> >>
> >>
> >
> > ___
> > 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
  


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests

[Rob Richards]

Both of those scenarios could also be bad 1.0 calls where a 400 error 
needs to be thrown due to missing a required parameter.
So worse case is that every single parameter from a 1.0 calls needs to 
be checked that at least one of them exists in the call and then its 
still possible that it could be a bad 1.0 although it looks like 2.0.


Rob

Paul Lindner wrote:
As stated previously the easy way to determine OAuth 1.0 vs 2.0 
without using negative assertions is to check for the presence of 
oauth_signature_method


On Mon, Jun 14, 2010 at 1:09 PM, David Recordon <mailto:record...@gmail.com>> wrote:


It's easy to detect version when calling a protected resource. In
OAuth 2.0 you only have one token parameter whereas 1.0 has a variety
of parameters including a signature.

--David


On Mon, Jun 14, 2010 at 9:05 AM, Rob Richards
mailto:rricha...@cdatazone.org>> wrote:
> Wouldn't it make sense to require the oauth_version parameter
under 2.0 for
> resource calls so that the two versions can be distinguished?
>
> Rob
>
> Paul Lindner wrote:
>>
>> If you're routing requests with a load balancer it's not so
trivial.
>> Instead of a substring match you're talking about a regex with
negative
>> lookahead matching -- that's why the presence of the signature
param is
>> essential to distinguishing between 2.0/1.0a.
>>
>> On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav
mailto:e...@hueniverse.com>
>> <mailto:e...@hueniverse.com <mailto:e...@hueniverse.com>>> wrote:
>>
>>But in that case, all the other oauth_* parameters are missing.
>>It's trivial.
>>
>>EHL
>>
>>> -Original Message-
>>> From: Marius Scurtescu [mailto:mscurte...@google.com
<mailto:mscurte...@google.com>
>><mailto:mscurte...@google.com <mailto:mscurte...@google.com>>]
>>> Sent: Thursday, June 10, 2010 10:39 AM
>>> To: Paul Lindner
>>> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org
<mailto:oauth@ietf.org>
>><mailto:oauth@ietf.org <mailto:oauth@ietf.org>>)
>>> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests
>>>
>>> I run into the same issue. In section "4.2. URI Query
>>Parameter", it would
>>> help if the parameter name, oauth_token, was different
from OAuth 1.
>>>
>>> Marius
>>>
>>>
>>>
>>> On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner
mailto:lind...@inuus.com>
>><mailto:lind...@inuus.com <mailto:lind...@inuus.com>>> wrote:
>>> > I am talking about the resource server. Specifically I
want to
>>be able
>>> > to quickly determine if an incoming request is 1.0a vs 2.0.
>> And since
>>> > this is a library it can't make a lot of assumptions
about the
>>> > specific environment it's running in.
>>> > At first I thought I would check the oauth_version
parameter.  It
>>> > turns out the 1.0a spec says that it is optional.  The only
>>one that
>>> > is required for 1.0a is oauth_signature_method.
>>> > Sadly we're long past time to change the spec to
optimize for
>>this use-case.
>>> >  (It would have been better to have a parameter for
oauth 2.0
>>that is
>>> > distinct from 1.0a)  At the very least this message will
live
>>on in
>>> > the mailing list archives -- at best we document the
proper way to
>>> > distinguish between the two versions somewhere.
>>> > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav
>>> > mailto:e...@hueniverse.com>
<mailto:e...@hueniverse.com <mailto:e...@hueniverse.com>>>
>>> > wrote:
>>> >>
>>> >> The request is very different on the resource server.
On the
>>> >> authorization server, why would you use the same endpoint?
>>> >>
>>> >>
>>> >>
>>> >> EHL
>>> >>
>>> >>
>>> >>
>>> >> From: oauth-boun...@ietf.org

Re: [OAUTH-WG] Status update

[Rob Richards]

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-WG] Versioning

[Rob Richards]

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Versioning

[Rob Richards]

Eran Hammer-Lahav wrote:
  

-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, July 01, 2010 10:37 AM
To: Eran Hammer-Lahav
Cc: Rob Richards; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Versioning

On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav 
wrote:


Hi Rob,

  

-Original Message-
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Thursday, July 01, 2010 3:26 AM
To: OAuth WG (oauth@ietf.org); 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.

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.


  
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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Versioning

[Rob Richards]

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:

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:
  

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


When tokens are passed in the query string there is no scheme. 
  
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com] 
Sent: Thursday, July 01, 2010 11:16 AM

To: Eran Hammer-Lahav
Cc: William Mills; Rob Richards; oauth@ietf.org
Subject: Re: [OAUTH-WG] Versioning

On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav 
 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

  

EHL



-Original Message-
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Thursday, July 01, 2010 10:49 AM
To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org
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.
  

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On 
Behalf Of Eran Hammer-Lahav

Sent: Thursday, July 01, 2010 9:36 AM
To: Rob Richards; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Versioning

Hi Rob,



-----Original Message-
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Thursday, July 01, 2010 3:26 AM
To: OAuth WG (oauth@ietf.org); 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
___
OAuth mailing list
OAuth@ietf.or

Re: [OAUTH-WG] Versioning

[Rob Richards]

Eran Hammer-Lahav wrote:

[Replying to everything at once...]
  

-Original Message-
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Thursday, July 01, 2010 11:43 AM



  

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.



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'
  


Never said this was hard just that it needs to be documented.
  

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.
  
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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Versioning

[Rob Richards]

Eran Hammer-Lahav wrote:

Hi Rob,

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 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 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.

EHL
  


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
  

-Original Message-
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Friday, July 02, 2010 4:05 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Versioning

Eran Hammer-Lahav wrote:


[Replying to everything at once...]

  

-Original Message-
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Thursday, July 01, 2010 11:43 AM


  

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.



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'

  

Never said this was hard just that it needs to be documented.


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.

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 interop

Re: [OAUTH-WG] Versioning

[Rob Richards]

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

Marius Scurtescu wrote:

See comments bellow...


On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia  wrote:
  

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).



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,
  


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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Versioning

[Rob Richards]

 On 7/14/10 6:33 PM, Marius Scurtescu wrote:

On Wed, Jul 14, 2010 at 11:46 AM, Rob Richards  wrote:

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

Marius Scurtescu wrote:

See comments bellow...


On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia  wrote:


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).


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,


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?



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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Versioning

[Rob Richards]

 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  wrote:


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

Marius Scurtescu wrote:

See comments bellow...


On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia  wrote:


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).


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,


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
___
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