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

Nat Sakimura sakimura at gmail.com
Wed Mar 14 14:22:14 UTC 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120314/fcf46bba/attachment-0001.html>


More information about the Openid-specs-ab mailing list