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

[Eran Hammer <[e-mail]>]

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:[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:[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