To summarize, I am weary of registration normative language that appears to disallow common practice implemented by servers to securely support multi-component applications. If these common practices will be non-compliant (or at least it appears to be so on first reading by many different people with detailed knowledge of the spec), isn't it incumbent on this spec to provide guidance on _how_ different components of an application will interoperate under different registration? At least for the very common case of a webserver + browser component, the importance of which is already enshrined in the spec by the definition of two response_types and flows?
On Thu, Mar 15, 2012 at 3:54 PM, Breno de Medeiros <br...@google.com> wrote: > On Thu, Mar 15, 2012 at 15:43, Eran Hammer <e...@hueniverse.com> wrote: >> I don't know how to better explain myself. Forget about the text you have >> issue with. Just answer this: >> >> Reading the specification (with that text removed), what happens when a >> hybrid client wants to register? What client type does it provide? How >> should the server handle this case? > > In the example case of the webserver + browser-based client > components, I think the server should just allow it. The browser does > not need to expose the client_secret since it requires no > authentication credentials. The webserver should use the client > credentials acquired during registration to authenticate itself when > using the code flow. > > It's more interesting when mobile applications and webserver want to > share credentials. The mitigation strategy of limiting lifetime of > tokens may not work in this case. In general the registration server > should not allow the use of a single registration in this case. This > case is different from the above in the sense that installed > applications are typically _also_ using the 'code' flow, but from a > different security context. A server could allow both clients to share > the same registration information, but segregate the set of redirect > URLs and tie the code to each security context and apply different > client authentication requirements to each. Or the server could > require separate client registration for each component. > >> >> EH >> >>> -----Original Message----- >>> From: Breno de Medeiros [mailto:br...@google.com] >>> Sent: Thursday, March 15, 2012 2:12 PM >>> To: Eran Hammer >>> Cc: Nat Sakimura; OAuth WG >>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 >>> >>> On Thu, Mar 15, 2012 at 13:13, Eran Hammer <e...@hueniverse.com> >>> wrote: >>> > Ok. That's much better than my guess that you wanted to drop all the >>> > registration text from the specification. >>> > >>> > What I'm looking for is a simple text that answers the question: >>> > >>> > "What to do if my client isn't simply public or confidential?" >>> > >>> > If we just drop the current text, the answer is implicitly "you can't >>> > have such a client" because there is no way to register a client of >>> > any other type. >>> > >>> > So let's try this again, and focus exclusively on answering this question. >>> > My text takes a position which is, "you can't - unless". Your >>> > suggestion is more of a vague discussion of the topic. I'd like to see >>> > clear, normative answer to this question. >>> >>> The current version is normative but far from clear. In fact, the most >>> natural >>> interpretation is that it bans normal practice and throws away the work that >>> was done in defining different flow types to support normal practice. >>> >>> 1. I don't see the need or desirability to put normative language on >>> registration practices. >>> 2. The contents of said normative language are harmful. >>> >>> I suggest two alternatives: >>> >>> 1. Remove the language. >>> 2. Substitute the language by non-normative informative discussion. >>> >>> You can also do other things, like introduce normative language that makes >>> sense. But I have not yet seen proposed language that would be acceptable. >>> >>> > >>> > EH >>> > >>> > >>> > On 3/15/12 12:30 PM, "Breno de Medeiros" <br...@google.com> wrote: >>> > >>> >>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 >>> > >>> >>> >>> >>> -- >>> --Breno > > > > -- > --Breno > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
