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

[Breno de Medeiros <[e-mail]>]

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