On Thu, Mar 15, 2012 at 07:45, Eran Hammer <e...@hueniverse.com> wrote:
> This add-on is unnecessary. It already says the authorization server can > handle it any way it wants. The fact that other registration options are > possible clearly covers the client identifier reuse case. As for the > response type, that’s not an issue but more of an optimization for an edge > case raised. > It still feels like a horse by committee to me. "unless the authorization server provides other registration options to specify such complex clients." seems a very round about way to say that the core spec already provides for such arrangements in the most common scenario. It is a bit of a stretch to say that the server provides "other registration options" by simply following strategy already laid out in the spec. In particular, I feel that this wording will be harmful to register extended behavior, e.g., alternative response_types by leading to fruitless conversations about spec compliance in the absence of real security risks. I do not believe the current text is the best representation of the spirit in which the spec was written (in particular the effort to specify two flows in detail to deal with precisely this issue) and possibly lead to harmful future interpretation. > **** > > ** ** > > EH**** > > ** ** > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Nat Sakimura > *Sent:* Thursday, March 15, 2012 2:04 AM > *To:* Breno de Medeiros; OAuth WG > > *Subject:* Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23**** > > ** ** > > ** ** > > So, Eran's first proposal: **** > > ** ** > > 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, unless the authorization > server provides other registration options to specify such complex > clients. **** > > ** ** > > kind of meets my concern. There seems to be another issue around the > usefulness of return_type in such case raised by Breno, and if I understand > it correctly, Eran's answer was that these separate components may have the > same client_id so that return_type is a valid parameter to be sent at the > request. **** > > ** ** > > So, to clarify these, perhaps changing the above text slightly to the > following solves the problem? **** > > ** ** > > 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, unless the authorization > server provides other registration options to specify such complex > clients. **** > > Each component MAY have the same client_id, in which case the server *** > * > > judges the client type and the associated security context based on > the response_type parameter in the request. **** > > ** ** > > Would it solve your problem, Breno? **** > > ** ** > > Best, **** > > ** ** > > =nat**** > > ** ** > -- --Breno
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
