Am 28.02.2011 23:58, schrieb Marius Scurtescu:
On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg
igor.faynb...@alcatel-lucent.com wrote:
+1
Igor
Torsten Lodderstedt wrote:
...
I'm in favour to add the refresh token parameter to the implicit grant
flow as it would make it more useable for
+1
Igor
Torsten Lodderstedt wrote:
...
I'm in favour to add the refresh token parameter to the implicit grant
flow as it would make it more useable for native apps.
___
OAuth mailing list
OAuth@ietf.org
On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg
igor.faynb...@alcatel-lucent.com wrote:
+1
Igor
Torsten Lodderstedt wrote:
...
I'm in favour to add the refresh token parameter to the implicit grant
flow as it would make it more useable for native apps.
I think it is much safer to go
Given these questions, I am wondering, why does the Implicit Grant flow NOT
have an authorization code step? Having one, would keep architecture of AS and
TS clearly separate.
One down side is that issuing of access/refresh token would now have to be
opened to SHOULD authenticate the client
Cannot help harping... It is exactly this type of a question that Phil
asked that makes a document on the use cases necessary!
Igor
Phil Hunt wrote:
...
What was the original case for this flow? That should point us as to why the
separate flow and whether refresh makes sense given the
One more round trip is often too slow.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phil Hunt
Sent: Monday, February 28, 2011 3:18 PM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
Given
[mailto:oauth-boun...@ietf.org] On Behalf
Of Phil Hunt
Sent: Monday, February 28, 2011 3:18 PM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
Given these questions, I am wondering, why does the Implicit Grant flow
NOT have an authorization code step
Am 18.02.2011 18:40, schrieb Marius Scurtescu:
On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloinmark.mcgl...@ie.ibm.com wrote:
Marius
Isn't the risk of the refresh token leaking the same as the risk of the
access token leaking, i.e. why not provide both?
Sure, but refresh tokens never die.
One
...@google.com
Sent by: oauth-boun...@ietf.org
16/02/2011 21:38
To
Eran Hammer-Lahav e...@hueniverse.com
cc
OAuth WG oauth@ietf.org
Subject
Re: [OAUTH-WG] Draft -12 feedback deadline
On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav
e...@hueniverse.com wrote:
The reason why we
On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloin mark.mcgl...@ie.ibm.com wrote:
Marius
Isn't the risk of the refresh token leaking the same as the risk of the
access token leaking, i.e. why not provide both?
Sure, but refresh tokens never die.
IMO, the refresh token
just provides a server
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday, January 26, 2011 12:09 PM
- 4.3. Resource Owner Password Credentials. The 3rd paragraph states that
the client MUST discard the credentials once it obtains an access token. I
think it SHOULD
Re: 4.3. This could be something to put in security considerations. Since
there will be reasonable cases where for example a password hash is retained.
And as indicated by Eran, this is a best practice rather then an inter-op issue.
Phil
phil.h...@oracle.com
On 2011-02-16, at 8:34 AM,
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday, January 26, 2011 12:09 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
- 4.1. Authorization Code. It is stated that authorization code is suitable
-Original Message-
From: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Thursday, January 27, 2011 2:37 AM
-- 3.1.1, 4.1.2, and Out-of-Band flows
It is an important consideration for us that clients that cannot capture a
redirect from the user-agent be able to use authentication
On Wed, Feb 16, 2011 at 9:00 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday, January 26, 2011 12:09 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Richer, Justin P.
Sent: Thursday, January 27, 2011 12:05 PM
1.2
Tokens may be pure capabilities. To a non-security-engineer such as
myself, this bit reads very oddly on its own. I
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday, February 16, 2011 9:05 AM
Yes, I understand. But Native Apps have no appropriate flow now, and they
started the whole protocol.
I am not sure they started the whole protocol (it was more like
On Wed, Feb 16, 2011 at 10:43 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday, February 16, 2011 9:05 AM
Yes, I understand. But Native Apps have no appropriate flow now, and they
started the
, 2011 10:58 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
On Wed, Feb 16, 2011 at 10:43 AM, Eran Hammer-Lahav
e...@hueniverse.com wrote:
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday
On Wed, Feb 16, 2011 at 11:06 AM, William Mills wmi...@yahoo-inc.com wrote:
Token endpoint with username/password credential doesn't solve this? Depends
on the auth scheme of course, but Bearer should provide a solution?
Not at all, in most case native apps must use the browser based 3-legged
Exactly Marius, and in most cases the app will want to procure a
refresh token as a result of the dance so it won't have to put the
user though the authorization process again and again. Unless I'm
mistaken, the implicit grant provides no means of obtaining a refresh
token
The implicit grant still requires a redirect of some kind, so many
native apps can just as easily use the web server flow as the implicit
flow. I personally don't see how the implicit flow is better suited than
the web flow in this case. However, neither of these are ideally suited
for native
, 2011 12:07 PM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
Exactly Marius, and in most cases the app will want to procure a refresh
token as a result of the dance so it won't have to put the user though the
authorization process again and again. Unless
On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
The reason why we don't return a refresh token in the implicit grant is
exactly because there is no client authentication...
Not sure that's the main reason. AFAIK it is because the response is
sent through the
: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday, February 16, 2011 1:39 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav
e...@hueniverse.com wrote:
The reason why we
On Jan 26, 2011, at 9:09 PM, Marius Scurtescu wrote:
- 4.1. Authorization Code. It is stated that authorization code is
suitable for clients that can hold a secret. Not necessarily true, it
is the best flow for native apps, for example.
We concur with this as well. Our current implementation
Overall, I much prefer the organization of this document, and I think it's
going to make a lot more sense to implementers. My thoughts, per section:
1.2
Tokens may be pure capabilities. To a non-security-engineer such as myself,
this bit reads very oddly on its own. I understand that
I plan to publish a quick fix to editorial issues raised in a -13 on Monday
1/31. If you have editorial feedback, please post it to the list by Friday 1/28
so that I can respond and incorporate if needed. This is not a deadline for
normative issues, only editorial, but you can post feedback on
28 matches
Mail list logo
