If you don't register the combination, how would anyone know (aside from reading every service specific documentation) what the combination means. As clearly stated in your own list, at a minimum, the location of the credentials is not obvious and must be defined. We had a long discussion on this list about the correct implementation of "token code" as one example.
The cost of registration is VERY low. You don't need an RFC to do it. You just need to publish a specification defining the response type and make it available somewhere stable. For example, on a Google official blog or documentation site, or on the OpenID Foundation site (your personal blog isn't ideal but can also sometime work). Once published, you send an email to the extension list and ask for registration. The template takes no time at all (requested name, your name or your company/organization name, and the location of the specification). You might get some feedback from the designated expert (e.g. if you try to register 'token_and_code' they might suggest changing it to 'token code' or if you try to register 'send_nothing' they will suggest 'none', etc.). Really the only requirement is that you write a short specification defining the combination. If you maintain a public web page with all the combination you defined, you can keep adding those there instead of writing new specification for each new one, as long as you keep the registered values unchanged once registered. So the cost is really insignificant, but the benefit of clarity and interop is significant. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Breno Sent: Wednesday, July 20, 2011 7:52 AM To: Paul Tarjan Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types Comments inline. On Tue, Jul 12, 2011 at 8:23 PM, Paul Tarjan <p...@fb.com<mailto:p...@fb.com>> 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" <e...@hueniverse.com<mailto:e...@hueniverse.com>> 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: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> >> [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] 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: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> >> [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] 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...@hueniverse.com<mailto:e...@hueniverse.com>> >> 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:br...@google.com<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<mailto: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<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<mailto: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<mailto: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<mailto:OAuth@ietf.org> >> >> >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> --Breno >> >> > >> >> >> >> >> >> >> >> -- >> >> --Breno >> > >> >> >> >> -- >> --Breno >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org<mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org<mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >_______________________________________________ >OAuth mailing list >OAuth@ietf.org<mailto:OAuth@ietf.org> >https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
