New spec uploaded

[Adam Rosien]

http://openfile.googlegroups.com/web/openfile-1.0-20080306.html

Now using xml2rfc for formatting. Consolidated multiple endpoints
into single endpoint. Use Atom feed rather than special Authorized
File List format.

[Ben Strong]

Looks good. I think we're headed in the right direction. A few comments:

1) It would be nice to have a more descriptive abstract. Something along
the lines of:

>>

OpenFile defines a standard protocol and user-interface guidelines for
websites and applications to request and receive access to clearly
defined sets of files from web storage providers. It leverages existing
standards for discovery (XRD), authentication (OAuth), and
publishing/editing (AtomPub).

OpenFile was created in response to three trends:

1. A large (and growing) number of online storage providers have
released incompatible file access APIs, creating an implementation
burden on application developers for each additional storage provider
they wish to support.

2. A large (and growing) number of websites and applications
(e.g., online word processors, photo editors, presentation viewers,
etc.) have released incompatible file open APIs, creating an
implementation burden on storage providers for each additional
application they wish to support.

3. Most existing storage provider APIs give applications access
to _all_ of the files in a user's account, even when the user's goal is
to open one particular file or a small set of files. This creates
obvious privacy and security risks.

When applications and storage providers support OpenFile, any
application can access files from any provider without incremental
integration work (or even knowing about the provider in advance). In
addition, any storage provider can open files in any application without
incremental integration work (or even knowing about the application in
advance).

Perhaps most importantly, OpenFile leverages the familiar user-interface
paradigm of the "Open File" dialog to ensure that the easiest and most
natural path for all parties involved (users, applications, and storage
providers) is to grant the smallest possible set of permissions on the
smallest possible set of files that the application needs to accomplish
its task.

<<

2) We should add a use case around launching an application from a
storage provider (e.g., opening a document in an online word processor
and saving it back). It would also be nice to have a desktop app use
case (e.g., a generic iPhoto plugin that can import/export from any
OpenFile provider).

3) I'm not sure why the discovery document is a MAY. It seems like a
required step in the workflow. In general, we should try to keep the
MAYs to an absolute minimum in order to maximize interoperability.

4) It's not clear where in the authorization process the file selection
occurs. I think we need to standardize that. In general, even though it
may be unusual for a protocol spec, I think that we should try to
specify the user experience as much as possible (possibly as a separate
document).

We still need to flesh out the discovery document, the "launch app from
storage provider" workflow, and the atom extensions for permissions and
file system attributes, but otherwise, I think we're looking pretty
good.

Ben

[Adam Rosien]

I think your #1 and #2 could be consolidated, and then used to imply
the need for adoption of Atom / AtomPub. Then we can highlight the
lack of privacy and security around granting full access to clients,
and a need for a more restricted workflow that emphasizes explicit
user choice. I'll come up with a draft edit to send to the list.

> 2) We should add a use case around launching an application from a
> storage provider (e.g., opening a document in an online word processor
> and saving it back). It would also be nice to have a desktop app use
> case (e.g., a generic iPhoto plugin that can import/export from any
> OpenFile provider).

Would you agree that a Client could have its own discovery document
with a listed endpoint for this "push" scenario?

> 3) I'm not sure why the discovery document is a MAY. It seems like a
> required step in the workflow. In general, we should try to keep the
> MAYs to an absolute minimum in order to maximize interoperability.

If a Client knows the OAuth and Authorization Endpoints then discovery
is not strictly necessary, although when I say that I feel like I'm
being tautological. I could go either way.

> 4) It's not clear where in the authorization process the file selection
> occurs. I think we need to standardize that. In general, even though it
> may be unusual for a protocol spec, I think that we should try to
> specify the user experience as much as possible (possibly as a separate
> document).

The user selection is mentioned in section 4.3 User Authorizes
Resources for Client. Admittedly the spec doesn't say much other than
"When the User is redirected to the Service Provider, the Service
Provider MUST display an authorization dialog appropriate for the
passed-in parameters." I think an additional section "User Interface
Considerations" would be useful, with a link to it from section 4.3.

> We still need to flesh out the discovery document, the "launch app from
> storage provider" workflow, and the atom extensions for permissions and
> file system attributes, but otherwise, I think we're looking pretty
> good.

