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
