Spent a little time today going over the OpenSAM Specs. I've cut and pasted what I thought were viable sections below. My overall impression is that this spec is focused solely on WebDAV activities (I was hoping for a more broad SaaS / cross-domain communication/actions best-practices document). However, there's some interesting stuff here. I was especially interested in the 'Document Veneer' portion of the spec. Notes and plagiarizations below:

The spec revolves around the definition of 2 'applications'. The home app (client) and 'Productivity App' (remote app). 

The architecture section makes note of an interesting assumption: Assumes a 'cascading' style of communication across multiple servers when utilizing multiple applications on multiple hosts (client talks to Server A which talks to Server B which talks to Server C. Interesting that from there server C talks back to the client. Not sure how this works.):

(Click image to enlarge)

"The cascading Productivity Applications simply launch each subsequent application with the CGI Parameters they received when they were launched. Since these CGI Parameters provide access to the Home Application, the web of applications remains connected with no loss of fidelity."

Summary
OpenSAM's architecture supports a broad range of solutions because:

   1. Once OpenSAM is added to an application, it can immediately join mashups with all other OpenSAM applications.
   2. OpenSAM applications can play many roles in a mashup and can be wired in a variety of ways.
   3. The LAUNCH LINK and WEBDAV READ/WRITE connections support very rich contextual, document, and document meta-data transmission.
   4. Mashups are built by using applications' templates, settings, account management, and GUI based meta customization features.
  
  
Document Veneer:

Users are accustomed to the files and folders paradigm, however, and think of their data and their processes in those terms. To bridge the powerful solution ? document centric gap, we recommend you strive to wrap your solution in a "Document Veneer." By doing so and working with SAM, your solution will be interoperable with more online Home and Productivity applications.

You can choose to support this to varying degrees. You may already support access to your document via a
domainname.com/get.cgi?id=1234
query. For other SAM applications to browse a user's documents, however, they will want to view them as:
domainname.com/foldername/usersfilename.ext
instead. We recommend that you take the document organization paradigm you present to your users (folders, projects, tags, etc.) and expose it directly in your HTTPS and WebDAV URLs. For example, if a user is a member of Group A and works with documents within Project B there, then enable them to browse and find their documents at:
domainname.com/GroupA/ProjectB/documentname.ext.


Define Document Commit Points

Commit Points are actions and points in time when changes to a document are committed to the system and become the current authoritive version of the document. Since multiple participants of a SAM mashup manage and manipulate documents, we must define when a document changes from the perspective of outside participants.

For example, as users open, modify, and save their data within your solution, you've defined points when the data is "committed" and becomes the current version. For collaborative or other reasons, you may commit their data upon an auto-save or automatic submission. Or you may autosave to a temporary copy and only commit it when the user clicks the Save button. Either way, define for your application's precise actions or conditions that commit a user's data to the current version of their document. Your Document Commit Points define when a newer version of a document is made available across SAM applications.

If your application follows the desktop model, the Document Commit Points would operate as follows:

   1. Dave opens his document MYDOC and begins editing.
   2. Every NN seconds your application autosaves MYDOC to a temporary location on the server.
   3. Dave clicks the Save button. This updates the authoritative version of the document on the server.
   4. Dave makes additional edits.
   5. Additional autosaves are perfomed.
   6. Dave clicks the Close button.
   7. Your application prompts Dave to see if he wishes to save or discard his changes.
   8. Dave chooses to discard his changes.

RESULT: The authoritative version of the document remains the one saved in step c.

A more dynamic model might proceed as follows:

   1. Dave and Bob each open the document SHAREDOC and begin collaborative editing.
   2. The system saves their edits in real time. New versions of SHAREDOC are continually being created.
   3. Dave and Bob close their browser window, leaving their edits in the authoritative version of the document.

In this case, artificial Commit Points are established. For example, you could establish that every 10 minutes of continuous editing defines a commit point. You'll want to synchronize these commit points with your version recoverying or rollback scheme. You'll also want to define these commit points so they are not too granular. The other SAM applications in your mashup do not want to manage 100s over versions created during a single editing session.

This resulting Document Veneer enables a wide variety of other components to browse and manipulate your documents without custom coding to your API or your paradigm. This last point is, by far, the biggest benefit of SAM and serves as a guiding principal for SAM.


Application Description File

Guess what? There's an XML manifest for every 'Productivity Application'!