I plan on adding a sample discovery document in the Example section.
I think the SP to Client push would have its own workflow section.
I'll make a note of any appropriate Atom extension attributes.

Thanks,

.. Adam

[Ben Strong]

> I think your #1 and #2 could be consolidated, and then used to imply
> the need for adoption of Atom / AtomPub. Then we can highlight the
> lack of privacy and security around granting full access to clients,
> and a need for a more restricted workflow that emphasizes explicit
> user choice. I'll come up with a draft edit to send to the list.

I'd like to keep them separate because #2 is just as interesting as #1
(if not more so, since there are more apps than providers) and the point
tends to get lost when you fold them together.

> Would you agree that a Client could have its own discovery document
> with a listed endpoint for this "push" scenario?

Yes, it definitely should. It can contain information like application
name (so you can add it to an "Open With" menu), description, supported
mime types and languages (btw, I wonder if we should add language as a
dialog param), or maybe even different endpoints for different mime
types. It should also be possible for a site to be both an app and a
provider. On another note, we should probably standardize on terms for
the two parties (File Consumer and File Provider?)

> If a Client knows the OAuth and Authorization Endpoints then discovery
> is not strictly necessary, although when I say that I feel like I'm
> being tautological. I could go either way.

I think the power of this whole thing is _not_ having to know the
endpoints. I would lean strongly towards requiring discovery.

Ben

[Anton Bar (G.ho.st)]

I have one general comment. I will digest the rest later, but this one
is important for us...

From our experience in G.ho.st, I believe that the problem of
different online storage systems vs. online application vendors cannot
be solved solely with the Open / Save As File dialogs. The GUI can be
useful in some cases, but not always and certainly not with the big
application vendors.

Example use case:
1. G.ho.st has Virtual File System and we can develop the Open / Save
As GUI w/o any problem.
2. Lets assume that G.ho.st does not have Zoho and we're planning to
integrate it using OpenFile.
3. According to the current version of OpenFile, in order to access
G.ho.st storage, Zoho will need at some point to redirect to our Open
File GUI.
4. ... and so on...

The solution of redirecting to somebody else's interface and hoping
they'll redirect back, is not practical. It may work with simple
online widgets and small anonymous application providers. Big names
will never agree to that for a number of reasons, technical and
commercial. They will want their interface visible at all times when
you work with their apps.

What is really required is an open standard for an online Virtual File
System API in addition to the granual authorization that we already
have in OpenFile. By VFS API I mean everything you'd expect to find in
a file system - files, directories, create/open/modify/update/delete
files/directories, support concurrent access, partial reads/updates,
assign and enforce user's permissions and so on.

If you are interested, I will write a proposal of VFS API for
inclusion in the OpenFile spec.

BTW, maybe you should see a real world example of exactly this use
case and try our service at http://G.ho.st. It's free and you have 3GB
for emails and 3GB for data, integrated Zimbra, Zoho and more.

[Adam Rosien]

> From our experience in G.ho.st, I believe that the problem of
> different online storage systems vs. online application vendors cannot
> be solved solely with the Open / Save As File dialogs. The GUI can be
> useful in some cases, but not always and certainly not with the big
> application vendors.

I agree there is the general interoperability problem, which I believe
is moving towards AtomPub (see below), but OpenFile is also about
granting limited authorization to clients to protect user's privacy
and security. These two goals of OpenFile are orthogonal, but
powerful together.

> The solution of redirecting to somebody else's interface and hoping
> they'll redirect back, is not practical. It may work with simple
> online widgets and small anonymous application providers. Big names
> will never agree to that for a number of reasons, technical and
> commercial. They will want their interface visible at all times when
> you work with their apps.

There are a number of counter-examples to your statement, for example,
all OpenID providers have their own interface, and also any
browser-based authentication schemes, such as OAuth or Flickr Auth,
have their own interface. Larger companies may fight against a more
open system, but it appears to me that they are in a losing battle
given the popular interest in decentralization technologies like
OpenID and OAuth.

