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: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] 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 <[email protected]> >> 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:[email protected]] >>>> 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 >>>> <[email protected]> >>>> 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:[email protected]] >>>>>> 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 >>>>>> <[email protected]> >>>>>> wrote: >>>>>>> As for the plus encoding we can choose another char or give an >>>> example. >>>>>>> >>>>>>> On Jul 11, 2011, at 18:07, "Marius Scurtescu" >>>>>>> <[email protected]> >>>>>> 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 >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> --Breno >>>>> >>>> >>>> >>>> >>>> -- >>>> --Breno >>> >> >> >> >> -- >> --Breno >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
