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? 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
