Re: [OAUTH-WG] defining new response types

[Eran Hammer-Lahav <[e-mail]>]

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