On Wed, Apr 14, 2010 at 5:06 PM, Allen Tom wrote:
> As a security person, I'm hesitant to bring this up, but perhaps the Device
> Flow should just be the flow for native client apps.
I'm open to this.
I'd suggest differentiating between devices that can open a web
browser (native apps), and apps
On Tue, Apr 13, 2010 at 1:35 PM, Luke Shepard wrote:
> The Native Application and the User-Agent flows should be combined into one
> flow. The combined flow works for all client-side code. This is how it was
> in David’s original draft; I’d love some help understanding why it was
> separated again
Hannes,
I haven't seen a tremendous amount of response to this meeting, but it
seems like a good idea, even though I cannot be there in person. I
would ask two things:
1. Could we have remote participation so that those of us who are
unable to travel can join?
2. Can you confirm that OAU
I believe this is basically how the draft-hardt-oauth-o1 Rich App profile
worked. It probably could have benefited from requiring that response
parameters were returned behind a # fragments on callback URLs. It also could
use the callback URL on the access token request, and the refresh toke
Yes, the device flow could be made to work, but isn't the current
native app flow more secure? Why fallback to this?
My guess is that most end users will not know what to make of all that
explanation and will just click one of the next buttons. But that's
just a wild guess (or fear).
Marius
On
On Wed, Apr 14, 2010 at 4:24 PM, Luke Shepard wrote:
>> Assuming simplification is the main driver, I think it is feasible to
>> combine Web Callback and Native Application, with no penalty.
>
> How would that work? The Web Callback flow assumes the presence of a
> client_secret, while the Native
On Wed, Apr 14, 2010 at 4:23 PM, Luke Shepard wrote:
> To get a verification code in the Native App scenario, the app either:
>
> 1/ Asks the user to copy/paste it.
> 2/ Retrieves it programmatically.
>
> For 1/, I haven't seen a widely deployed desktop app use the copy/paste
> scenario. For apps
> Assuming simplification is the main driver, I think it is feasible to
> combine Web Callback and Native Application, with no penalty.
How would that work? The Web Callback flow assumes the presence of a
client_secret, while the Native Application does not have a secret.
To get a verification code in the Native App scenario, the app either:
1/ Asks the user to copy/paste it.
2/ Retrieves it programmatically.
For 1/, I haven't seen a widely deployed desktop app use the copy/paste
scenario. For apps that do want the user to copy/paste a code, we have designed
the
It's not limited to only apps that can register custom schemes, but I do agree
it doesn't solve all scenarios.
My main concern is that the current language seems to preclude a number of
highly usable callback based scenarios that are viable with Native apps in 2
ways.
1. the Web Callback fl
On Wed, Apr 14, 2010 at 2:19 PM, Chuck Mortimore
wrote:
> As far as 2,3, and 4, the window title approach is really irrelevant.
> Instead, the client will either directly handle callbacks through a
> custom scheme, or be able to recognize when a known callback URL has been
> loaded, and hence c
As far as 2,3, and 4, the window title approach is really irrelevant.
Instead, the client will either directly handle callbacks through a custom
scheme, or be able to recognize when a known callback URL has been loaded, and
hence can extract the fragment from the URL directly.
I'm not sure i
On Wed, Apr 14, 2010 at 7:44 AM, Luke Shepard wrote:
> Anyone have feedback on this?
I can see several problems with using the User-Agent flow for native
applications:
1. A verification code is much simpler to copy-and-paste (as opposed
to access token + refresh token + lifetime). At the extreme
With the simplified params, the callback url parameter is now just "callback".
Since most major API providers already use "callback" to signify JSON-P
callback, can we rename this to "callback_uri"? This will help avoid collisions
and confusion.
-Naitik
Sorry, I missed this thread. It dovetails with my objections raised in the
other thread ("Combining the native application and user-agent flows")
The question of whether OAuth should support custom URL protocols seems a bit
academic. In practice, major providers will probably allow them if there
+1, at least for changing the wording of the current flows to deal with Native
applications capable of various callback mechanisms.
That's the gist of this thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg01779.html
-cmort
On 4/14/10 7:44 AM, "Luke Shepard" wrote:
Anyone have fe
Anyone have feedback on this?
Sorry to push - we are in the midst of implementing this on a short timeline
and it's important that we have clarity about the different flows. As it
currently stands, I would not support the "Native Application Flow" and would
instead tell desktop developers to us
On 4/14/10 8:13 AM, David Recordon wrote:
Hey Eliot,
Have some text to propose?
Not yet. I'd suggest talking about the problem a bit more first.
Would, for instance, specifying a basic TLV encoding prove at all
useful? Here's one throw one more thing to throw into the mix. Were
this a S
Nope. Since HTTPS is a SHOULD I just wanted to ask. I'll add it.
EHL
On Apr 14, 2010, at 10:19, "Richard Barnes" wrote:
> This argument makes sense to me.
>
> EHL: Do you have an exception in mind?
>
>
>
> On Apr 14, 2010, at 10:15 AM, Jeroen van Bemmel wrote:
>
>> Since HTTPS is used, intermed
This argument makes sense to me.
EHL: Do you have an exception in mind?
On Apr 14, 2010, at 10:15 AM, Jeroen van Bemmel wrote:
Since HTTPS is used, intermediate proxies aren't a problem. However,
a browser might store the response containing the token in
"Temporary Internet files" or simi
Since HTTPS is used, intermediate proxies aren't a problem. However, a
browser might store the response containing the token in "Temporary
Internet files" or similar locations, and rich clients often use the
same HTTP libraries as the browser. Since the server cannot make any
assumptions about
21 matches
Mail list logo
