Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

[Mike Jones <[e-mail]>]

Much better.  Thanks for working with Breno on the new wording.

				-- Mike

-----Original Message-----
From: Eran Hammer [mailto:[e-mail]] 
Sent: Saturday, March 17, 2012 2:43 PM
To: Mike Jones; 'Nat Sakimura ([e-mail])'
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

Mike, Nat,

Does the new text work for you?

EH

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] 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-mail]>
> 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: [e-mail]
> >> [mailto:[e-mail]] 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
> <[e-mail]>
> >> wrote:
> >> > On Thu, Mar 15, 2012 at 15:43, Eran Hammer <[e-mail]>
> >> 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:[e-mail]]
> >> >>> 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-mail]>
> >> >>> 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" <[e-mail]>
> >> 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-mail]>
> >> >>> 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"
> <[e-mail]>
> >> >>> 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-mail]>
> >> >>> 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 <[e-mail]>
> >> >>> >>>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
> >> >>> >>>>> To: Eran Hammer-Lahav <[e-mail]>
> >> >>> >>>>> Cc: Nat Sakimura <[e-mail]>, OAuth WG
> >> >>> <[e-mail]>
> >> >>> >>>>>
> >> >>> >>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
> rev.
> >> >>> >>>>> 23
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer 
> >> >>> >>>>><[e-mail]>
> >> >>> >>>>>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: [e-mail] [mailto:oauth-
> >> [e-mail]]
> >> >>> >>>>>>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
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >>
> >> --
> >> Breno de Medeiros
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
> Breno de Medeiros