Architectural Overview
As shown in the diagram, a basic DRM transaction starts with the content creator. This person is most often an author, musician, photographer, or other creative professional who generates a piece of media, be it audio, video, text, or some other format. The media is converted to digital form by either the creator or a content publisher. Once in digital form, the media file is encrypted to protect it from unauthorized use, and stored on the publisher's server. A license server, possibly with the help of a pay management system, manages access to the encrypted file by decrypting it on demand or by doling out access keys. Decrypted media might be delivered directly to a browser, or an end user might download the encrypted file and decode it with an appropriate DRM-enabled client. Either way, the result is a fully licensed, digital-quality media file or stream in the hands of a consumer.
In a B2B scenario, the end consumer might be replaced by a server application that requests media and manages the resulting downloads. For example, a news service could make its articles available for syndication. A Web site or other news outlet would then set up a server to automatically purchase and download the latest articles at a certain interval.
The architecture shown in the diagram is fairly standard. For example, IBM's EMMS package implements this design closely. IBM provides a more or less turnkey approach to online digital rights management by bundling the DRM capability into an end-to-end content hosting service. Microsoft, on the other hand, provides the Microsoft Windows Media Digital Rights Management SDK to let its customers build their own DRM-enabled systems. Microsoft has also partnered with companies that provide full-service solutions built around this SDK, similar to IBM's EMMS solution.
Any DRM-enabled architecture requires additional steps before it represents a complete and robust service. The servers must be secure, as they will be housing license materials, customer information, and the protected media itself. Transmission between customers and the servers must also be encrypted to protect any customer information, licenses, and even the media itself while in transit.
The system needs to be robust, especially in situations where customers are paying for their media. This means that you must provide generous bandwidth to accommodate downloads, a secure and stable pay management scheme that doesn't permit errors like inaccurate billing, and an intuitive storefront that gives customers quick access to desired products.
Controlling Access to Media
Once a customer downloads the media, the DRM framework must decide which aspects of the media that customer can and cannot view. A flexible framework should let you specify the following rights restrictions at the very least:
Usage Limits. The content provider can specify the number of times a customer may access a given media file. An MP3 might be licensed to play only three times, for example.
Node Locking. You can tie the ability to access a given piece of protected media to specific PCs, PDAs, or other devices. The file cannot be accessed from unlicensed devices.
Archival and Transfer Control. This restriction lets you control the ways in which protected files may be archived to other media. Archiving a protected audio file to floppy disk might be permissible, for instance, while archiving the same file to audio CD-R formats might not.
Calendar Limits. Media can be licensed based on the date, or time of day. For example, video files might be viewable only in the evening, or only on the weekend.
Unlicensed Preview. Even when the customer has no license for a given piece of media, the content provider can opt to allow him or her a low-bandwidth or time-limited preview.
Super-Distribution. This refers to the practice whereby customers are allowed to redistribute protected media under specific terms. For example, recipients of the redistributed files might only be allowed to preview a portion of the media, until such a time as they obtain their own licenses.
Granular Access. One of the more complex controls, this allows different licenses to unlock only specific parts of a protected file. For example, a preview license might unlock a specific sample chapter of an electronic book, while a full viewing license would provide access to the entire text.
Your framework should also be robust, such that the rights cannot be easily circumvented. Thus, you must have strong security measures in place on both the client (viewer) and license servers. DRM architectures frequently employ strong encryption and robust key mechanisms like Public Key Infrastructure (PKI) to ensure that the private key can be protected and that transmissions between client and server are secure.
Choosing a Solution
As with any framework or SDK, different products provide varying levels of features. When evaluating a DRM solution, it's important to confirm that it meets your needs. Technology constraints are likely to be a significant issue. Any DRM framework you implement will have to support the various media formats and codecs employed by your business. It must also support appropriate licensing models, and optional features like super-distribution may prove critical.
Protection and security issues will also play an important role in your decision. You should clearly understand what levels of protection are applied to the media, license management, transmission protocols, and customer information. The system must be robust, not just in its operation, but also in its design.
For instance, customers should be able to archive licenses and recover them if the customers lose data on their computers. You will also have to decide whether the framework goes far enough with respect to user identification—or if it goes too far. Many customers will be justifiably sensitive if their identities and online habits are being tracked by your system.
If you plan to host the DRM architecture yourself, be sure that it supports your chosen platforms. Pay special attention to life cycle costs for your system, especially licensing, for the DRM software itself and for the operating system and database that power it. You may want to consider using third party licensing server and fee management systems instead, to reduce security and complexity issues. You should also think about the impact a framework will have on your customers. Client-side platform restrictions, proprietary viewers, payment schemes, and other usability issues need to be considered in the context of your target audience.
You will also have to spend some time evaluating the flexibility of the DRM framework. Standardization efforts in the DRM industry are ongoing. Choosing a vendor that tracks the current developments in Rights Expression Languages, for example, can help to ease you through the growing pains of DRM technology. (See the article "Freedom of Expression," for more information on these XML-derived standards.)
Once you select a DRM framework, you can expect a fair amount of integration, and possibly development, effort. Some technologies are supplied as turnkey architectures, whereas others simply expose APIs to be incorporated into proprietary applications. Consequently, thorough review and early prototypes may help you to explore a framework before you commit your infrastructure to that solution. Many of the major vendors provide evaluation licenses for developing prototypes.
