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

[John Bradley <[e-mail]>]

OK with me. 

John B 

Sent from my iPad

On 2012-03-17, at 5:43 PM, 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
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth