Responses below.
On Jul 6, 2010, at 2:23 PM, Brian Eaton wrote:
> On Tue, 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 pages. It's not a
>> matter of expense but of complexity.
>>
>> BUT
>>
>> 2/ As we discussed
On Tue, 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 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 e
On Wed, Jun 23, 2010 at 12:37 AM, Luke Shepard wrote:
> One more question - is the 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 this technique. There
is
One more question - is the 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 pages.
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 wi
On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav wrote:
> 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
Write the spec then. It should be pretty short.
EHL
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Tuesday, June 22, 2010 4:31 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: native app support (was: Next draft)
>
> On Tue,
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
> -Or
On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav 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 draft)
> -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 draft)
>
> On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav
> wrote:
On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav 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 established
> redir
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 established redirection
URI" which happens to point at the server.
EHL
> -Orig
On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu 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
> needed:
>
> 2.1 Eit
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
wrote:
3) I would rather add the user_code as optional URL parameter to the device
flow.
Are you suggesting the sam
On Wed, Jun 9, 2010 at 12:42 AM, Torsten Lodderstedt
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?
Marius
_
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 nat
On Tue, Jun 8, 2010 at 11:45 AM, David Recordon 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? Wouldn't it ju
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 AM
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
19 matches
Mail list logo
