D-Lib Magazine
July/August 2002

Volume 8 Number 7/8

ISSN 1082-9873

Federated Digital Rights Management *

A Proposed DRM Solution for Research and Education

Mairéad Martin
Director, Advanced Internet Technologies
The University of Tennessee
<maireadm@utk.edu>

Grace Agnew
Associate University Librarian for Digital Library Systems
Rutgers, the State University of New Jersey
<ganew@rci.rutgers.edu>

David L. Kuhlman
Analyst, Advanced Internet Technologies
The University of Tennessee
<jkuhlman@utk.edu>

John H. McNair
Senior Systems Analyst, Advanced Internet Technologies
The University of Tennessee
<jmcnair@utk.edu>

William A. Rhodes
Consultant, Advanced Internet Technologies
The University of Tennessee
<wrhodes@utk.edu>

Ron Tipton
Senior Systems Analyst, Advanced Internet Technologies
The University of Tennessee
<uther@utk.edu>

Introduction

This article describes efforts underway within the research networking and library communities to develop a digital rights management (DRM) solution to support teaching and research. Our specific focus is to present a reference architecture for a federated DRM implementation that leverages existing and emerging middleware infrastructure. The goals of the Federated Digital Rights Management (FDRM) project are to support local and inter-institutional sharing of resources in a discretionary, secure and private manner, while endeavoring to maintain a balance between the rights of the end-user and those of the owner. "Federated" in our project title refers to the shared administration of access controls between the origin site and the resource provider: the origin site is responsible for providing attributes about the user to the resource provider. FDRM applies and extends the federated access control mechanisms of Shibboleth, a project of the Internet2 Middleware Initiative to develop "architectures, policy structures, practical technologies, and an open source implementation to support inter-institutional sharing of web resources subject to access controls". [SHIB]

FDRM is being pursued by members of the VidMid Video-on-Demand Working Group [VIDMID], a collaboration between the Internet2 Middleware Initiative [I2MID] and the Video Development Initiative [VIDE]. The VidMid agenda is aligned with the goals of the National Science Foundation Middleware Initiative, a national effort to develop enabling middleware for applications in science, engineering, and education [NMI]. While VidMid work is centered on enabling digital video applications, the application of FDRM is extensible to digital content in any format.

DRM Requirements for Research and Education

DRM is recognized as a complex and critical aspect of the lifecycle of a digital object. In Research and Education (R&E), we are currently witnessing a surge of interest in DRM for several reasons. An obvious reason is the need for DRM to support digital library collections, code and software development, distance education, and networked collaboration, among other applications. Many institutions, for example, have completed the first step in the development of digital collections — the digitization and storage of content, and the development of descriptive metadata schemes for discovery and retrieval of that content. Progressing to the next step of enabling global access to that content will require DRM.

There is also evidence of a growing interest in academia for open publishing models, such as the Budapest Open Access Initiative [BOAI]. These new models are emerging in response to escalating commercial journal costs and restrictive publishing practices, which are perceived as disenfranchising the journal authors from their own intellectual property. Open publishing models require new DRM strategies that emphasize fair use, protection of intellectual property from misuse, and multiple subscription models, which include both fee-based and non-fee based access.

Finally, many in R&E consider that commercial DRM solutions tip the balance between the rights owner and the user too much in favor of the rights owner, undermining fair use and the first sale doctrine in the process — two critical and cherished principles in R&E.¹ There is also concern that some DRM implementations compromise the privacy of the user.

Two points are worth noting here. The first is that R&E requirements reveal a distinction between conventional definitions of DRM (the e-commercial model, which functions solely to protect the rights of the owner) and the broader definition emerging in the R&E community. The latter includes access management as well as intellectual property rights management, and is as concerned with the rights of the user as with those of the rights owner. Indeed, given this difference in interpretation, it has been suggested that the term "DRM" has been appropriated by the publishing industry and that the goals of the R&E community in this space would be better served using a different term [GASAWAY]. The second point is that, whether fair use is interpreted as a declarative right or a defense, methods have been proposed to accommodate fair use either in trusted systems [STEFIK] or by means of third-party escrow [BURKE]. The notion, therefore, that an accommodation of fair use is beyond the province of DRM technologies is being challenged.