> What is really required is an open standard for an online Virtual File
> System API in addition to the granual authorization that we already
> have in OpenFile. By VFS API I mean everything you'd expect to find in
> a file system - files, directories, create/open/modify/update/delete
> files/directories, support concurrent access, partial reads/updates,
> assign and enforce user's permissions and so on.
>
> If you are interested, I will write a proposal of VFS API for
> inclusion in the OpenFile spec.

Atom+AtomPub is rapidly gaining popularity and adoption. What
similarities or differences do you see between your VFS and adapting
and extending Atom?

.. Adam

[Ben Strong]

Given the current spec, you are absolutely correct. Let me elaborate on
our thoughts on how the push scenario would work to see if it addresses
your concerns:

To open a file or set of files in an app, you would simply post the url
of an atom feed containing the files to the app endpoint. It would then
go pull the files without invoking the dialog. The feed would be
identical to one that would be returned in the callback after invoking
the dialog, but you can bypass the entire authorization and selection
step because the user's open action does that implicitly.

As for the VFS, our thought is to define all the file system operations
on top of AtomPub. So, the feed that you get either directly as a result
of a push from the provider or at the end of the selection process would
be the root of a virtual file system scoped to exactly what the user
authorized. If the user only selects one file, then it is a file system
containing exactly one file, but if the user selects a collection (e.g.,
a directory), then you can iterate over it recursively, and basically
have a full hierarchical file system.

If you'd like to have a go at defining some VFS AtomPub extensions, then
please do. We haven't really thought that part through yet, but since
most of the file system operations map directly to AtomPub operations,
this should mainly be a matter of standardizing representations of
filesystem metadata (move and copy may be tricky, though). We originally
intended to return WebDAV file systems, since WebDAV is a workable and
fully fleshed-out file system api over http, but given that it isn't
very popular in the web api community and Atom has a lot of momentum
behind it, we decided it would be a better fit (see
http://nih.blogspot.com/2008/02/nearly-two-years-ago-i-made-prediction.h
tml for the perspective of one of the core WebDav developers). Using
Atom has the added benefit that you could use the same mechanism to
select things that aren't files and directories (e.g., GData or Astoria
feeds).

Let me know if that makes sense (and I'll take a look at Ghost in the
meantime).

Ben

> -----Original Message-----
> From: open...@googlegroups.com [mailto:open...@googlegroups.com] On

[Anton Bar]

Now I have even more info to digest :-) It'll take a day or two, but I'm on it.

 

Another point against WebDAV - it uses the Digest authentication method. Now, when a web server returns the Digest HTTP header, the browser should show the Login / Password dialog, isn't it? If yes, then AJAX/DHTML, OpenLaszlo and Flash applications will not be able to use it. Or maybe I'm missing something?
 

[Ben Strong]

Good point. I hadn't even considered that. I assumed that the authentication mechanism was orthogonal to the WebDAV protocol. Looking at the spec now, it says that you must not use basic, and you must support digest. It doesn't say you have to use digest, though, so it seems like there's some room for interpretation if you wanted to use OAuth. Anyway, it's moot if we use Atom.

________________________________________

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of Anton Bar

Sent: Friday, March 07, 2008 4:11 PM
To: open...@googlegroups.com

Subject: Re: New spec uploaded

Now I have even more info to digest :-) It'll take a day or two, but I'm on it.

 
Another point against WebDAV - it uses the Digest authentication method. Now, when a web server returns the Digest HTTP header, the browser should show the Login / Password dialog, isn't it? If yes, then AJAX/DHTML, OpenLaszlo and Flash applications will not be able to use it. Or maybe I'm missing something?

 ----~----~------~----~------~--~---

[Adam Rosien]

> 1) It would be nice to have a more descriptive abstract. Something along
> the lines of:

...

> Perhaps most importantly, OpenFile leverages the familiar user-interface
> paradigm of the "Open File" dialog to ensure that the easiest and most
> natural path for all parties involved (users, applications, and storage
> providers) is to grant the smallest possible set of permissions on the
> smallest possible set of files that the application needs to accomplish
> its task.

I'm mostly copying your good abstract; it's much clearer than before.
I am rewording the specific use of "'Open File' dialog" to the more
general "leverages the familiar user-interface paradigm of dialogs
(Open dialog, Save dialog, etc.)".

