Am 28.02.2011 23:58, schrieb Marius Scurtescu:
On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg
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 saf
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
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
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 highe
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 fr
On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg
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 with refresh tokens o
+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
https://www.ietf.org/mailman/listinf
Am 18.02.2011 18:40, schrieb Marius Scurtescu:
On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloin 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 can replace the refresh
On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloin 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 side mechanism for r
curtescu
> Sent by: oauth-boun...@ietf.org
>
> 16/02/2011 21:38
>
> To
>
> Eran Hammer-Lahav
>
> cc
>
> OAuth WG
>
> Subject
>
> Re: [OAUTH-WG] Draft -12 feedback deadline
>
> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav
> wrote:
> > Th
; From: 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
> wrote:
On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav 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 user-agent and it coul
Wednesday, February 16, 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
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 a
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 (http://tools.ietf.org/h
On Wed, Feb 16, 2011 at 11:06 AM, William Mills 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 dance.
Marius
___
; Sent: Wednesday, February 16, 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
> wrote:
> >
> >
> >> -Original Message-
> >> From: Mar
Yes.
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Wednesday, February 16, 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, Er
On Wed, Feb 16, 2011 at 10:43 AM, Eran Hammer-Lahav 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 whole pr
> -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 mor
> -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
On Wed, Feb 16, 2011 at 9:00 AM, Eran Hammer-Lahav 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:
> -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 authenti
> -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 th
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, Eran
> -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 SH
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 "capabil
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 implementatio
- 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.
- 4.1.2 Authorization Response. Minor typo in last sentence on page
16: "size of any value is issues" => "size of
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 b
30 matches
Mail list logo