The VidMid Video-on-Demand Working Group is exploring how far middleware (identity management, authentication, authorization, security and metadata) and the establishment of communities of trust might go towards implementing customized, open and interoperable DRM systems. This focus is the theme of an invitational workshop planned for September 2002; the "NSF Middleware Initiative and DRM Workshop is being funded by the NSF NMI program to bring together content management, copyright law, and middleware experts to explore cooperative DRM development to meet R&E needs. The workshop will be facilitated by the authors, and is supported by the Coalition for Networked Information [CNI], EDUCAUSE [EC], Internet2 [I2], the Southeastern Universities Research Association [SURA], and the Video Development Initiative [VIDE].

An additional and very significant focus for the “NMI and DRM Workshop” is the presentation of a proposal to cooperatively develop a rights metadata core. Equivalent to the Dublin Core for descriptive metadata, the rights core will be cooperatively developed to meet R&E requirements, and will map to existing and future rights languages, as well as interoperating with descriptive metadata schemas. There is a proliferation of rights languages currently, but, for the most part, these support one-to-one e-commercial transactions. A sufficient user base is not yet established to determine whether these languages are flexible and extensible enough for R&E purposes, or whether their use is going to be encumbered by patent claims. The rights core data element set and application schema will be developed by identifying the core DRM needs for R&E, and mapping the data elements required to document and support those needs against existing rights schemas. One of the significant benefits of this process will be the identification of R&E needs that are not currently addressed by existing schemas. The authors expect to propose changes and additions to existing schemas to provide more relevance and utility for R&E among commercial and open source DRM implementations.

A DRM implementation, obviously, entails more than technology. There are complex legal and policy issues implicit in any DRM implementation, as well as a need to support gradations of risk. The FDRM project is a first step for VidMid in testing the hypothesis that it is possible to develop a DRM solution to meet R&E requirements — it does not attempt to address all of these complexities. Our approach to the DRM problem is focused on flexible access management rather than enforcement of rights after the user has legitimately accessed the resource. Our primary goal in this article is to present a reference architecture for FDRM to demonstrate how emerging middleware infrastructure might be leveraged as a foundation and framework for an effective DRM implementation.

FDRM Design Principles

The FDRM project is based on the following design principles and concepts:

1. FDRM is founded on directory services infrastructure and identity management principles currently in use and emerging in Higher Education today.

2. Although interoperable with any authentication and authorization mechanism, FDRM is modeled on the Shibboleth project as described in the Shibboleth Architecture Draft v05 [SHIB ARCHITECTURE].

2.1 FDRM employs existing Shibboleth federated authentication and authorization mechanisms and uses open source protocols, such as the Security Assertions Markup Language [SAML] and the Simple Object Access Protocol [SOAP].

2.2 FDRM is founded on the Shibboleth model for inter-realm trust and establishment of trust communities.

2.3 FDRM shares Shibboleth's core design principle of maintaining privacy of the user.

2.4 Rights and content administration are federated in FDRM in the manner of Shibboleth's federated authentication and authorization model.

3. FDRM is designed to be extensible, include broader access controls in future phases, and to interoperate with commercial mechanisms for rights enforcement.

4. FDRM is designed to interoperate with existing enterprise directories, rights, descriptive and administrative metadata schemas, commercial DRM systems, and user-level Public Key Infrastructure (PKI).

5. FDRM is designed to scale for campus/enterprise implementations.

6. FDRM is designed to support secure messaging, maintain integrity of content, protect intellectual property, and ensure the integrity of rights and descriptive metadata.

7. FDRM uses open standards and protocols. New code or standards developed will be placed in the public domain.

8. FDRM is designed to be applicable to all media types, formats and standards.

Why Shibboleth?

FDRM is designed for use with any authentication and authorization² system, be it simple .htaccess files, Windows Domain Authentication [WDA], or LDAP authentication modules [LDAP]. The architecture presented here is modeled on the Internet2 Shibboleth project [SHIB]. The Shibboleth model and architecture make a compelling foundation on which to build FDRM, since it is designed for federated application, built on open source XML-based messaging standards and open source directories, and is extensible, as our proposed reference architecture demonstrates. Shibboleth is also predicated on the establishment of trust communities. Most significantly, Shibboleth's emphasis on user privacy is one that is wholly shared by FDRM. This emphasis will mark a significant distinction between the FDRM solution and some current commercial DRM systems. The ability to track usage, protect the integrity of a resource, and manage version control is possible in FDRM, without compromising the privacy of the individual. In addition to applying the federated authentication and authorization mechanisms of Shibboleth, FDRM federates asset management.

