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

[Breno <[e-mail]>]

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