http://code.google.com/p/opensocial-resources/issues/detail?id=1278

As was illustrated by the confusion and discussion at the face-to-face around the notion of an "OWNER" , it's obvious that these things need clarification and proper definition in the spec. Primarily, the idea of "OWNER" is far to under-defined in 2.x ...

For 3.0, I would like to see us clarify those things even further...and possibly even define a few additional roles for clarity..

1. VIEWER - The entity for which gadget is currently being rendered.
2. SUBJECT - The data that is currently being handled by the gadget
3. OWNER - The entity responsible for the gadget instance
4. CONTEXT - The context into which the gadget instance is included (e.g. the page it is installed on)
5. SOURCE - The source of the gadget specification (identifies the entity that created the gadget)

For example,

When a Profile gadget is displayed on a page...

• VIEWER is the user viewing the profile data
• SUBJECT is the profile data being displayed.
• OWNER is the entity responsible for adding the profile gadget instance to the page
• CONTEXT is the page onto which the gadget is displayed
• SOURCE is the entity that provided the profile gadget code

When a Files gadget is displayed on a page...

• VIEWER is the user viewing the profile data
• SUBJECT is either the file or the folder being displayed.
• OWNER is the entity responsible for the files gadget instance itself
• CONTEXT is the page onto which the gadget is displayed
• SOURCE is the entity that provided the profile gadget code

Currently, the single, poorly defined OWNER role is used ambiguously by containers to represent SUBJECT, OWNER, CONTEXT and SOURCE... which isn't adequate for a variety of reasons.

SUBJECT is the most difficult to define of the roles since it may not necessarily represent a single data object, but a composite of information from multiple sources and multiple owners compiled dynamically by the gadget itself. For instance, a gadget may display data from a profile, a list of files, and an activity stream.

The specific extent of this change would need to be determined. However, the following changes would be apparent:

• For signed fetch, oauth and oauth2... right now, we say that the identity of the "viewer" and "owner" can be included in the request, but there's no clear definition of what the "owner" signifies in this case. With this change, these would be modified to allow the identity of the VIEWER, APP OWNER and CONTEXT OWNER. The identity of the SOURCE could be included but would be entirely optional and likely not very useful. The identity of the SUBJECT and SUBJECT OWNER typically should not be important to a remote resource and would generally be very difficult or impossible for the container to reliably determine. The parameters would be:
  • opensocial_viewer_id (specifies who the remote content is being requested for)
  • opensocial_owner_id (specifies the container's notion of who owns the instance of the gadget that is requesting the data... might be the same as viewer_id but might not)
  • opensocial_app_id (specifies the container's unique identity for the application instance that is requesting the data.. this would be optional... a remote service might provision access to content to individual instances for billing or other administrative purposes, etc)
  • opensocial_context_id (specifies the container's unique identity for the context into which the gadget instance is deployed.. this would be optional.. a remote service might provision access to content based on the context to which a gadget is deployed for billing or other administrative purposes... for instance, a profile gadget might only be permitted to access remote student information if it's deployed on a context related to a particular course)
  • opensocial_source_id (specifies the container's notion of who provided the gadget specification)