Re: [OAUTH-WG] defining new response types

2011-07-12 Thread Paul Tarjan
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 re

Re: [OAUTH-WG] defining new response types

2011-07-12 Thread Marius Scurtescu
On Tue, Jul 12, 2011 at 1:35 PM, Eran Hammer-Lahav 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 mostly authorization s

Re: [OAUTH-WG] defining new response types

2011-07-12 Thread John Bradley
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: > I will

Re: [OAUTH-WG] defining new response types

2011-07-12 Thread Eran Hammer-Lahav
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

Re: [OAUTH-WG] defining new response types

2011-07-12 Thread Mike Jones
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 "

Re: [OAUTH-WG] defining new response types

2011-07-12 Thread Breno de Medeiros
On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav 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

Re: [OAUTH-WG] defining new response types

2011-07-12 Thread Eran Hammer-Lahav
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 c

Re: [OAUTH-WG] defining new response types

2011-07-12 Thread Breno de Medeiros
On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav 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 readi

Re: [OAUTH-WG] defining new response types

2011-07-12 Thread 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, individu

Re: [OAUTH-WG] defining new response types

2011-07-12 Thread Breno de Medeiros
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 paramete

Re: [OAUTH-WG] Refresh token security considerations

2011-07-12 Thread Phil Hunt
+1 Maybe either way at the issuers discretion (optional) until we have a strong feeling why one technique is particularly problematic. i.e. if the server chooses to provide a new refresh token the old token is expired. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011

Re: [OAUTH-WG] Refresh token security considerations

2011-07-12 Thread Brian Eaton
On Tue, Jul 12, 2011 at 8:29 AM, William J. Mills wrote: > Why would you re-issue a refresh token every usage?  What's the use case > where this makes sense? It's key rotation built into the protocol. Even if a refresh token is stolen, it's going to become useless to the attacker very quickly.

[OAUTH-WG] UMA/OAuth2.0 Webinar (Wednesday 13 July / 12noon-EST)

2011-07-12 Thread Thomas Hardjono
Folks, For those who are interested in UMA and how it builds on top OAuth2.0, there will be a free public webinar on UMA tomorrow Wednesday July 13th at 12noon-EST (9AM-Pacific). The presentation should cover much of the UMA Core draft. Registration link can be found here: http://kantarainitiat

Re: [OAUTH-WG] Refresh token security considerations

2011-07-12 Thread William J. Mills
Why would you re-issue a refresh token every usage?  What's the use case where this makes sense? The way I always think about the design is that refresh tokens are indended to be multi-use.  From: Torsten Lodderstedt To: William J. Mills ; Eran Hammer-Lahav

Re: [OAUTH-WG] Refresh token security considerations

2011-07-12 Thread Torsten Lodderstedt
Why? "William J. Mills" schrieb: I agree that this is something you could do, but it doesn't seem like a good design pattern. _ From: Torsten Lodderstedt To: Eran Hammer-Lahav ; OAuth WG Sent: Sunday, July 10, 2011 1:21 AM Subject: Re: [OAUTH-WG