DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
 h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record;
 b=Kbju8GMW4Rt0++qkbLine/9HjoNQUWPxzSxFhqIwKDPqVUpbKk/4XNReyinG0oyA8
 DNU0+ZrZ7E+EdjdP6dBUw==
MIME-Version: 1.0
In-Reply-To: <29F569B4-C107-4204-9790-44FCE1364CB5@facebook.com>
References: <AANLkTikkG3T_DYKhjMbyYayi7SzZel3RJXFSguxq7SSZ@mail.gmail.com>
 <AANLkTilycD2urJZqbP8HaRcqUQ6bM30WAzy4c4VOmLql@mail.gmail.com>
 <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
 <AANLkTinj6wsniocBB45Ul0P5WNsAjktz-p0antXpkyUX@mail.gmail.com>
 <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
 <AANLkTilM3NSD0BLQk5rz5UWxsudTHSBmMbDcwmcztcVb@mail.gmail.com>
 <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C8@P3PW5EX1MB01.EX1.SECURESERVER.NET>
 <AANLkTimykXBFhoAW4A3CY_GEc-v3I21SvKGKP08MjsX3@mail.gmail.com>
 <39DE4E99-6DB3-4FBA-B78C-B2AB2B162221@facebook.com>
 <29F569B4-C107-4204-9790-44FCE1364CB5@facebook.com>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Thu, 24 Jun 2010 13:19:58 -0700
Message-ID: <AANLkTikhXW_XKQyuAYfog2NxgHgP7DVE7BQU2YZvlPfB@mail.gmail.com>
To: Luke Shepard <lshepard@facebook.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] native app support (was: Next draft)
Precedence: list

On Wed, Jun 23, 2010 at 12:37 AM, Luke Shepard <lshepard@facebook.com> wrot=
e:
> 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 i=
t's currently used?

Google has several Windows desktop apps that use this technique. There
is an Outlook integration app called Glook and probably some versions
of Picasa and SketchUp.

Marius

>
> 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. It's no=
t a matter of expense but of complexity.
>>
>> BUT
>>
>> 2/ As we discussed previously in our in-person meeting, this should be h=
andled by a different endpoint, and not be the responsibility for the provi=
der. If Google wishes to support this for their desktop apps, then it shoul=
d provide an endpoint that handles the OAuth response and puts it in the <t=
itle>. I can say that Facebook has no interest in supporting this hack on t=
he server side, but clients that want it can use their own html file that d=
oes it for them.
>>
>> For example, for Javascript web apps it is a pain to host a cross-domain=
 receiver file. So we host one on behalf of developers (called xd_proxy.php=
). But it is not part of our server-side logic.
>>
>> If you want to write a spec for that, then great, but the <title> hack d=
oes not belong in the main spec.
>>
>> On Jun 22, 2010, at 4:30 PM, Marius Scurtescu wrote:
>>
>>> On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav <eran@hueniverse.com=
> wrote:
>>>> In that case, I suggest an extension. But I just don't think this need=
s 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.
>>>
>>> Hard to tell, you could be right. Keep in mind that this page has to
>>> be reliable and secure, $10 will probably not give you that. An authz
>>> server can easily provide all this at almost no cost.
>>>
>>> Marius
>>>
>>>>
>>>> EHL
>>>>
>>>>> -----Original Message-----
>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com]
>>>>> Sent: Tuesday, June 22, 2010 4:17 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 4:07 PM, Eran Hammer-Lahav
>>>>> <eran@hueniverse.com> wrote:
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Marius Scurtescu [mailto:mscurtescu@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
>>>>>>> <eran@hueniverse.com> wrote:
>>>>>>>> In OAuth 1.0a, we needed it for the patch. I don't think this need=
s
>>>>>>>> to be in
>>>>>>> the spec because it doesn't help interop. If the server supports su=
ch
>>>>>>> a scheme, it should document it. It also falls under "previously
>>>>>>> established redirection URI" which happens to point at the server.
>>>>>>>
>>>>>>> OK, that makes sense.
>>>>>>>
>>>>>>> What about:
>>>>>>>> Also, this page should put the verification code and the client
>>>>>>>> state (code and state) in the page title in a standard way such
>>>>>>>> that the native app can extract them from the window title. WRAP
>>>>>>>> defined how the title should be formed.
>>>>>>>
>>>>>>> Extension?
>>>>>>
>>>>>> I don't think this needs a spec. Just something provided by the serv=
er. Does
>>>>> the client need any special handling? It can always just use a static=
 web page
>>>>> to do this, no?
>>>>>
>>>>> A spec would help so all servers provide code and state in a consiste=
nt
>>>>> format. Client libraries can then provide methods to parse this. Also=
, client
>>>>> apps connecting to multiple servers can expect some consistency.
>>>>>
>>>>> Marius
>>>>>
>>>>>>
>>>>>> EHL
>>>>>>
>>>>>>>
>>>>>>> Marius
>>>>>>>
>>>>>>>>
>>>>>>>> EHL
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com]
>>>>>>>>> Sent: Tuesday, June 22, 2010 1:02 PM
>>>>>>>>> To: Eran Hammer-Lahav
>>>>>>>>> Cc: OAuth WG (oauth@ietf.org)
>>>>>>>>> Subject: Re: native app support (was: Next draft)
>>>>>>>>>
>>>>>>>>> On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu
>>>>>>>>> <mscurtescu@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
>>>>>>>>> needed:
>>>>>>>>>>
>>>>>>>>>> 2.1 Either make redirect_uri optional or define a standard value
>>>>>>>>>> that signals that the client does not have such a page.
>>>>>>>>>>
>>>>>>>>>> 2.2 The authz server must supply a default result page, if there
>>>>>>>>>> is no redirect_uri. Also, this page should put the verification
>>>>>>>>>> code and the client state (code and state) in the page title in
>>>>>>>>>> a standard way such that the native app can extract them from
>>>>>>>>>> the window title. WRAP defined how the title should be formed.
>>>>>>>>>
>>>>>>>>> Should this also go to an extension? It is not introducing any ne=
w
>>>>>>>>> parameters, not sure if it belongs there. OAuth 1 at least define=
d
>>>>>>>>> the
>>>>>>> "oob" special value.
>>>>>>>>>
>>>>>>>>> Marius
>>>>>>>>
>>>>>>
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>