Why?
William J. Mills wmi...@yahoo-inc.com schrieb:
I agree that this is something you could do, but it doesn't seem like a good
design pattern.
_
From: Torsten Lodderstedt tors...@lodderstedt.net
To: Eran Hammer-Lahav e...@hueniverse.com; OAuth
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 tors...@lodderstedt.net
To: William J.
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:
On Tue, Jul 12, 2011 at 8:29 AM, William J. Mills wmi...@yahoo-inc.com 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
+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
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
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,
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 +
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
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
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
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
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
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
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
15 matches
Mail list logo
