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

[Eran Hammer <[e-mail]>]

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