Every application will describe itself in an OpenSAM Application Description File. Applications that wish to connect to one another will read each other's Application Description File to discover all the details needed to connect. The Application Description File also contains branding, logos for use in mixed application UIs, and non-technical information for users to help them decide between the many applications available.

Application Description Files are in RDF format and can describe more than one application.

Application Description Files are updated as an application evolves, so applications must periodically refresh information they've cached about applications they connect to. We recommend your refresh every 24 hours and immediately when an error is encountered that might indicate stale information is being used.

Strictly speaking, the Application Description File is not mandatory for an OpenSAM Launch Link or custom crafted mashup to work. It is required for non-technical users to connect applications and it does provide the mechanisms for better UI in aggregate applications.


SSO stuff:
authenticating w/ dynamically-generated session ID, not password. Not sure how this works?
basic auth over ssl
JIT Account Provisioning

Table of SSO params:

Examples

URL within a Home Application to launch a Productivity Application:

http://www.coolapp.com/?StorageServerUrl=https%3A%2F%2Fwebdav.homeapplication.com/handlr
&StorageUserName=JohnSmith
&StorageSessionId=FKD39053DLS
&StorageOrg=ABC%20Company

WebDAV request URL to authenticate the SSO via WebDAV:

https://webdav.homeapplication.com/handlr?
&StorageUserName=JohnSmith
&StorageSessionId=FKD39053DLS
&StorageOrg=ABC%20Company

WebDAV HTTP request including headers:

PROPFIND /handlr/?StorageUserName=JohnSmith

&StorageSessionId=FKD39053DLS
&StorageOrg=ABC%20Company

Host: webdav.homeapplication.com
User-Agent: Server-to-Server HTTP_Request
Connection: close
Depth: 1
Content-Type: text/xml
Authorization: Basic c2ZkZW1vQGluZXRvZmZpY2UuY29tOkZBRjk4QjE2NEE5QzQzMEI3Rjk5QzUwN0QwRDNBNTRG^M
Content-Length: 171

Notes:

The WebDAV request is over HTTPS (ssl), so Authorization: Basic is allowed.

The StorageUserName and StorageSessionId is contained in both the WebDAV request CGI parameters and in the Authorization: Basic header.

Meta-Data associated w/ documents:
Storing Meta-Data is important! Should be handled by Home App. Productivity app can relate to home app about changes, etc. Not sure I get all the PROPPATCH stuff below:

When the Productivity Application stores a document via WebDAV, it also issues PROPPATCH requests on the document to set the meta-data values it was given when launched. It does not include the StorageMeta_ prefix portion within the attribute name when performing the PROPPATCH.

For example, if the document KeyThoughts.html were created with StorageMeta_Region=South%20America and StorageMeta_Audience=Internal-Private, then the following PROPPATCH would be issued:

PROPPATCH /handlr/KeyThoughts.html?
&StorageSessionId=nrksnx6ockEkHoyiSTd__3ZfWPeP1YrYELU5.XofrryIMM%3D
&StorageOrg=ShareMethods
&StorageUserName=joe%40shareoffice.demo HTTP/1.1

Host: webdav.homeapplication.com
User-Agent: Server-to-Server HTTP_Request
Connection: close
Content-Type: text/xml
Content-Length: 262

<?xml version="1.0" encoding="utf-8" ?>
   <D:propertyupdate xmlns:D="DAV:" xmlns:Z="http://www.w3.com/standards/z39.50/">^M
     <D:set><D:prop><Z:Region>South America</Z:Region>
                  <Z:Audience>Internal-Private</Z:Audience>
            </D:prop>
     </D:set>
   </D:propertyupdate>

There is an interesting aspect of this regarding saving a new file 'BB' which inherits from 'AA':

If a user performs a Save As... to create a new file from an existing file, the Productivity Application must take extra care to propagate the CGI Parameter's meta-data to the new file as well.

This raises another issue -- what happens when the user opens file AA, and then saves it as BB. We wish BB to inherit the meta-data associated with AA, but perhaps not all of it. Since the meta-data is defined and managed by and for the Home Application, we allow the Home Application to decide which attributes to propagate from AA to BB. We do this by informing the Home Application which file the new file was derived from by doing a PROPPATCH of a special attribute:
<Z:SavedAsSourceFile>URI of the source file</Z:SavedAsSourceFile>

The Home Application is free to perform meta-data propagation, simply store for future use, or completely ignore this special property.