I am proposing the entire removal of: "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."
In particular the example of a server-side component versus browser-based components is particularly unhelpful since it violates the entire principle of why two response_type 'code' and 'token' were defined, and how OAuth2 is typically implemented. That's when I claim this normative language is redefining the protocol. On Thu, Mar 15, 2012 at 12:13, Eran Hammer <e...@hueniverse.com> wrote: > Which text in -25 are you proposing we remove exactly? I can't judge the > text below without the full context of where and how it is proposed in the > current document. > > Also, you are ignoring my detailed analysis of the current facts. We have > two client types and the issue here is what to do with other, undefined > types. > > EH > > > On 3/15/12 11:54 AM, "Breno de Medeiros" <br...@google.com> wrote: > >>My proposal is to remove any reference to registration (which is a red >>herring and has raised all the problems we refer here) and refer to >>client authentication instead. >> >>Proposal: >> >>"Clients may be implemented as a distributed set of components that >>run in different security contexts. For instance, a single client may >>include a webserver component and a script component in a browser. It >>is not appropriate for the different components to utilize the same >>client authentication mechanisms, since client authentication >>credentials that are held securely in one context cannot be deployed >>securely in another. >> >>Servers MUST mitigate security threats from client components that >>cannot hold client credentials as securely by distinguishing them from >>client components that can. Example of suitable measures are: >> >>- Requiring separate registration of components such as web server and >>a mobile application. >>- Restricting the time validity of tokens issued to clients that hold >>no authentication credentials, such as browser script-based >>components." >> >>Please don't truncate explanations in the interest of space if the >>resulting text is confusing and possibly misleading. Better to say >>nothing instead. >> >>On Thu, Mar 15, 2012 at 11:32, Eran Hammer <e...@hueniverse.com> wrote: >>> Here are the facts: >>> >>> The authorization server must know the client type in order to enforce >>>many >>> of the requirements in the specification. >>> The requirement to provide a client type is not decorated with a MUST or >>> SHALL but that is implied. >>> The specification only defines two client types: public and >>>confidential. >>> There is no client type defined for a hybrid client. >>> The specification needs to address the very common use case of clients >>>with >>> both public and private components. >>> >>> I don't want to discuss in the specification how client identifiers are >>> provisioned, nor do I want to discuss the potential binding of response >>> types to client types. But we do need to provide some guidance to >>>clients >>> and authorization servers what to do with clients that do not fit the >>> current type definitions. >>> >>> It is far too late for us to define a new client type, along with all >>>the >>> security considerations that such type imply. Our entire security >>> consideration section and protocol design are based on have a well >>>defined >>> client type. >>> >>> Requiring separate registration for each component is the most >>> straight-forward solution. Allowing the authorization server to offer >>> alternatives is the backdoor to enable extensibility. >>> >>> Within these constraints, I am open to other prose or creative >>>solutions. >>> But the add-ons proposed are all ugly hacks. They clarify specific >>>questions >>> raised which I do not believe represent the core confusion here which is >>> what is the right way to handle hybrid clients. >>> >>> The best way to move forward is to take a minute and ask the group to >>>share >>> how they handle such cases or how they think they should be handled. >>>Based >>> on that we can come up with a clear solution. >>> >>> EH >>> >>> From: Breno de Medeiros <br...@google.com> >>> Date: Thu, 15 Mar 2012 09:56:13 -0700 >>> To: Eran Hammer-Lahav <e...@hueniverse.com> >>> Cc: Nat Sakimura <sakim...@gmail.com>, OAuth WG <oauth@ietf.org> >>> >>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 >>> >>> >>> >>> 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 >> >> >> >>-- >>--Breno > -- --Breno _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