The Shibboleth Architecture

The following extract is from the Shibboleth-Architecture Draft v.05 [SHIB EXTRACT]. (A glossary of Shibboleth and FDRM terms is provided at the end of this document).

In Shibboleth, when a user at a browser attempts to access a resource at a destination site, the "Shibbolized" web server will 'notice' that it doesn't have attributes about the user. The part of the web server that obtains and caches attributes is called the "Shibboleth Attribute Requester" or SHAR (rhymes with 'tar') for short.

The SHAR will then interact with the Attribute Authority (AA) at the origin site to get attributes about the user. The AA may store attributes directly, or more likely will obtain them from the institution's LDAP directory or other institutional database. Shibboleth doesn't specify how the AA stores or acquires user attributes. That is up to each origin site to decide on and implement. The AA must additionally have access to the user's "attribute release policy" for the destination site, in order to decide what attributes to send back to the SHAR. Again, Shibboleth doesn't specify how attribute release policies are stored and managed.

We call the attribute request that the SHAR sends to the AA an "AQM" for "attribute query message". The response that the AA sends to the SHAR is an "ARM" for "attribute response message".

The SHAR, once it has these attributes, will send them on to the manager of the resource the user is trying to access. The resource manager (RM) will then make an access control decision based on the user's attributes, and either grant or deny the user's request. If the user is simply trying to access a static web page or a typical application, this RM may be the web server itself. In the case where the user is attempting a more complex action (say updating experimental results or transferring grant money), the RM may sit "behind" the web server on a separate machine.

The FDRM Architecture

FDRM will extend the Shibboleth architecture with the following four components:

1. Resource Attribute Authority (RAA)

Function: A database of metadata containing rights records with rights, permissions and constraints associated with a digital resources.

Implementation: An RDBMS/object-oriented database to store the rights records. The rights records are written in an XML-based rights language.

2. Shibboleth Object Attribute Resolver (SHOAR)

Function: A component that interacts with the RAA in order to obtain the rights metadata associated with the requested resource.

Implementation: A module on a "Shibbolized" web server initially implemented in CGI for prototyping, then as an Apache module or in Java. The query and response messages will be implemented according to SAML specifications.

3. Packaging/License Service (P/LS)

Function: A fundamental component of a DRM architecture, the P/LS dynamically packages content for delivery. The licensing function of the P/LS entails specification of the rights the user is allowed to exercise on the content (e.g., play, annotate, edit, transfer, etc.).

Implementation: A dynamic content delivery system, such as Java Server Pages [JSP] or PHP [PHP].

4. Resource Manager (RM)

Function: The RM resolves the user's attributes with the resource attributes (rights, permissions and constraints), and forwards the details of the package request to the P/LS. The RM is the equivalent of a DRM Controller in a commercial DRM model.

Implementation: A module on an HTTP server, which could be implemented in CGI for prototyping, and, ultimately, as an Apache module or in Java.

The following diagrams illustrate the sequence of events and message flows that occur when a user accesses an FDRM managed resource. Figure 1 and Figure 2 represent the existing Shibboleth components; Figure 3 and Figure 4 FDRM components.

Figure 1: Authentication

1. A user in an origin site launches a web browser and selects a URL to access a managed resource from a HTTP server.

2. The Shibboleth Indexical Resource Establisher (SHIRE) receives the user's request and sends the location of the requested resource and the SHIRE's URL to an off-site "Where Are You From?" (WAYF) server.

3. The WAYF server establishes a connection with the requesting user and the Handle Service³ responsible for the origin site.
1. The user authenticates with the origin site, as required, and the authentication service at the origin site returns an affirmation to the Handle Service.
2. The Handle Service and Attribute Authority (AA) agree on an opaque handle for the user.

4. The local Handle Service returns the handle package to the SHIRE. The handle package includes the opaque handle and the address of the user's local AA (UAA) server.

Figure 2: Authorization

5. The SHIRE then passes the received handle package to the Shibboleth Attribute Requester (SHAR).

