Sorry, I meant response_type 'none' and _not_ 'node' On Wed, Jul 20, 2011 at 7:51 AM, Breno <[email protected]> wrote:
> > > Comments inline. > > On Tue, Jul 12, 2011 at 8:23 PM, Paul Tarjan <[email protected]> wrote: > >> I like splitting on space like scopes. But I'm fine with registering all >> possible compositions that make sense, if you prefer. >> > > I agree with Marius that registering the combinations are not useful, > however also agree with Paul that it's not a show stopper. > > >> >> >> 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") >> >> > Google is planning to support the following combinations: > > response_type=node > response_type=id_token > response_type=code > response_type=token > response_type=code token (in either order, fragment-encoded response) > response_type=code id_token (in either order, query-encoded response) > response_type=token id_token (in either order, fragment-encoded response) > response_type=code token id_token (in any possible order, fragment-encoded > response) > > > >> 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" <[email protected]> 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 >> > > > > -- > Breno de Medeiros > > -- Breno de Medeiros
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
