That is much clearer. Thank you. On Sat, Mar 17, 2012 at 9:17 AM, Eran Hammer <e...@hueniverse.com> wrote: > 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
-- Breno de Medeiros _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
