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

[Eran Hammer <[e-mail]>]

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