On Wed, Jul 20, 2011 at 8:42 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> 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. > Sounds good. > **** > > ** ** > > 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> 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> 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] 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] 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> > >> 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] > >> >> 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 > >> > > >> > >> > >> > >> -- > >> --Breno > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >_______________________________________________ > >OAuth mailing list > >OAuth@ietf.org > >https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth**** > > > > > -- > Breno de Medeiros**** > -- Breno de Medeiros
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
