Figure 10-1 shows a reference architecture for a digital rights management system. The reference architecture is by Bill Rosenblatt, et al., and is discussed in some detail in the book Digital Rights Management: Business and Technology (John Wiley & Sons). The reference architecture points out the key interactions in a DRM system and also exposes some of the weaknesses in current DRM schemes.
In Figure 10-1, there are three primary participants. The client is an application invoked on behalf of the entity wanting to access and use a digital resource. The content server is the application that is invoked on behalf of the entity supplying the digital resource. The license server is the application invoked on behalf of the person who owns or controls the rights associated with the good. The license server and content server might be operated by the same entity or they might not. For example, the owner of the goods may contract with multiple distributors to supply the good but control the licensing centrally.
In the reference architecture, the client, on behalf of the user, requests a specific resource from the content server (1). The content server uses a content repository along with product information to create a content package. The content repository might be part of the content server itself or a standalone content management system. The product information specifies price and other product-specific information. It makes sense to separate the product information from the content, because the same content may be sold as different products differentiated by customer class, additional services or warranties, and so on.
The content is delivered in an encrypted content package that contains both the content and metadata. Whether the content is streamed or delivered as a single package is inconsequential to our discussion. The metadata usually includes information such as title, author, rights holder, and other information about the content as well as information that uniquely identifies this content and transaction.
The DRM controller (2) contacts the license server (3) associated with the content package to retrieve a license for the content. The DRM controller sends the license server information about the content package and the identity credentials for the entity that invoked it.
The license server checks the identity credentials (4) using whatever identity infrastructure is available to it for authentication and then consults a rights database (5) for authorization. We'll see an example of an XML language for expressing rights later in this chapter.
There may be a financial transaction (6) if the user is required to pay for the license. Alternately, the license server may require some other consideration such as registering and providing contact information. Once consideration for the license has been received, encryption keys (7) are retrieved based on the content package identity and these keys are used to generate a license that is sent back to the DRM controller (8) as an encrypted package containing a statement of rights and a set of keys for unlocking the content package. The license is encrypted to protect the keys used to unlock the content package and to ensure its integrity.
The DRM controller decrypts the license and uses the keys contained in it to unlock the content. The content can be sent to a rendering application (9) for display (10).
The client, in managing rights, may store information about usage in the content package. Usage data is stored with the package, rather than separately, to ensure that even if the content package and license are moved to another client, the usage restrictions are honored and audit trails are continuous.
The client application is a critical component in this scheme, because the client application, rather than the client, receives and processes the keys. This overcomes, in part, the problem of a user unlocking the digital content and then using it in an uncontrolled fashion, because the client application can ensure the permissions carried in the license are honored.