Re: [OAUTH-WG] defining new response types

[John Bradley <[e-mail]>]

The functionality is important.

I was under the impression from Paul Tarjan that this had been agreed at the last F2F.

While I am not emotionally attached to this specific request syntax, we do need this functionality.

John Bradley

On 2011-07-12, at 4:35 PM, Eran Hammer-Lahav wrote:

> I will withdraw my objections to the change (parsing the response_type string) if enough support is present. If you care about it, please speak out now.
> 
> EHL
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Mike Jones
>> Sent: Tuesday, July 12, 2011 1:32 PM
>> To: OAuth WG
>> Subject: Re: [OAUTH-WG] defining new response types
>> 
>> As a data point motivating this functionality, the OpenID Connect Core spec
>> currently includes:
>> 
>>   response_type
>>      A space delimited, case sensitive list of string
>>      values (Pending OAuth 2.0 changes).  Acceptable values include
>>      "code", "token", and "none".  The value MUST include "code" for
>>      requesting an Authorization Code, "token" for requesting an Access
>>      Token, and "none" if no response is needed.
>> 
>> The OpenID Connect Session Management spec also defines an "id_token"
>> response_type.  Combinations of these (other than "none") are meaningful
>> and used.
>> 
>> The syntax for this can change, but this functionality is very important to
>> OpenID Connect as it is currently written.
>> 
>> 				Thanks,
>> 				-- Mike
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Breno de Medeiros
>> Sent: Tuesday, July 12, 2011 11:48 AM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] defining new response types
>> 
>> On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav <[e-mail]>
>> wrote:
>>> That's pretty farfetched. In previous versions we had 'code_and_token'
>> which was a composite value but without any special characters. If people
>> think that we need to force such values to avoid this claimed developer
>> confusion, let's drop the + and be done.
>>> 
>> 
>> Maybe far fetched, but it's already available in our production environment --
>> we had implemented the code_and_token approach earlier (though not
>> documented it) but abandoned that route as we thought the exponential
>> explosion was harmful when we started contemplating adding new types
>> and allowing various combinations of them.
>> 
>>> The only requirement I was asked to cover was to allow response type
>> extensibility. If there is WG consensus to also support the requirement of
>> composite values using any order, we can discuss that.
>> 
>> Let's.
>> 
>>> 
>>> In addition, defining a parsing method adds a significant amount of new
>> complexity beyond just splitting the string:
>>> 
>>> * It allows for composite values that make no sense (since anything goes,
>> composite values are not registered, just the components).
>>> * Additional error codes are needed to indicate bad format, unsupported
>> values (specify which one), unsupported combinations, etc.
>>> * Developers lose the benefit of a simple registry with every possible
>> combination they may choose.
>>> 
>>> So the two questions are:
>>> 
>>> 1. Do you find the + proposal as defined in -18 to be useful or confusing?
>> 
>> It is ugly.
>> 
>>> 2. Should the protocol support dynamic composite values with the added
>> complexity (breaking change)?
>> 
>> That's my preference.
>> 
>>> 
>>> EHL
>>> 
>>>> -----Original Message-----
>>>> From: Breno de Medeiros [mailto:[e-mail]]
>>>> Sent: Tuesday, July 12, 2011 11:18 AM
>>>> To: Eran Hammer-Lahav
>>>> Cc: Marius Scurtescu; OAuth WG
>>>> Subject: Re: [OAUTH-WG] defining new response types
>>>> 
>>>> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav
>>>> <[e-mail]>
>>>> wrote:
>>>>> Requiring parsing of the response type parameter is a big change at
>>>>> this
>>>> point. Even if it is a decent idea, I'm against it for the sole
>>>> reason that I don't want to introduce such a change - we're done.
>>>>> 
>>>>> The + character makes reading values easier because it give
>>>>> composites of
>>>> existing, individually defined values, a special meaning to *people*,
>>>> but it does not change any existing code or adds any work. Servers
>>>> will still perform simple string comparison. Parsing a list of values is
>> unnecessary complexity.
>>>> Developers can learn to put values in their expected order (since
>>>> they are all going to cut-n-paste anyway).
>>>> 
>>>> I disagree. I believe that servers will either not support the
>>>> composite types at all, or will allow developers to enter it into any
>>>> order to avoid developer pain.
>>>> 
>>>> Also, developers will _not_ cut-and-paste. They will expect the fact
>>>> that order is not meaningful by interacting with providers that don't
>>>> perform exact string matching and then have interoperability issues
>>>> with compliant implementations.
>>>> 
>>>>> 
>>>>> I rather drop the special character then add parsing, but I think
>>>>> it is a useful
>>>> *convention*.
>>>>> 
>>>>> Do people want to keep it or drop it?
>>>>> 
>>>>> EHL
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Breno de Medeiros [mailto:[e-mail]]
>>>>>> Sent: Tuesday, July 12, 2011 10:59 AM
>>>>>> To: Eran Hammer-Lahav
>>>>>> Cc: Marius Scurtescu; OAuth WG
>>>>>> Subject: Re: [OAUTH-WG] defining new response types
>>>>>> 
>>>>>> Imposing order and exact string matching on response_type's while
>>>>>> simultaneously supporting a special character '+' and introducing
>>>>>> the concept of composite response_type is a poor compromise,
>> IMNSHO.
>>>> What
>>>>>> is the rationale to fear allowing multiple-valued response_type as
>>>>>> we have for other parameters in the spec?
>>>>>> 
>>>>>> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav
>>>>>> <[e-mail]>
>>>>>> wrote:
>>>>>>> As for the plus encoding we can choose another char or give an
>>>> example.
>>>>>>> 
>>>>>>> On Jul 11, 2011, at 18:07, "Marius Scurtescu"
>>>>>>> <[e-mail]>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> If I read section 8.4 correctly it seems that new response
>>>>>>>> types can be defined but composite values must be registered
>> explicitly.
>>>>>>>> 
>>>>>>>> I don't think this approach scales too well. OpenID Connect for
>>>>>>>> example is adding a new response type: id_token.
>>>>>>>> 
>>>>>>>> id_token can be combined with either code or token and
>>>>>>>> potentially with both of them, the following combinations must
>>>>>>>> be registered as a
>>>>>>>> result:
>>>>>>>> code+id_token
>>>>>>>> token+id_token
>>>>>>>> code+token+id_token
>>>>>>>> 
>>>>>>>> and this assumes that code+token is already registered.
>>>>>>>> 
>>>>>>>> I think it makes more sense to define response_type as a space
>>>>>>>> separated list of items, where each item can be individually
>>>>>>>> registered. I do realize that this complicates things quite a
>>>>>>>> bit (not we have to define and deal with both composite
>>>>>>>> response_type and the individual items).
>>>>>>>> 
>>>>>>>> As a side note, using + as separator could cause lots of problems.
>>>>>>>> If people naively type "code+toke" it will be decoded as "code
>> token".
>>>>>>>> No one will remember the hex code for +.
>>>>>>>> 
>>>>>>>> Marius
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> --Breno
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> --Breno
>>> 
>> 
>> 
>> 
>> --
>> --Breno
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth