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

Richer, Justin P. jricher at mitre.org
Wed Mar 14 11:33:37 UTC 2012


The way I read it, "code token" is its own type, and it needs to be treated 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<mailto: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/e9fc9979/attachment-0001.html>


More information about the Openid-specs-ab mailing list