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
[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
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
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
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
: 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
; 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
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
, 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
, 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
On Tue, Jul 12, 2011 at 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.
The complexity of composite response types is affecting
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
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
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
14 matches
Mail list logo