(aside) The Apple UI Guidelines are a good read:
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_18_section_7.html#//apple_ref/doc/uid/20000961-BACFBACB

.. Adam

[Anton Bar (G.ho.st)]

Please see my notes below.

> There are a number of counter-examples to your statement, for example,
> all OpenID providers have their own interface, and also any
> browser-based authentication schemes, such as OAuth or Flickr Auth,
> have their own interface. Larger companies may fight against a more
> open system, but it appears to me that they are in a losing battle
> given the popular interest in decentralization technologies like
> OpenID and OAuth.

Flickr apps is a good example of web widgets or small web apps, which
work great with this GUI model. Larger (and more valuable)
applications such as editors, email, calendars etc., especially those
developed by larger vendors, will have a problem. Even if they are
losing the battle, I believe we should not fight anybody. One of the
reasons OAuth is doing so well is because they specifically adapted it
for the existing application vendors (the spec emphasizes this right
in the intro!). Also note that the most popular part of OAuth is the
Consumer Request spec (aka the 2-legged scenario) which doesn't
require any GUI (and Google OpenSocial supports it).

OpenID is not a good example because its GUI is used only for
registration, afterwards it works silently. OpenFile will probably be
used every time you access a file system.

For example: once Client gets the permissions XML, it will send it in
a secure way along with each read/write file request. The Service
provider will know what data it needs to return or store and will be
able to verify the permissions.

I still have an impression that you originally planned OpenFile to
handle only the authorization part, and I need the full fledged file
system API, including the authorization.

> Atom+AtomPub is rapidly gaining popularity and adoption. What
> similarities or differences do you see between your VFS and adapting
> and extending Atom?

If I'm not missing your point, I think that AtomPub will be great for
functionality such as enumeration of files, getting properties,
quotas, user's permissions and so on.

I also think that we should also provide direct access to files.
Example 1 - you may share images stored on G.ho.st. When you do it,
each image gets a direct link to it. When you open this link in the
browser, you get your file contents directly, w/o any XML wrapper.
Example 2 - HTML doc with embedded images, scripts and CSS files. You
can parse the HTML out of Atom, and load it in an IFRAME, but then,
the browser will read and render the rest of automatically, which will
fail if the files will be wrapped in something like Atom.

I hope I'm not completely missing your point though....

What do you think?

[Anton Bar (G.ho.st)]

Sounds good to me. I'll write a proposal of VFS over AtomPub spec
later today. It will include also direct file access, please see the
examples in my earlier response to Adam.

