Announcing OpenFile

A small group of us at work came up with an idea for a new web API that we are developing and would like as much community involvement as possible. We're calling it "OpenFile" in the spirit of OpenID, OAuth, OpenSocial, etc. From our in-progress spec:

Users store more and more of their data in disparate services: photos on Flickr, SmugMug, Snapfish; files in Amazon S3, Box.net, Mozy; documents on Google Documents, Zoho, etc. At the same time there are more and more web web-enabled applications that would like access to these sets of data to offer additional value: online image editing, audio and video transcoding, remote access, etc. Often a client wants to perform relatively simple operations: open a file, save a file, but every service provider implements this in a different manner. For these basic operations there needs to be an easier way for clients to access the user's data from any kind of provider in a uniform way, and at the same time protecting the privacy and security of the data itself.

The OpenFile API is a vendor-neutral protocol for desktop and web clients to be granted limited access to users' data that is managed by an external service provider. Its specific goals are to:

• Provide clients the web equivalent of "Open File" and "Save As" dialogs that are managed by a user's service provider rather than the client, avoiding the exposure of private data to a requesting client, such as the user's folder structure. This also encourages the user to authorize the minimum amount of data to the client, rather than granting carte blanche access to all possible operations.


• Allow authorized clients to then "Open" (read) and "Save" (write) authorized files.


• Interoperate with open standards such as OAuth to avoid disclosing a user's credentials for a service provider to a client.

Intended audience

This specification is intended for:

• Data storage/backup providers who want to enable their users to access their data via numerous third-party clients in a standard and secure way.


• Web services that want to simplify and extend their current methods of importing and exporting file data.

Community participation

Please join the mailing list if you are interested in contributing, editing, or implementing this specification. We hope to emulate the process used by the OAuth mailing list in developing this spec: mailing list membership by application to avoid extraneous posts, quick discussions and voting on issues, rapid progress towards implementation and adoption.

Examples

Photo editing web site

1. Alice discovers a new web-based picture editing service picedit.com and wants to try it out on some of her pictures which are stored in the OpenFile-enabled myphotos.com site at the URL alice.myphotos.com.


2. On picedit.com's Import page there is a textbox where Alice can enter her OpenFile provider URL (alice.myphotos.com) so that picedit.com can learn how to pull photos from it. Alice is then redirected to alice.myphotos.com, which asks her to login if she's not logged in already, and then to select what photos she wants to grant picedit.com access to.


3. Alice chooses just one photo of her cat and is redirected back to picedit.com, which then pulls the picture of her cat from alice.myphotos.com. Alice then starts editing the photo.


4. When she's done she presses the "Save" button, causing picedit.com to push the updated image back to alice.myphotos.com where it will replace the previous version.

Online music store

1. Joe just bought the final Daft Punk album missing from his collection on drm-free.com. He can download it directly into his computer, but he also wants it available from his online-streaming service stream-it.net, and he wants it backed up to his offsite-backup service back-it-up.com.


2. On drm-free.com Joe enters the OpenFile endpoint URLs for both his services: stream-it.net and back-it-up.com.


3. First he's redirected to stream-it.net's "Save As" dialog, where he is asked if he wishes to allow drm-free.com to write some files. Joe navigates his folder structure and sets up a new folder for the album data, then is redirected back to drm-free.com.


4. Next he's redirected to back-it-up.com where he goes through the same authorization process for drm-free.com.


5. Finally drm-free.com begins transferring the music files to both services, keeping Joe informed about the progress of the transfers.