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

Nat Sakimura sakimura at gmail.com
Wed Mar 14 17:25:49 UTC 2012


So it was my attempt to see if it were a problem that we can solve
here or not and good to hear that you filed it to the oauth list.

=nat via iPhone

On 2012/03/14, at 12:54, Marius Scurtescu <mscurtescu at google.com> wrote:

> On Wed, Mar 14, 2012 at 9:28 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>> If we�fre 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�ft 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