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
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
On Wed, Apr 14, 2010 at 2:19 PM, Chuck Mortimore
cmortim...@salesforce.com 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
On Wed, Apr 14, 2010 at 4:23 PM, Luke Shepard lshep...@facebook.com 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
On Wed, Apr 14, 2010 at 4:24 PM, Luke Shepard lshep...@facebook.com 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,
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
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
