On Wed, Jun 23, 2010 at 12:37 AM, Luke Shepard lshep...@facebook.com wrote:
One more question - is the title technique used in production? I think
you'd mentioned that it was ... if so, can you point me to the docs where
it's currently used?
Google has several Windows desktop apps that use
Two points:
1/ I agree that it can be onerous for clients to host web pages. It's not a
matter of expense but of complexity.
BUT
2/ As we discussed previously in our in-person meeting, this should be handled
by a different endpoint, and not be the responsibility for the provider. If
Google
One more question - is the title technique used in production? I think you'd
mentioned that it was ... if so, can you point me to the docs where it's
currently used?
On Jun 22, 2010, at 11:00 PM, Luke Shepard wrote:
Two points:
1/ I agree that it can be onerous for clients to host web
On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu mscurte...@google.com wrote:
In order to properly support native applications I suggest the
following changes:
[...]
2. optional redirect_uri (default result page)
Some native apps do not have a redirect_uri, as a result two things are
On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
In OAuth 1.0a, we needed it for the patch. I don't think this needs to be in
the spec because it doesn't help interop. If the server supports such a
scheme, it should document it. It also falls under previously
On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Tuesday, June 22, 2010 3:35 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: native app support (was: Next
In that case, I suggest an extension. But I just don't think this needs it. Why
involve the server at all in this? The client should just host a web page
somewhere with the format it wants or the language for the user.
With $10 hosting, every client can host a web page somewhere.
EHL
1) +1
2) +1 - Oauth 1.0a had oob, why not for that purpose
3) I would rather add the user_code as optional URL parameter to the
device flow.
4) What about an additional best practices document?
regards,
Torsten.
Am 08.06.2010 19:46, schrieb Marius Scurtescu:
In order to properly support
On Wed, Jun 9, 2010 at 12:42 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
3) I would rather add the user_code as optional URL parameter to the device
flow.
Are you suggesting the same thing? That the endpoint at
verification_uri should accept an optional user_code query parameter?
Oops, I misread this point.
So +1 for 3), too.
regards,
Torsten.
Am 09.06.2010 18:45, schrieb Marius Scurtescu:
On Wed, Jun 9, 2010 at 12:42 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
3) I would rather add the user_code as optional URL parameter to the device
flow.
In order to properly support native applications I suggest the
following changes:
1. client_name
In all flows when client_id is sent also allow for an optional
client_name. This optional parameter is meant as a display name for
the client, and it is useful in all unregistered cases, not only for
Hey Marius,
1) Feels like this should be in an unregistered client spec.
3) Why would a device which intends to open a web browser use the
device flow to start? Wouldn't it just use the user agent flow?
4) Yes, but should be a separate document.
Thanks,
--David
On Tue, Jun 8, 2010 at 10:46
On Tue, Jun 8, 2010 at 11:45 AM, David Recordon record...@gmail.com wrote:
Hey Marius,
1) Feels like this should be in an unregistered client spec.
Not sure. Does the core spec always assume registered?
3) Why would a device which intends to open a web browser use the
device flow to start?
13 matches
Mail list logo
