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

Brian Campbell bcampbell at pingidentity.com
Wed Mar 14 13:32:25 UTC 2012


A related question came up on the OAuth WG list:
http://www.ietf.org/mail-archive/web/oauth/current/msg08548.html
though I don't know if that provides much guidance.

On Wed, Mar 14, 2012 at 7:22 AM, Nat Sakimura <sakimura at gmail.com> 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
>


More information about the Openid-specs-ab mailing list