Subject: [OAUTH-WG] defining new response types

From: Marius Scurtescu <[email-masked]>
Date: Mon, 11 Jul 2011 18:07:14 -0700

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 11 Jul 2011 18:49:28 -0700

You are over complicating it. You can define anything you want. But if you want to use the special + character, each of the parts must be defined and registered. If parts of a combination don't make sense on their own use something else to join them like underscore. 

EHL

On Jul 11, 2011, at 18:07, "Marius Scurtescu" <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 11 Jul 2011 18:51:23 -0700

As for the plus encoding we can choose another char or give an example.

---

From: Breno de Medeiros <[email-masked]>
Date: Tue, 12 Jul 2011 10:59:23 -0700

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?

-- 
--Breno

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 12 Jul 2011 11:10:47 -0700

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 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-masked]]
> 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
> 
> 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?
> 
> >> 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).
> >>
> >> people naively type "code+toke" it will be decoded as "code token".
> >> No one will remember the hex code for +.
> >>
> >> Marius

---

From: Breno de Medeiros <[email-masked]>
Date: Tue, 12 Jul 2011 11:18:06 -0700

> 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…

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.

-- 
--Breno

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 12 Jul 2011 11:36:23 -0700

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.

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.

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?
2. Should the protocol support dynamic composite values with the added complexity (breaking change)?

EHL

> Sent: Tuesday, July 12, 2011 11:18 AM
> To: Eran Hammer-Lahav
> > 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.
> 
> >
> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav
> >> <[email-masked]>
> >> wrote:
> >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu"
> >> > <[email-masked]>
> >> wrote:
> >> >
> >> >> If I read section 8.4 correctly it seems that new response types
> >> >> can be defined but composite values must be registered explicitly.
> >> >>
> >> >> (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".

---

From: Breno de Medeiros <[email-masked]>
Date: Tue, 12 Jul 2011 11:48:22 -0700

> 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 thi…

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.

> 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.

-- 
--Breno

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Jul 2011 20:31:56 +0000

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-masked] [mailto:[email-masked]] 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

> 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 thi…

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.

Let's.

It is ugly.

That's my preference.

>> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav 
>> <[email-masked]>
>> wrote:
>> 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.
>> >
>> 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 rather drop the special character then add parsing, but I think 
>> > it is a useful
>> *convention*.
>> >
>> >> 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?
>> >>
>> >> >> If I read section 8.4 correctly it seems that new response 
>> >> >> types can be defined but composite values must be registered explicitly.
>> >> >>
>> >> >> 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
>> >> >>
>> >> >> 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).
>> >> >>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 12 Jul 2011 13:35:21 -0700

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

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mike Jones
> Sent: Tuesday, July 12, 2011 1:32 PM
> To: OAuth WG
> 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
> 
> > 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.

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Jul 2011 18:12:23 -0400

The functionality is important.

I was under the impression from Paul Tarjan that this had been agreed at the last F2F.

While I am not emotionally attached to this specific request syntax, we do need this functionality.

John Bradley

On 2011-07-12, at 4:35 PM, Eran Hammer-Lahav wrote:

>> Of Breno de Medeiros

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 12 Jul 2011 15:18:08 -0700

> 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.

The complexity of composite response types is affecting mostly
authorization servers. Hiding this behind the requirement to
explicitly register all combinations is not helping much IMO. Most
auth server implementations will end up parsing the list and looking
at the individual elements anyhow.

Marius

---

From: Paul Tarjan <[email-masked]>
Date: Wed, 13 Jul 2011 03:23:38 +0000

I like splitting on space like scopes. But I'm fine with registering all
possible compositions that make sense, if you prefer.

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")

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-masked]> 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
>
>> As a data point motivating this functionality, the OpenID Connect Core
>>spec
>> currently includes:
>> 
>>    response_type
>>environment --
>> >> will still perform simple string comparison. Parsing a list of
>>values is
>> unnecessary complexity.

---

From: Breno <[email-masked]>
Date: Wed, 20 Jul 2011 07:51:32 -0700

Comments inline.

> 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.

> (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)

-- 
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Wed, 20 Jul 2011 07:52:19 -0700

Sorry, I meant response_type 'none' and _not_ 'node'

response_type=id_token
>> >> > * Developers lose the benefit of a simple registry with every
>> possible
>> >> combination they may choose.
>> >> >
>> >> > 2. Should the protocol support dynamic composite values with the
>> added
>> >> complexity (breaking change)?
>> >>
>> >> That's my preference.
>> >>
>> >> >
>> >> > EHL
>> >> >
>> >> >> > Requiring parsing of the response type parameter is a big change
>> at
>> >> >> > this

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 20 Jul 2011 08:42:52 -0700

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: [email-masked] [mailto:[email-masked]] 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 <[email-masked]<mailto:[email-masked]>> 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.

response_type=none
response_type=code
response_type=token

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)

Paul

On 7/12/11 1:35 PM, "Eran Hammer-Lahav" <[email-masked]<mailto:[email-masked]>> wrote:

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>> Of Mike Jones
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>> Of Breno de Medeiros
>> On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
>> wrote:
>> >> From: Breno de Medeiros [mailto:[email-masked]<mailto:[email-masked]>]
>> >> <[email-masked]<mailto:[email-masked]>>
>> >> wrote:
>> >> >> From: Breno de Medeiros [mailto:[email-masked]<mailto:[email-masked]>]
>> >> >> <[email-masked]<mailto:[email-masked]>>
>> >> >> wrote:
>> >> >> > <[email-masked]<mailto:[email-masked]>>
>> >> >> wrote:
>> >> >> >
>> >> >> >> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Wed, 20 Jul 2011 08:51:25 -0700

On Wed, Jul 20, 2011 at 8:42 AM, Eran Hammer-Lahav <[email-masked]>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:* [email-masked] [mailto:[email-masked]] *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 <[email-masked]> wrote:****
>
> possible compositions that make sense, if you prefer.****
>
> ** **
>
> however also agree with Paul that it's not a show stopper.****
>
>  ****
>
>
>
> (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)****
> ** **
>  ****
> Paul****
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
>
> --
> Breno de Medeiros****
>

-- 
Breno de Medeiros