How about we phrase it the other way: A clients may be implemented as a distributed set of components, each with a different client type and security context (e.g. a distributed client with both a confidential server-based component and a public browser-based component). If the authorization server does not provide support for such clients, or does not provide guidance with regard to their registration, the client SHOULD register each component as a separate client.
This does two thing: put the server's policy first instead of as the exception, and uses SHOULD instead of MUST which seems to be too strong for many people. Better? EH > -----Original Message----- > From: breno.demedei...@gmail.com > [mailto:breno.demedei...@gmail.com] On Behalf Of Breno > Sent: Saturday, March 17, 2012 8:50 AM > To: Eran Hammer > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 > > 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
