Hi, Nat Sakimura started a thread on the OpenID Connect list about a breaking change introduced by rev 2.3
The paragraph in question is in section 2.1: "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. The authorization server MAY provider tools to manage such complex clients through a single administration interface." http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-oauth-v2-23.txt You can see the thread here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001672.html This paragraph basically prevents response_type=code+token which is already implemented by many providers and also relied on by OpenID Connect. The intent, I think, was to prevent clients from embedding the client secret meant for a confidential client into a public client. JavaScript based clients using the token flow do not need the client secret, so this concern does not apply. Thoughts? Thanks, Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
