Thanks Eran. This is much better.
=nat On Sun, Mar 18, 2012 at 6:43 AM, Eran Hammer <e...@hueniverse.com> wrote: > Mike, Nat, > > Does the new text work for you? > > EH > > > -----Original Message----- > > From: breno.demedei...@gmail.com > > [mailto:breno.demedei...@gmail.com] On Behalf Of Breno > > Sent: Saturday, March 17, 2012 12:10 PM > > To: Eran Hammer > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 > > > > 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 > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth