Re: [OAUTH-WG] native app support (was: Next draft)

On Wed, Jun 23, 2010 at 12:37 AM, Luke Shepard <lshepard@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 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 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 wishes to support this for their desktop apps, then it should provide an endpoint that handles the OAuth response and puts it in the <title>. I can say that Facebook has no interest in supporting this hack on the server side, but clients that want it can use their own html file that does 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 does 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 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.
>>>
>>> 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 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.
>>>>>>>
>>>>>>> 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 server. 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 consistent
>>>>> 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 new
>>>>>>>>> parameters, not sure if it belongs there. OAuth 1 at least defined
>>>>>>>>> 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
>
>