> behind it, we decided it would be a better fit (seehttp://nih.blogspot.com/2008/02/nearly-two-years-ago-i-made-prediction.h

> > case and try our service athttp://G.ho.st. It's free and you have 3GB

[Anton Bar (G.ho.st)]

Can you elaborate on why you prefer Atom over WebDAV?

> We originally intended to return WebDAV file systems, since WebDAV is a workable and
> fully fleshed-out file system api over http, but given that it isn't
> very popular in the web api community and Atom has a lot of momentum

> behind it, we decided it would be a better fit (seehttp://nih.blogspot.com/2008/02/nearly-two-years-ago-i-made-prediction.h

[Adam Rosien]

> Flickr apps is a good example of web widgets or small web apps, which
> work great with this GUI model. Larger (and more valuable)
> applications such as editors, email, calendars etc., especially those
> developed by larger vendors, will have a problem. Even if they are
> losing the battle, I believe we should not fight anybody. One of the
> reasons OAuth is doing so well is because they specifically adapted it
> for the existing application vendors (the spec emphasizes this right
> in the intro!). Also note that the most popular part of OAuth is the
> Consumer Request spec (aka the 2-legged scenario) which doesn't
> require any GUI (and Google OpenSocial supports it).

I agree that we should be as adoptable as possible. I worry however
about not requiring enough security via authentication since we are
dealing with people's most private data.

My interpretation of the 2-legged scenario for OpenFile, where an app
is authenticated only by its api key and secret, is that there is a
one-to-one mapping between api key/secret pairs and users, that is,
when a user creates an api key/secret, that key/secret is tied to
their account. Then the user has "pre-authenticated" the client. An
obvious security flaw is that someone may share their key/secret, but
the user does have the ability to revoke the pair via the provider.
Does this scenario agree with what you have in mind?

Using either the 2- or 3-legged scenario does not remove the
requirement for the User to select resources to authorize for the
Client. It is important that the User use the Service Provider's
interface for this versus the Client's interface.

> OpenID is not a good example because its GUI is used only for
> registration, afterwards it works silently. OpenFile will probably be
> used every time you access a file system.

Agreed since no token for OpenID is later used for subsequent requests.

> For example: once Client gets the permissions XML, it will send it in
> a secure way along with each read/write file request. The Service
> provider will know what data it needs to return or store and will be
> able to verify the permissions.
>
> I still have an impression that you originally planned OpenFile to
> handle only the authorization part, and I need the full fledged file
> system API, including the authorization.

For an authenticated Client, the OAuth Access Token is sent with each
request. The Service Provider maintains a mapping between the Access
Token and the granted resources, so when the Client is given an
Authorized Feed, each referenced URL is *also* protected by the same
Access Token. (This last point is *not* in the spec and I need to add
it.)

Ben and I see the system API defined by the contents of the Authorized
Feed (currently proposed to be in the form of an Atom Feed) rather
than existing outside the scope of an Authorized Feed. The Authorized
Feed, and every URL referenced by the feed, are protected by OAuth.
In this way only the resources granted by the User are available to
the authenticated Client.

> If I'm not missing your point, I think that AtomPub will be great for
> functionality such as enumeration of files, getting properties,
> quotas, user's permissions and so on.
>
> I also think that we should also provide direct access to files.
> Example 1 - you may share images stored on G.ho.st. When you do it,
> each image gets a direct link to it. When you open this link in the
> browser, you get your file contents directly, w/o any XML wrapper.
> Example 2 - HTML doc with embedded images, scripts and CSS files. You
> can parse the HTML out of Atom, and load it in an IFRAME, but then,
> the browser will read and render the rest of automatically, which will
> fail if the files will be wrapped in something like Atom.

I may be confused, but are you saying that Atom may not work because
it can't reference the file itself? Atom <entry> elements must
contain a <content> element that may reference any URL
(http://atompub.org/rfc4287.html#element.content). This URL would be
the contents of the file. Any content URL would have to be protected
with OAuth.

I may have misunderstood your point though!

.. Adam

[Anton Bar (G.ho.st)]

> My interpretation of the 2-legged scenario for OpenFile, where an app
> is authenticated only by its api key and secret, is that there is a
> one-to-one mapping between api key/secret pairs and users, that is,
> when a user creates an api key/secret, that key/secret is tied to
> their account.  Then the user has "pre-authenticated" the client.  An
> obvious security flaw is that someone may share their key/secret, but
> the user does have the ability to revoke the pair via the provider.
> Does this scenario agree with what you have in mind?

Yes, it would be nice to be able to unauthenticate a Client. Maybe we
should propose it for OAuth Core as RECOMMENDED feature.

> Using either the 2- or 3-legged scenario does not remove the
> requirement for the User to select resources to authorize for the
> Client.  It is important that the User use the Service Provider's
> interface for this versus the Client's interface.

I understand this point, but I have a proglem with obligating the
Service Providers doing this.
Please have a look at www.OpenSAM.org, they do something very similar,
but differently.

> For an authenticated Client, the OAuth Access Token is sent with each
> request.  The Service Provider maintains a mapping between the Access
> Token and the granted resources, so when the Client is given an
> Authorized Feed, each referenced URL is *also* protected by the same
> Access Token.  (This last point is *not* in the spec and I need to add
> it.)

Yes, sounds right.

> Ben and I see the system API defined by the contents of the Authorized
> Feed (currently proposed to be in the form of an Atom Feed) rather
> than existing outside the scope of an Authorized Feed.  The Authorized
> Feed, and every URL referenced by the feed, are protected by OAuth.
> In this way only the resources granted by the User are available to
> the authenticated Client.

Maybe I'm missing something here. Lets take an example. What if I
share a PDF file and now I'd like to print it using some printing
Client. The client knows to read PDF files via HTTP. According to your
current proposal, will the client need to read it wrapped in Atom,
unwrap and only then load or you had a different idea?

> I may be confused, but are you saying that Atom may not work because
> it can't reference the file itself?  Atom <entry> elements must
> contain a <content> element that may reference any URL
> (http://atompub.org/rfc4287.html#element.content).  This URL would be
> the contents of the file.  Any content URL would have to be protected
> with OAuth.

I didn't explain this clearly. Lets try again:
- For the sake of discussion, lets assume that G.ho.st VFS returns
files via Atom feed.
- I have FOO.HTML containing a reference to FOO.GIF
- I share FOO.HTML through G.ho.st VFS, and now have a direct link to
download FOO.HTML
- PROBLEM 1: If user opens this link in a browser, she sees the Atom
wrapping FOO.HTML instead of the original file
- User opens some Client that reads the feed, unwraps FOO.HTML and
displays it in an IFRAME
- PROBLEM 2: The browser renders FOO.HTML, detects the referenced
image and tries to load it. This will fail because the image will be
wrapped in an Atom feed, and browsers do not have built-in support for
loading images through an Atom feed.

Let me know if it's still unclear. My main point is that any file
system should provide direct raw access to files, wrapping it or
adding headers or footers.

Regards,
Anton.

[Adam Rosien]

> I understand this point, but I have a proglem with obligating the
> Service Providers doing this.
> Please have a look at www.OpenSAM.org, they do something very similar,
> but differently.

I have to check that link out. Sounds like a good fit with our goals.

(a longer reply forthcoming)

.. Adam

[Adam Rosien]

Anton -

G.ho.st seems to be an OpenSAM member. How much activity does the
group have? There doesn't seem to be a public mailing list. Some
quick google searches don't show much activity in the last six months.
Has OpenSAM stalled, or is just quiet with activity going on in the
background?

.. Adam

[Adam Rosien]

> > My interpretation of the 2-legged scenario for OpenFile, where an app
> > is authenticated only by its api key and secret, is that there is a
> > one-to-one mapping between api key/secret pairs and users, that is,
> > when a user creates an api key/secret, that key/secret is tied to
> > their account. Then the user has "pre-authenticated" the client. An
> > obvious security flaw is that someone may share their key/secret, but
> > the user does have the ability to revoke the pair via the provider.
> > Does this scenario agree with what you have in mind?
>
> Yes, it would be nice to be able to unauthenticate a Client. Maybe we
> should propose it for OAuth Core as RECOMMENDED feature.

Revocation of keys is a common security technique so I would guess the
OAuth group assumes that SP's can revoke Client key/secrets, although
it is not explicit.

> > Using either the 2- or 3-legged scenario does not remove the
> > requirement for the User to select resources to authorize for the
> > Client. It is important that the User use the Service Provider's
> > interface for this versus the Client's interface.
>
> I understand this point, but I have a proglem with obligating the
> Service Providers doing this.
> Please have a look at www.OpenSAM.org, they do something very similar,
> but differently.

We at Sharpcast feel the explicit User authorization is a requirement
of the spec we would like to create. But that doesn't mean that we
would not support creating a common VFS interface via Atom.

> Maybe I'm missing something here. Lets take an example. What if I
> share a PDF file and now I'd like to print it using some printing
> Client. The client knows to read PDF files via HTTP. According to your
> current proposal, will the client need to read it wrapped in Atom,
> unwrap and only then load or you had a different idea?

If the client used OpenFile, then the user would authorize the client
to access the PDF, the client would get the Atom feed, then the client
would download the PDF via the link in the feed.

> I didn't explain this clearly. Lets try again:
> - For the sake of discussion, lets assume that G.ho.st VFS returns
> files via Atom feed.
> - I have FOO.HTML containing a reference to FOO.GIF
> - I share FOO.HTML through G.ho.st VFS, and now have a direct link to
> download FOO.HTML
> - PROBLEM 1: If user opens this link in a browser, she sees the Atom
> wrapping FOO.HTML instead of the original file
> - User opens some Client that reads the feed, unwraps FOO.HTML and
> displays it in an IFRAME
> - PROBLEM 2: The browser renders FOO.HTML, detects the referenced
> image and tries to load it. This will fail because the image will be
> wrapped in an Atom feed, and browsers do not have built-in support for
> loading images through an Atom feed.

I'm assuming that if the client uses OpenFile, then they know they are
getting an Atom feed and know how to extract the actual content
(FOO.HTML in this case) from the feed, either via the content inlined
in the feed or by a link. In my mind only the client knows about the
Atom feed; the user sees only the extracted content of the feed,
rendered by the client as they client chooses.

If the client were a HTML editor, for example, the client would render
the source of FOO.HTML rather than displaying FOO.HTML as a browser
would. If the client were a file browser, the client could show
FOO.HTML as a normal file in a directory.

> Let me know if it's still unclear. My main point is that any file
> system should provide direct raw access to files, wrapping it or
> adding headers or footers.

I totally agree. I think representing the granted resources as Atom
feeds fulfills this requirement by allowing hyperlinks to the content.

.. Adam

[Adam Rosien]

Changes:

* Added Anton Bar (G.ho.st) as author.
* Replaced abstract with text from Ben Strong (Sharpcast).
* Added TODO use cases for "Launching an Application from a Service
Provider" and "Import/Export from Desktop Application".
* Removed "Authorization Endpoint" concept and added "Client Endpoint"
concept (for provider push).
* Separated Client pull workflow section from Service Provider push workflow.
* Integrated OpenFile-specific parameters as part of OAuth sequence.
* Defined OpenFile discovery service types.
* Added information about Authorized Feed expiration.
* Added full example for Client workflow.

New spec at http://groups.google.com/group/openfile/files.

Your comments are appreciated.

.. Adam

[Anton Bar (G.ho.st)]

It looks like we still have the old spec

On Mar 12, 12:20 am, "Adam Rosien" <a...@rosien.net> wrote:
> Changes:
>
> * Added Anton Bar (G.ho.st) as author.
> * Replaced abstract with text from Ben Strong (Sharpcast).
> * Added TODO use cases for "Launching an Application from a Service
> Provider" and "Import/Export from Desktop Application".
> * Removed "Authorization Endpoint" concept and added "Client Endpoint"
> concept (for provider push).
> * Separated Client pull workflow section from Service Provider push workflow.
> * Integrated OpenFile-specific parameters as part of OAuth sequence.
> * Defined OpenFile discovery service types.
> * Added information about Authorized Feed expiration.
> * Added full example for Client workflow.
>

> New spec athttp://groups.google.com/group/openfile/files.

[Adam Rosien]

Clicking on the link for openfile-1.0-20080311.html I get the new spec.

.. Adam

[Anton Bar (G.ho.st)]

Sorry, now I get "The page you navigated to does not exist.". I tried
in two browsers after cleaning the cache/

On Mar 12, 6:17 pm, "Adam Rosien" <a...@rosien.net> wrote:
> Clicking on the link for openfile-1.0-20080311.html I get the new spec.
>
> .. Adam
>

> On Wed, Mar 12, 2008 at 1:45 AM, Anton Bar (G.ho.st) <anton...@gmail.com> wrote:
>
>
>
>
>
> >  It looks like we still have the old spec
>
> >  On Mar 12, 12:20 am, "Adam Rosien" <a...@rosien.net> wrote:
> >  > Changes:
>
> >  > * Added Anton Bar (G.ho.st) as author.
> >  > * Replaced abstract with text from Ben Strong (Sharpcast).
> >  > * Added TODO use cases for "Launching an Application from a Service
> >  > Provider" and "Import/Export from Desktop Application".
> >  > * Removed "Authorization Endpoint" concept and added "Client Endpoint"
> >  > concept (for provider push).
> >  > * Separated Client pull workflow section from Service Provider push workflow.
> >  > * Integrated OpenFile-specific parameters as part of OAuth sequence.
> >  > * Defined OpenFile discovery service types.
> >  > * Added information about Authorized Feed expiration.
> >  > * Added full example for Client workflow.
>
> >  > New spec athttp://groups.google.com/group/openfile/files.
>
> >  > Your comments are appreciated.
>

> >  > .. Adam- Hide quoted text -
>
> - Show quoted text -

[Adam Rosien]

Files on Google Groups seems to have transient failures... :(

.. Adam