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

[Nat Sakimura <[e-mail]>]

Thanks Eran.

This is much better.

=nat

On Sun, Mar 18, 2012 at 6:43 AM, Eran Hammer <[e-mail]> wrote:

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



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en