6. The SHAR constructs an Attribute Query Message (AQM) and submits it to the UAA defined in the handle package. The AQM includes the opaque handle, the target URL and the SHAR name.

7. The UAA responds to the AQM with an Attribute Response Message (ARM), which includes the SHAR name, target URL and the user attributes as allowed by the user's Attribute Release Policy (ARP).

Figure 3: Asset Management

8. The SHAR passes the results of the ARM to the Shibboleth Object Attribute Resolver (SHOAR).

9. The SHOAR constructs a Resource Attribute Query (RAQ) and submits it to the Resource Attribute Authority (RAA) associated with the requested resource. (The URL that the user first accesses contains the location of the RAA, as well as the specific requested resource.)

10. The RAA returns a Resource Attribute Response (RAR) to the SHOAR detailing the supporting services and access rights associated with the requested resource.

Figure 4: Content Packaging and Delivery

11. Depending on the assertions received from the UAA and the RAA, the SHOAR sends a package request to the Resource Manager (RM).

12. The RM forwards the package request to the Packaging and License Service (P/LS).

13. The P/LS creates the requested package and sends it back to the RM.

14. The RM passes the requested resource to the user.

The following are key considerations in further development of this architecture, or in an FDRM implementation:

1. Meeting R&E requirements: How well does FDRM meet R&E requirements for rights and access management? Will it integrate with existing middleware and other applications?

2. Location of the Policy Decision Point (PDP): In the architecture presented here, there are at least two PDPs. One PDP is located at the Resource Manager, which makes a policy decision to either grant or deny access to the requested object. Another PDP occurs at the User Attribute Authority, which makes a policy decision based on the user's Attribute Release Policy. Are these the optimal locations for the PDPs?

3. Security: The SAML assertions used in FDRM are digitally signed. However, more robust security implementations exist and will be required for the interaction between all of the FDRM components. Would content security be enhanced if it were based on the Secure Sockets Layer (SSL), an internal key system, or dependent upon existing organizational PKI?

4. Rights enforcement: In the current architecture, the Packaging/Licensing Service is responsible for encrypting the content package delivered to the requesting user. What other control mechanisms can be integrated into this architecture (e.g., digital signatures or watermarks)?

5. Trust requirements: If FDRM were to be implemented with Shibboleth, would the Shibboleth trust model satisfy DRM trust requirements too? What are the additional FDRM trust requirements?

6. Implications for directory development: Many DRM implementations utilize White Pages directories to provide authentication facilities. However, it is likely that more utility would be achieved by defining DRM roles and responsibilities within directory object classes in order to facilitate management from both the user and content owner/distributor perspectives. What are those object classes likely to be? How might the eduPerson and eduOrg classes support right management roles [EDU]?

7. Payment: How will FDRM support applications where payment for access or services is required? Can the Resource Manager support that function?

8. Policies: What policies need to be considered in the FDRM design? What policy implications does the current design have?

9. Nomenclature: If FDRM is implemented as a Shibboleth module, how can the new DRM components be named so as to distinguish them from existing components (e.g., User Attribute Authority vs. Resource Attribute Authority) and to make their functions explicit?

10. Rights and policy languages: How might emerging policy languages, such as the OASIS eXtensible Access Control Markup Language [XACML] function within this architecture and with a rights expression language? Would existing rights expression languages integrate with FDRM?

Conclusion

DRM represents a fundamental agreement between the content creator and the content user. Development of a successful DRM model to meet R&E needs requires the active engagement of the R&E community — content creators, publishers/distributors, repositories and content users. FDRM is designed to be extensible to a wide range of content management and access requirements so that DRM can be an enabling middleware that promotes emerging publishing and intelligent object repository models.

R&E is currently faced with a formidable challenge — protecting intellectual property and the integrity of content, while at the same time enabling the flexible access required to advance its agenda, and realize the rich potential of networked collaboration. In response to this challenge, FDRM builds on existing technologies and standards with the aim of enabling institutions to manage their local content and make that content globally accessible. In the manner of the Shibboleth model, FDRM uses federated administration of access control mechanisms and the establishment of communities of trust.

The next steps for the FDRM project team include refinement of the architecture according to needs identified by the R&E community through the invitational workshop, culminating in the development of a prototype of the FDRM system for proof-of-concept. The authors very much welcome feedback on the principles and architecture presented in this article.

Acknowledgements

