Subject: Re: [apps-discuss] FWD: Sending personal files between web applications

From: "Pablo Salomon" <[email-masked]>
Date: Sat, 3 Jul 2010 00:15:36 -0300

Hi Aaron,

Oauth by itself does not allows a website to send a file to any existing or
future website that complies with Oauth. Oauth focuses on securely granting
my authorization to another website's API but Website A needs to implement
the specific Website B's API for uploading a file which can be different
from Websites C,D,E, etc. The focus of my proposal is that there should be a
common way (or API) for such a basic task which is sending a file to another
website.

Another difference is that in Oauth typical scenarios the main interaction
of the user remains with a single Website to which I give access to other
Website's APIs. In order to give this access I may be redirected to the
other Websites but after the authentication the user continues to interact
with the original Website.

In the scenario I described in my original post, the user switches to a new
Website when he sends the file to it.

There are a couple of parallelism with the "Open with" feature on the popup
menu of a file on Windows Explorer:

1. When Microsoft designed this feature it didn't anticipate all the
applications that could be listed in the "Open with" submenu and the user
can even select any executable file as an open with target. In the scenario
I described, when the user selects the attachment in Gmail he may be
presented with a list of popular "open with" or "send to" target websites
but the user should have the option to select any website (that complies
with this new standard) by typing its URL.

2. When a user selects an application using the "open with" feature, that
application opens up and becomes the foreground application which is what
the user expects as he wants to keep working on the file with the selected
application. The same is true for the sample scenario I described when the
user sends his Gmail attachment to photoshop.com in order to edit it.

Best Regards,

                Pablo

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 03 Jul 2010 16:40:51 +0900

> common way (or API) for such a basic task which is sending a file to another

There may be no simple API to send (i.e. push) a file from one server to 
another. There is however an API to get (i.e. pull) a file from one 
server to another, indeed there are several, in particular HTTP and FTP.
Website A only needs to make the file available at a specific URI 
(/IRI). Website B then simply gets it from there. The whole thing can be 
expressed with a simple URI (/IRI) without any additional information.

There may still be some missing pieces, but as a general guideline, 
wherever you can pull, prefer it over push.

Regards,    Martin.

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sat, 03 Jul 2010 09:09:23 -0400

--On Saturday, July 03, 2010 16:40 +0900 "\"Martin J. Dürst\""
<[email-masked]> wrote:

>...
> There may be no simple API to send (i.e. push) a file from one
> server to another. There is however an API to get (i.e. pull)
> a file from one server to another, indeed there are several,
> in particular HTTP and FTP.
> Website A only needs to make the file available at a specific
> URI (/IRI). Website B then simply gets it from there. The
> whole thing can be expressed with a simple URI (/IRI) without
> any additional information.
> 
> There may still be some missing pieces, but as a general
> guideline, wherever you can pull, prefer it over push.

Of course FTP is symmetric: given sufficient authentication to
meet whatever requirements the server is configured to impose,
push ("send") and pull ("get") are equally feasible and
convenient.  Those who are interested in real or imagined
"missing pieces" should participate in the FTPEXT2 BOF in
Maastricht.

    john

---

From: Aaron Stone <[email-masked]>
Date: Tue, 6 Jul 2010 11:05:55 -0700

>> common way (or API) for such a basic task which is sending a file to

The semantics of what it means to push a file from Site A to Site B
are necessarily defined by the two sites. Any protocol that's meant to
carry the file needs to be plugged into some code that implements the
semantics of what the site will do with that file.

WebDAV provides the semantics of "I want File X to appear at URL Y".
Web APIs provide deeper semantics like, "I want File X to become my
account profile icon." I have no idea how you'd standardize that.

> another. There is however an API to get (i.e. pull) a file from one server
> to another, indeed there are several, in particular HTTP and FTP.
> Website A only needs to make the file available at a specific URI (/IRI).
> Website B then simply gets it from there. The whole thing can be expressed
> with a simple URI (/IRI) without any additional information.

WebDAV provides a push API. I haven't been following OAuth closely
enough to know if someone is looking at how WebDAV would work with
OAuth. Off the cuff, I believe that it's as simple as publishing an
appropriate Authenticate / WWW-Authenticate header on a Not Authorized
response. http://oauth.net/core/1.0/#auth_header and letting the HTTP
bits sort themselves out.

> There may still be some missing pieces, but as a general guideline, wherever
> you can pull, prefer it over push.
>
> Regards,    Martin.
>

(Responding to Pablo)

Oh! Ok, in this very limited use case, I definitely get where an "open
with" URL makes sense. The right layer for this might be a
microformat, or well-known-uri.

http://microformats.org/

http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

The underlying protocols would absolutely be HTTP and OAuth -- for example:

http://spreadsheets.example.com/openwith?uri=http://mysite.example.com/mydoc.csv

You'd log into spreadsheets.example.com, then it looks at the openwith
arguments and pulls the file into the spreadsheet editor. If the file
is not protected, it loads right away. If the file is protected, the
OAuth dance proceeds.

Cheers,
Aaron

---

From: Eric Burger <[email-masked]>
Date: Fri, 16 Jul 2010 17:20:56 -0400

This does sound a bit related to the problem solved by URLAUTH: the ability to send a secure, time-limited reference to a remote object.