First, rather than defining two endpoints, one for Open Dialog, the
other for SaveAs Dialog, we propose to consolidate these into one
endpoint, tentatively called the "Authorization Endpoint". This URL
will take multiple options specified by the Client indicating what
data and operations the Client wants to be authorized for. For
example, "read+1+file" (Open), "write+1+file" (Save As), or
"create+1+directory" (grant the ability to for the Client to create
files in a User-selected directory). The Service Provider is
responsible for displaying a proper UI to the User for the request.
This change simplifies the service and offers an extensibility point
for adding other kinds of authorization requests. We're thinking of
standardizing typical file requests like the examples by parameters
with three parts like the examples above:
1. Operation: create, read, update, delete
2. Count: one, many
3. Resource: file, directory
The second change we propose is to remove the Authorized File List
(AFL) document returned (directly or indirectly via a URL) to the
Client, and instead return an Atom feed document containing the
granted resources. Using Atom removes the need for a new format,
reduces the implementation effort of both Clients and Service
Providers due to existing libraries, makes this spec more
standards-compliant, and offers a flexible extension mechanism for
describing authorized resources.
Your thoughts are appreciated; we are excited about the simplifications.
.. Adam