The authors would like to acknowledge the assistance of the Internet2 Middleware Architecture Committee for Education (MACE) Working Group in providing feedback on the FDRM reference architecture. We are grateful to Michael West, Graduate Assistant, Advanced Internet Technologies at The University of Tennessee for his assistance in preparing this article, to Dan Lipe for design of the FDRM architectural diagrams, and to Jeanne Boyle, Associate University Librarian for Public Services and Communications at Rutgers, The State University of New Jersey, for her assistance with copyright law concepts and terminology.

Notes

[1] Fair Use is an important legal exception enabling a user to make "reasonable" use of a copyrighted work without requesting permission. What amounts to reasonable use is determined by the four factors outlined in Section 107 of the Copyright Act of 1976: the purpose or character of the use (commercial vs. nonprofit educational use, for example), the nature of the copyrighted work, the amount of the work used, and the effect of the use on the market for the work. Section 109 of the Copyright Act of 1976 permits the purchaser of a copy of a copyrighted work to lend, sell, or otherwise dispose of that copy without requiring authorization from the copyright owner. This is often referred to as the "First Sale Doctrine" — a principle upon which libraries and other entities that lend or lease works depend. Both fair use and the first sale doctrine are threatened by the restrictive access controls of conventional DRM technologies, which are protected by the Digital Millennium Copyright Act of 1998.

[2]Authentication is the process by which a user provides credentials to a server, such as a username or password, to verify identification. Authorization is the process of determining what the user is permitted to do or permitted to access based on the attributes.

[3] Note that the Shibboleth Handle Service differs from the Corporation for National Research Initiatives' Handle System™, a system for persistent identification of digital objects or other resources on the Internet. The function of the Shibboleth Handle Service is to create a "handle", or alias, for a user, as well as ensure that the user has authenticated locally.

* Edtior's Note: This article is being made available by D-Lib Magazine in the interest of public dissemination of the information contained therein. However, we wish to inform readers that the article, and, in particular, the Shibboleth architecture referred to in the article, raises several legal questions in the context of CNRI's Digital Object Architecture, and, in particular, the Handle System, which is a registered trademark of CNRI for similar services. This matter is currently being addressed by CNRI and is being brought to the attention of the relevant parties for discussion and resolution.

References

[BOAI] Budapest Open Access Initiative (Home Page). Accessed May 2002. <http://www.soros.org/openaccess/>.

[CNI] The Coalition for Networked Information (Home Page). Accessed May 2002. <http://www.cni.org>.

[EC] EDUCAUSE (Home Page). Accessed May 2002. <http://www.educause.edu>.

[EDU] eduPerson Object Class (Home Page). Accessed May 2002. <http://www.educause.edu/eduperson/>.

[I2] Internet2 (Home Page). Accessed May 2002. <http://www.internet2.edu>.

[I2MID] Internet2 Middleware Initiative (Home Page). Accessed May 2002. <http://middleware.internet2.edu/>.

[JSP] Java Server Pages. Accessed May 2002.<http://java.sun.com/products/jsp/>.

[LDAP] Lightweight Directory Access Protocol (v.3). Accessed May 2002. <http://www.ietf.org/html.charters/ldapbis-charter.html>.

[NMI] The NSF Middleware Initiative (Home Page). Accessed May 2002. <http://www.nsf-middleware.org/>.

[PHP] PHP. Accessed May 2002.<http://www.php.net/>.

[SAML] OASIS Security Assertion Markup Language Technical Committee (Home Page). Accessed May 2002. <http://www.oasis-open.org/committees/security>.

[SHIB] The Internet2 Shibboleth Project (Home Page). Accessed May 2002. <http://middleware.internet2.edu/shibboleth/>.

[SHIB ARCHITECTURE] Cantor, Scott and Erdos, Marlena. Shibboleth-Architecture DRAFT v05. May 2, 2002. Accessed May 2002. <http://middleware.internet2.edu/shibboleth/docs/draft-internet2-shibboleth-arch-v05.pdf>.

[SHIB EXTRACT]: Cantor, Scott and Erdos, Marlena. Shibboleth-Architecture DRAFT v05. May 2, 2002: Section3.1: "Slightly Simplified Architecture". Accessed May 2002. <http://middleware.internet2.edu/shibboleth/docs/draft-internet2-shibboleth-arch-v05.pdf>.

