[Openid-specs-ab] Breaking change in OAuth 2.0 rev. 23

Marius Scurtescu mscurtescu at google.com
Wed Mar 14 16:54:37 UTC 2012


On Wed, Mar 14, 2012 at 9:28 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> If we’re concerned about this change, we should begin discussing it on the
> OAuth mailing list and lobbying to have it undone.  Discussing it on the AB
> list won’t accomplish this.

I just sent a message to the OAuth list in this regard. Yes, I think
this should be debated there.

Marius

>
>
>
>                                                             -- Mike
>
>
>
> From: openid-specs-ab-bounces at lists.openid.net
> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Breno de
> Medeiros
> Sent: Wednesday, March 14, 2012 9:26 AM
> To: Nat Sakimura
>
>
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Breaking change in OAuth 2.0 rev. 23
>
>
>
> I am quite confused with this change.
>
> In particular, I am not sure response_type is anymore relevant. Can't it be
> inferred from the client, since each client is bound to a security context?
>
> On Mar 14, 2012 7:37 AM, "Nat Sakimura" <sakimura at gmail.com> wrote:
>
> Good to know it. I thought an extension could only extend from an extension
> point but could not override a normative  language. If it can, it would not
> be a problem.
>
> =nat via iPhone
>
>
> On 2012/03/14, at 10:25, "Richer, Justin P." <jricher at mitre.org> wrote:
>
> Not true -- extensions can override MUST requirements if they specify the
> conditions that break it.
>
>
>
>  -- Justin
>
>
>
> On Mar 14, 2012, at 10:22 AM, Nat Sakimura wrote:
>
>
>
> The problem is the normative MUST language. If it were SHOULD, it is less of
> the problem.
>
>
>
> Since it is a MUST, we cannot extend it. That is the problem that I am
> pointing  out.
>
> =nat via iPhone
>
>
> On 2012/03/14, at 10:17, nov matake <nov at matake.jp> wrote:
>
> This is the only discussion about this change.
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg08271.html
>
>
>
> And this is the response I got in OAuth ML.
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg08548.html
>
>
>
> According to the Eran's reply, I thought extensions (eg. response_type=code
> token) can overwrite the requirement.
>
>
>
> On 2012/03/14, at 22:22, Nat Sakimura wrote:
>
>
>
>
>
> =nat via iPhone
>
>
> On 2012/03/14, at 7:33, "Richer, Justin P." <jricher at mitre.org> wrote:
>
> The way I read it, "code token" is its own type, and it needs to be treated
>
>
>
> My first take was that but the text goes:
>
>
>
> a distributed client with both a confidential
> server-based component and a public browser-based component), MUST
> register each component separately as a different client
>
>
>
> so looks to me that it does not allow that interpretation...
>
>
>
> differently from either "code" or "token", which isn't a change. What the
> intent of the text is, I believe, is to keep people from using the same
> client id with "code" as with "token". This would effectively be mixing
> public and private clients in the most normal use cases, which is the
> section that it's in, and that's not a good thing.
>
>
>
> I don't think it's actually a breaking change, but I'm less convinced of the
> utility of normative language here.
>
>
>
>  -- Justin
>
>
>
> On Mar 14, 2012, at 7:02 AM, Nat Sakimura wrote:
>
>
>
> I only noticed now that rev 23 had a breaking change. it seems to
> doesn't allow the response_type=code token unless we define another client
> type such as "hybrid".
>
>
>
> This is a breaking change.
>
> I wonder why I did not notice it till now.
>
>
> See below.
>
> From section 2.1of
> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-oauth-v2-23.txt
>
> "A client application consisting of multiple components, each with its
> own client type (e.g. a distributed client with both a confidential
> server-based component and a public browser-based component), MUST
> register each component separately as a different client to ensure
> proper handling by the authorization server."
>
> Discuss.
>
>
>
> --
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>


More information about the Openid-specs-ab mailing list