Specifying Rights

One of the most important features of a DRM system is the ability to specify and manage rights. Rights are a special kind of authorization, and much of what we learned about authorization in Chapter 8 is applicable to DRM. The differences lie in the fact that DRM is meant to restrict actions on a much finer-grained scale than we typically deal with in a standard authorization system.

Authorization rights typically center around whether a subject is allowed to read, modify, or create objects. As we saw, we usually specify the rights for classes of users against classes of objects in order to make the task manageable. In DRM, we often want to give specific rights (for example, the right to view but not copy) to specific people (Ted in accounting or a particular customer) for specific time periods (for the next two hours or three more times). That makes the task much more difficult. The problem can be made tractable by being able to build general licenses and derive specific licenses from them automatically.

We also saw in Chapter 8 that separating authorization rights from the objects being protected increases the ability of operators to take protective action. Specifically, when rights are associated with objects, removing rights for a particular user means visiting each object the user might have had rights to. The goal of systems like RBAC is to specify rights separately, so we can remove access rights across the board with a single, reliable action.

In DRM systems, the nature of the problem does not make this solution possible. Since our problem statement is to protect content that is not directly under our control, the rights will generally be sent outside the systems we directly control to some other system that will enforce them. Offline access to protected content is usually a requirement, and so it is not practical for the client application to check back with the license server each time the content is accessed. Thus, rights can be difficult or impossible to revoke once they've been issued.

There are several proprietary DRM systems and most of them have proprietary languages or systems for specifying rights. XrML is an XML-based rights management language. We'll discuss it briefly because it is gaining widespread acceptance as an open format for specifying rights and because it illuminates the kinds of features that you want in a rights language. XrML is a large standard, and this section is not intended to be a tutorial. More detailed information on the XrML standard can be found at http://www.xrml.org. The examples given here are based on the Example Use Cases document that accompanies the XrML 2.0 specification.

The following simple example gives us a feel for XrML. In English, the license grants a specific RSA public-key holder the right to print the contents of an object identified by a URI as many times as she wants before Christmas day, 2005.

    <license>
      <grant>
        <keyHolder>
          <info>
            <dsig:KeyValue>
              <dsig:RSAKeyValue>
                <dsig:Modulus>Fa7wo6NYf...</dsig:Modulus>
                <dsig:Exponent>AQABAA=  =</dsig:Exponent>
              </dsig:RSAKeyValue>
            </dsig:KeyValue>
          </info>
        </keyHolder>
        <cx:print/>
        <cx:digitalWork>
          <cx:locator>
            <nonSecureIndirect
               URI="http://www.contentguard.com/sampleBook.spd"/>
          </cx:locator>
        </cx:digitalWork>
        <validityInterval>
          <notAfter>2005-12-24T23:59:59</notAfter>
        </validityInterval>
      </grant>
    </license>

You can see that the <keyHolder/> elements contain the user's key. The <print/> element gives the allowed action. The <digitalWork/> element identifies which resource the license applies to. The <validityInterval/> element specifies the interval for which the license is valid.

This is an example of an XrML end-user license. More complicated license specifications are possible. As an example, suppose that PDQ Records wishes to allow university libraries to allow their patrons to check out digital music. There are three types of rights that might be specified.

The first, very general type concerns one entity granting rights to a class of content to a class of entities. Here's an example:

PDQ Records allows university libraries to issue limited end-user licenses within certain parameters for any content they have purchased.

The second type is a policy specification. In a policy specification, an entity spells out specific rights that classes of users have regarding classes of content. Here's an example:

Brigham Young University will grant faculty the right to check out any PDQ Records song in its collection for up to six months. Student may checkout any PDQ Records songs in the BYU collection for three weeks. Anyone may play any PDQ Records song in the BYU collection on a library computer at any time.

The third, and most specific, type is an end-user rights license. Here's an example:

BYU grants Alice the right to play "When the Thistle Blooms" for three weeks.

Notice the hierarchy of rights contained in these examples. The first is very general and grants very broad rights to a class of entities. The rights specified in the second policy statement must fit within the rights granted in the first statement. Similarly, the rights granted in the third policy statement fall within the rights granted in the second statement, and hence those granted in the first as well.

In addition to specifying rights, this example assumes that Brigham Young University can uniquely identify itself and assert that it is a university in a way that is trusted by PDQ Records, and that Alice can uniquely identify herself and assert that she is a student in a way that BYU can trust.

XrML can be used to specify each of these cases, although the XML documents for each are lengthy and not included in the interest of brevity. Interested readers are referred to the Example Use Cases document that accompanies the XrML specification.