[SOAP] W3C XML Protocol Working Group (Home Page). Accessed May 2002. <http://www.w3.org/2000/xp/Group/>.

[SURA] The Southeastern Universities Research Association (Home Page). Accessed May 2002. <http://www.sura.org>.

[VIDMID] VidMid, the video working group of the Internet2 Middleware Initiative (Home Page). Accessed May 2002. <http://middleware.internet2.edu/video>.

[VIDE] The Video Development Initiative (Home Page). Accessed May 2002. <http://www.vide.net>.

[WDA] Windows Domain Authentication. Accessed May 2002. <http://support.microsoft.com/default.aspx?scid=kb;EN-US;q102716>.

[XACML] OASIS eXtensible Access Control Markup Language Technical Committee (Home Page). Accessed May 2002. <http://www.oasis-open.org/committees/xacml/>.

Glossary of Shibboleth and FDRM Terms

Attribute Authority (AA) - The service responsible for the release of information about the user to the Shibboleth Attribute Requester. The AA is located within the user's administrative domain and grants the user control over the release of their attributes.

Attribute Query Message (AQM) - An information packet transmitted from the Shibboleth Attribute Requester to the user's Attribute Authority requesting attributes about the user.

Attribute Release Policy (ARP) - A set of rules, established and controlled by the user, that resides in the user's administrative domain and governs which attributes will be available to the Shibboleth Attribute Requestor in order to grant access to a requested resource.

Attribute Response Message (ARM) - An information packet transmitted from the user's Attribute Authority to the Shibboleth Attribute Requester in response to the Attribute Query Message. The ARM provides attributes about the user subject to the restrictions of the Attribute Release Policy.

Authentication Service (AS) - The service responsible for the verification of a user's credentials, usually a query in the form of a password or ID.

Packaging/License Service (P/LS) - The server responsible for the dynamic assembly and licensing of content for delivery to the requesting user. The licensing element of the P/LS entails specification of the rights the user is allowed to exercise on the content (e.g., play, annotate, edit, transfer, etc.).

Resource Attribute Authority (RAA) - A database of metadata containing rights records with rights, permissions and constraints associated with digital resources.

Resource Attribute Query (RAQ) - An information packet transmitted from the Shibboleth Object Attribute Resolver to the Resource Attribute Authority requesting attributes about the requested resource.

Resource Attribute Response (RAR) - An information packet transmitted from the Resource Attribute Authority to the Shibboleth Object Attribute Resolver in response to the Resource Attribute Query.

Resource Manager (RM) - The service that evaluates user and resource attributes to make the access control decision to grant or deny the request to access a resource.

Security Assertion Markup Language (SAML) - An emerging standard from the Organization for the advancement of Structured Information Standards (OASIS) for the secure exchange of authentication and authorization information using XML.

Shibboleth Attribute Requester (SHAR) - The component responsible for obtaining and caching attributes about the user. The SHAR acquires this information by sending an Attribute Query Message to the user’s local Attribute Authority and receiving an Attribute Response Message in reply.

Handle Service - The Shibboleth service responsible for confirming that the user has authenticated at the user's local Authentication Service. This service also creates an opaque alias, or handle, by which attributes can be associated with the user while protecting the user's identity. Note that the Shibboleth Handle Service is not the same as the Corporation for National Research Initiatives' Handle System™, a system for persistent identification of digital objects or other resources on the Internet.

Shibboleth Indexical Referencer (SHIRE) - The component responsible for determining the location of the user's Handle Service. The SHIRE contacts the Handle Service to obtain an "indexical reference", or handle, that can be used to request attributes about the user.

Shibboleth Object Attribute Resolver (SHOAR) - A Federated Digital Rights Management (FDRM) component that interacts with the Resource Attribute Authority in order to obtain the rights metadata associated with the requested resource.

Where Are You From (WAYF) - A Shibboleth component or service that can be used to assist the Shibboleth Indexical Referencer locate the user's handle service and request that a handle be passed back to it. A WAYF service would have a list of institutions participating in the Shibboleth group and the location of each handle service.

Top | Contents
Search | Author Index | Title Index | Back Issues
Previous Article | Next Article
Home | E-mail the Editor

D-Lib Magazine Access Terms and Conditions

DOI: 10.1045/july2002-martin