Re: [OAUTH-WG] defining new response types

[Paul Tarjan <[e-mail]>]

I like splitting on space like scopes. But I'm fine with registering all
possible compositions that make sense, if you prefer.


As I posted to the group about a month ago, we are planning on supporting

response_type=none
response_type=code
response_type=token
response_type=signed_request token
response_type=token signed_request
(and maybe "code token"/"token code")

We already have support for response_type=none and the signed_request one
is a few weeks out.

Paul


On 7/12/11 1:35 PM, "Eran Hammer-Lahav" <[e-mail]> 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