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.
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. 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? 2. Should the protocol support dynamic composite values with the added complexity (breaking change)? EHL > -----Original Message----- > From: Breno de Medeiros [mailto:br...@google.com] > 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...@hueniverse.com> > 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:br...@google.com] > >> 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...@hueniverse.com> > >> wrote: > >> > As for the plus encoding we can choose another char or give an > example. > >> > > >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu" > >> > <mscurte...@google.com> > >> 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 > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > >> > >> > >> -- > >> --Breno > > > > > > -- > --Breno _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
