This was already raised and addressed on this list last week. When someone defines and registers code+token, that specification must define how such a client is registered in light of the text below. This might mean defining a new client type, choosing the confidential client type with other normative text limiting the use of the secret in the public component, etc.
IOW, this section doesn't break anything because there is nothing else defined to break. There is no way to avoid explicitly defining these requirements for a code+token response type, or any other new response type for that matter. The text below is required to ensure that the authorization server can properly enforce the rest of the normative security language in the specification. EH > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Wednesday, March 14, 2012 9:53 AM > To: OAuth WG > Cc: Breno de Medeiros > Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
