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

[Eran Hammer <[e-mail]>]

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.

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