Architecture

The Content Access Framework provides a common interface for applications to access content. In effect, it behaves as a switch between different agents, known as Content Access Agents.

Each agent is an ECOM plugin, which implements the Content Access Agent interface 0x10204740. This interface should be a static function that creates and returns an instance of a class derived from ContentAccess::CAgentFactory (e.g. ContentAccess::CF32AgentFactory).

static CAgentFactory* AgentImplementationFunction();

There is a special agent supplied by Symbian known as the F32 Agent. This agent is used as a fallback for reading unprotected content files. If no other agent recognizes a file, the F32 agent will be used to read it. In effect, this is the same as opening the file using an RFile, but allows the application to use the same code to read protected and unprotected content.

The following diagram illustrates the implementation of CAF with two fictitious agents (OMA and MPEG).

The problem with this implementation is that all three agents are loaded into the application's process space, which represents a security risk. The application could potentially access the key used to decrypt protected content.

A better solution is to implement the parts of the agent that require access to encryption/decryption keys or rights in a separate server process. When platform security is enabled, the server implementation also allows the APIs to be policed by the agent server DLL to ensure only applications with the right capabilities will have access to the content.

To improve performance, any functionality that does not require access to keys or rights should be implemented in the client side DLL. Client side functionality reduces the number of context switches the processor needs to perform resulting in improved performance from the agent.

There is no need to implement the F32 agent in a server process since it is only used to access unprotected content.

The following guidelines are suggested for implementing Client/Server agents, but may not be appropriate for all agents.

Client side functionality

• Implement the Content Access Agent ECOM interface

• Browse the contents of files

• Retrieve attributes or meta-data from a file

• All functions requiring the agent to display a user interface or dialog

• File recognition (for client applications and Apparc MIME types)

• Marshall calls to the server side

Server side functionality

• Content Encryption (protecting plaintext)

• Content Decryption (reading DRM content)

• Manage, protect and store Rights

• Any potentially destructive operation such as deleting content or rights

• Notifications

• Capability Enforcement

The APIs provided in this document indicate the functions that are likely to require a client process to have DRM capability in order to use the functionality. The client process will only need DRM capability if it attempts to read DRM content using a CAF agent that implements a DRM protection scheme.

The capability can only be enforced by the CAF agent running in a separate server process, so it is the responsibility of the agent to ensure the client process has the required capabilities.

There are no capabilities required to use unprotected content.

CAF is used to read unprotected or DRM protected content. It is a client side DLL that must be linked with the process using CAF.

The agents may run in separate processes and will not have the correct capabilities to open files in TCB or server private directories using just a file name. These files must be opened by the process that owns the file and an open RFile handle passed to CAF in order to read them.