Figure 1: The most abstract model of legal rights mapping to an underlying DRM implementation
On more than one occasion in the recent past, debate has raged about the use of the term "Right" in the context of "Digital Rights Management". Indeed, it has been a rich vein of confusion that has led to significant misunderstanding and muddled agendas.
Simply stated, the problem is one of historical accident. The Digital Rights Management (DRM) community has used the term "Rights" for many years to refer to activities managed by the permissioning and access control mechanisms of traditional DRM systems. One often encounters phrases such as "the right to view" and "the right to print" to describe controls imposed on consumers over access to "protected" content.
Unfortunately, the word "Right" is a well-defined legal term with even longer history. Terms such as "Intellectual Property Rights" (IPRs), "moral rights", and "mechanical rights" are all heavily used in legal parlance and, typically (at least in the context of interest here), refer to the legal rights of creators and distributors of content designed to protect their financial interests.
Worse still, because DRM solutions are marketed at precisely those content creators and distributors to whom the legal definitions apply, the terminology is invariably mixed up to the point where few are sure about the real topic of conversation. The upshot has been a seemingly endless flow of confused press reports, confused standards body meetings, and confused arguments for and against DRM itself. Add to the milieu the subject of "human rights" and trouble really begins to erupt.
In this article, we try to dispel some of the myth surrounding DRM whose primary cause is the hotchpotch of terminology. Moreover, by unravelling the terminology it is possible to make better analysis of advances that can be made in Rights Management architecture and so address head on some of the criticisms levelled against DRM. In doing so, the author seeks genuinely to answer concerns rather than argue against or rationalise them.
Contrary to urban folk law, DRM is not about wielding absolute power and unconstitutional control over individuals. Rather, DRM is about attempting to win back some of the ground lost to content providers when their material moves into the digital domain. Ultimately, content providers are trying to make a fair and decent living from their endeavours. Many are fearful that digital representation of their content will render their commercial position untenable. Consequently, and in the absence of new business models, these players will shy away from the digital marketplace. Tech-industry pundits have suggested that new business models are the answer. However, there has not been a corresponding avalanche of new models has failed to materialise.
Regardless of opinion about them being outmoded, defunct, or otherwise, laws and treaties governing intellectual property were put in place primarily to allow content providers the ability to earn the fair and decent living they desire. The primary goal sought from DRM is to assist the application of existing or modified provisions to the digital domain. In short, content providers simply wish to assert their "legal" (and contractual) rights. Unfortunately, existing DRM implementations attempt to approximate this by providing low-level permissioning and copy-protection mechanisms. Herein lies a problem.
| Any means, technical or otherwise, by which content providers can avoid critical devaluation of their content by virtue of the existence of anarchic distribution channels. |
One of the loudest anti-DRM voices has been that of Bruce Schneier of Counterpane Internet Security Inc. In the August 2001 edition of his newsletter "Crypto-Gram", he picks up on the theme of alternative business models in place of DRM, remarking:
| I don't know what model will become the prevalent one in the digital world. But I do know that technical methods to prevent digital copying are doomed to fail. |
In denying the success of technical solutions in the above statement, Schneier is directly attacking the use of encryption technologies to implement copy-protection. Unfortunately, this is often read as an argument against DRM in the wider context.
Interestingly, although the question of workable business models remains unanswered, three examples are cited of alternative models in action:
Some believe that DRM is about using digital technology to manage legal rights (i.e., "digital management of rights"). Others believe that DRM is about managing access controls over digital content or, in other words, "managing digital rights". In truth, DRM is really about both of the above but for very different reasons.
Remember that content providers' primary goal is to protect their legal and contractual rights. Within reason, they do not particularly care about implementation details, so long as their aims are achieved in a legal, moral, fair, and satisfactory manner. The vendors of DRM solutions, on the other hand, tend to think in a lower-level, implementation-specific mode. What we really need is to understand the relationship between the two sides as depicted in Figure 1.
Figure 1: The most abstract model of legal rights mapping to an underlying DRM implementation
Clearly, one approach to implementing management of the contract is to effect access controls over content to ensure that legal and contractual rights are not being violated. There are, however, many other implementation possibilities although it is useful to dwell on this one for a while longer because it is the approach taken by all present-day DRM systems. Examining this mode of implementation helps to understand why today's DRM technologies are failing. The abstract model is redrawn in Figure 2 with the implementation defined as an access control mechanism.
Figure 2: Implementing management of legal rights via access controls
Alert readers may have noticed that, despite setting the implementation in Figure 2 to be "access control", the mapping between legal rights and the underlying implementation is still yet to be defined. This is a key concept that many in the industry seem to have been missed. Consequently, the mapping invariably defaults to that shown in Figure 3.
Figure 3: How today's DRM maps Legal Rights into the underlying implementation model
Taking the approach illustrated in Figure 3, content providers are forced to think at the implementation level in order to map between their desired goals and the functionality of the tools provided.
Pausing for a second to consider some of the most common complaints about DRM systems, we find that they often include the following:
Solution 1, is exactly that described by Figure 3 with all the onus of ensuring fair access placed on the beleaguered content vendor. Not only does the vendor have to think in low-level permissioning terms, but now the requirements of all consumers must be taken into account and expressed in those terms. The same exercise would have to be undertaken by all content vendors for every content item ever published. On balance, solution 1 is almost certainly not viable.
Solutions 2, 3, and 4 extend the mapping model by the addition of a secondary mapping between different low-level access controls. This is depicted in Figure 4.
Figure 4: Secondary mapping between low-level access controls
Solution 5 is the scenario shown in Figure 2 where the precise method of mapping is as yet undefined, although we do know that it is an automatic process undertaken on behalf of the content vendor by the DRM infrastructure.
Solutions 2-5 all appear to provide exactly what we need. The content vendor communicates with the system in the language of legal rights, the DRM system implements that in a way that it understands, and (as long as we have the mappings correct) the content consumer is provided with the access they need. In fact, all four of these solutions are roughly equivalent, differing mainly in implementation detail. Solutions 2-4 may be more straightforward to implement than solution 5, but the latter has the advantage that the semantics of the high-level rights description are never hidden by an intermediate low-level representation. Where solutions 2-4 utilise an intermediate access control definition, it is possible that some meaning may be lost and that less than perfect mappings might result.
A question remaining is how to create the automatic mappings, either between low-level access controls in solutions 2-4 or from the high-level to low-level definitions in solution 5. This issue is tackled in the next section.
However, there is another part to the story, because policy is only another may in which to structure complex rules. The collection of policies equates to the complex set covering access control for all possible contexts. Erickson tackles this problem by suggesting delegated policy. A logical extension of that is to allow policy to be delegated beyond the realm of the content provider and onto trusted third parties. Another extension is to allow "meta policies" to define how rules can be changed from one context to another (echoing the model illustrated in Figure 4).
The policy model requires further extension to fit the automatic mapping of high-level legal rights to low-level access controls. A close analogy can be found in the way that presentation of Web content can be separated from its logical description via the application of style sheets. Style sheets provide a mapping between different kinds of representation to be realised according to context. This is precisely what we are seeking for solution 5 described above.
For a DRM style sheet to work, it must be a trusted entity and one can devise any number of schemes based on public key infrastructure (PKI) tools to achieve this safely. Electronic signatures on style sheets might be used to anchor them into a web of trust and to ensure the integrity of the mappings they describe.
Figure 5 illustrates the concept.
Figure 5: Trusted Style Sheets
The job of a style-sheet is to convert from a logical representation to a practical representation. In the case of Web pages, that conversion might be between structured XML data to visual information that a browser can understand. It is a conversion from one domain of discourse to another. In the DRM case, the conversion can be viewed as an interpretation of contractual terms and conditions in respect of consumer requirements. In concrete terms, that may be to express the terms and conditions according to low-level permissions that make sense according to the full context of the consumer's activities and circumstance.
In essence, a set of permissions is effectively negotiated between the content provider and the consumer. The content provider establishes their side of the negotiation via the machine readable contract. Consumers articulate their side of the negotiation via style-sheets. Mediation may be provided by trusted third parties and the full context of the negotiation can be taken into account when deciding the outcome of the negotiation. User credentials play an important part in establishing context.
Style-sheets might equally be applied to the problem of direct mapping between low-level access controls, as described in solutions 2-4 above. Style sheets provided by trusted third parties would be validated by appropriate electronic signatures.
In building rights expression languages, the standards bodies must consider the above arguments with due care. If rights expression languages are designed such that they merely support the expression of access controls then we have clearly failed to move on from the present poor state of the industry. DRM systems are failing in part because they take fundamentally the wrong approach to rights expression.