Apr 14, 2004
Stephen Downes, Gilbert Babin, Luc Belliveau, Raphael Blanchard, Gerard Levy, Pierre Bernard, Gilbert Paquette, Sylvie Plourde
Abstract
This paper describes the design and implementation of the distributed digital rights management (DDRM) system as undertaken by the eduSource project, a national network of learning object repositories built by a consortium of universities and other agencies in Canada. DDRM is foremost a system of rights expression, with transactions managed by a set of brokers acting on behalf of purchasers and providers. Rights are described using ODRL, contained in files managed by the provider broker, and accessed by means of pointers in the learning object metadata exchanged within the eduSource network.
1. eduSource
The eduSource project is a network of Canadian learning object repositories providing access to all Canadian educational institutions to a broad array of educational resources. Funded by by the contributions of project partners (more than 30 universities, agencies, and businesses across Canada) and by CANARIE, Canada's Advanced Internet Development Organization, the intent of eduSource is to "create a testbed of linked and interoperable learning object repositories." (McGreal, et.al., 2003) The development of eduSource involves not only the design of a suit of software applications, referred in project documentation as the Repository in a Box (RiB), it is also intended support the ongoing development of standards based tools, systems, practices and protocols necessary for a national learning infrastructure.
eduSource is based in part on three prior CANARIE funded initiatives: Explor@, "a software environment for the delivery of courses or distance learning events" (Technologies Cogigraph 2003), POOL (Portal for Online Objects in learning), a peer to peer learning object distribution network (eduSplash, 2003), and CanLOM, a learning object metadata repository. (CanLOM, 2003) Added to these were CAREO (Campus Alberta Repository of Educational Objects), a learning object metadata repository (CAREO, 2003), institutional services provided by Athabasca University, and a variety of smaller initiatives.
The eduSource project team identified four major goals:
- To promote and refine a repository metadata framework through the ongoing development of the CanCore protocol;
- To support experimental research in key areas such as pedagogy, accessibility, protocols, network engineering, hardware integration, quality of service, security, rights management, content development and software applications;
- To implement a national testbed to investigate processes such as peer review, content repurposing, user support, professional development and content transactions; and
- To communicate and disseminate its findings through cooperation and partnership with other federal and provincial agencies, institutions and the private sector. (McGreal, et.al., 2003)
Work on the eduSource project began in the summer of 2002. As of this writing, eduSource is projected for launch at the end of March, 2004.
2. eduSource Vision
The eduSource Digital Rights Management initiative has its origins in the eduSource vision. Making eduSource unique was not only its distributed nature, it being an attempt to link a geographically dispersed set of online resources and services, but also the diverse and sometimes conflicting points of view characterizing member initiatives at the outset. For example, while POOL is fundamentally a peer to peer system, similar in many ways to products such as Napster, Explor@ was a relatively traditional learning management system and CAREO a centralized metadata repository.
Moreover, as additional projects came into the fold, a wider array of points of view was added. With the addition of business partners came a desire to see implemented a digital rights management solution, and as a consequence this was incorporated into the original approach. Through the duration of the project, the emergence of such projects as the Open Archives Initiative (OAI) and Rich Site Summary (RSS) added yet another content distribution model for members to consider.
At the crux of many of these different visions lay digital rights management, and accordingly, Canada's National Research Council e-Learning group, as the DRM package manager for eduSource, initiated a 'Vision Committee' to draft broad
meters for the eduSource project. After wide consultation, the Vision Committee produced the following statement as part of its overall document: (Downes, et.al., 2002)
eduSource is to be designed not as a single software application, but rather, as a set of related components, each of which fulfills a specific function in the network as a whole. This enables users of eduSource to employ only those tools or services that suit their need, without requiring that they invest in the entire system. It also allows for distributed functionality; an eduSource user may rely on a third party to provide services to users. The purpose of this principle is to allow for specialization. Additionally, it allows eduSource users to exercise choice in any of a variety of models and configurations.
Any given software tool provided by eduSource may be replicated and offered as an independent service. Thus, it is anticipated that there will be multiple instances of each type of repository in the network. The purpose of this principle is to provide robustness. Additionally, it is to ensure that no single service provider or software developer may exercise control over the network by creating a bottleneck through which all activities must pass.
In order to realize this objective, the vision committee also endorsed the principle of open standards and open source. Accordingly, they wrote: (Downes, et.al., 2002)
EduSource repositories will use Open Rights Management standards and protocols. The purpose of this is to ensure that there is no a priori overhead cost incurred by agencies wishing to offer services compatible with eduSource. Imposing an a priori cost immediately poses a barrier to small and medium sized enterprises that may wish to participate and it biases the network toward the provision of commercial content only.
This vision was endorsed by the eduSource Steering Committee, which in turn resolved to license all software under the Lesser GNU Public License (LGPL, 1999) and to endorse the use of Open Digital Rights Language (Ianella, 2002) to express digital rights in the eduSource project.
3. DRM Vision
In addition to statements about the design of eduSource as a whole, the Vision Committee defined specific
meters for the development of eduSource Digital Rights Management: (Downes, et.al., 2002)
Any provider of learning materials may prepare and distribute learning materials through the eduSource repository network. eduSource will support the registration and indexing of various providers, this registration will be free and optional. The purpose of this principle is to ensure that providers are not faced with a priori `membership fees' or similar tariffs in order to gain access to potential purchasers. This does not preclude restrictions, tariffs or controls on specific instances of an eduSource-compliant repository. However, in any case where a restricted component, such as a for-profit metadata repository, exists, an equivalent unrestricted component, such as a public metadata repository, will also exist.
There will be no prior restraint imposed on the distribution model selected by participants in eduSource. Specifically, eduSource will accommodate free content distribution, co-op or shared content distribution, and commercial fee-based content distribution. The purpose of this principle is to ensure fair and open competition between different types of business models, to ensure that users are not `locked in' to the offerings provided by certain vendors, to provide the widest possible range of content options, and to ensure that prices charged for learning content most accurately reflect the true market value of that content.
Multiple parties may provide metadata describing a given learning resource. There is no prior restraint exercised by providers of learning materials on evaluations, appraisals, comments and other descriptions of their learning material. The purpose of third party metadata may be to provide alternative classification schemes, to indicate certification compliance, or to provide independent assessments and evaluations of learning resources. The purpose of this principle is to ensure that potential users of learning resources can obtain and input multiple descriptions of that material. It is also to create an environment for the creation of optional but value-added third party services for which fees or other costs may be charged.
eduSource should be considered as an implementation of and an extension of the semantic web. This means that metadata and services provided by eduSource repositories should be available to the semantic web as a whole. It also means that eduSource repositories and tools can and should incorporate elements of the semantic web, such as sector-specific ontologies, into its own design. The purpose of this principle is to ensure that eduSource is capable of the widest reach possible. It is also to reduce the duplication of effort between developers working in specific domains and educators working in the same domain.
The principle behind fee-based and subscription-based transactions is that it should be easier to buy material than to steal it. Thus where possible, the acquisition of rights and the exchange of funds will be automated. The purpose of this principle is to reduce transaction and clearance costs for purchasers of learning materials.
In addition, the structure of DRM within the network should be such as to allow for multiple digital rights models. For example, it should be possible for a government or agency to distribute free materials, for a college association to establish a cooperative system for sharing, and for a commercial provider to sell content on a per-view or subscription based model. Individual learners should have the option to access and, if necessary, purchase materials directly, or they should be able to obtain access to materials through their school board, provincial learning ministry, or employer.
Thus there is no single rights agency governing all transactions. A given provider of learning materials will work with one of many brokers who sell to multiple purchasers, and a given user may one of many agents who conduct transactions with multiple vendors. Vendors and users may select from any number of brokering services, so that no single transaction agent controls the network. Vendors and purchasers may act as their own brokers. A vendor or purchaser may elect to employ multiple brokers. Brokers acting on behalf of, say, a provincial department of education, may represent a given populations, such as the students of that province. The purpose of this provision is to eliminate the need for the creation of multiple accounts, to allow users to user resources from multiple vendors, and to provide a choice of brokers, and therefore a greater likelihood of trust.
In addition to describing digital rights on behalf of content providers, the network should assert individual rights and preferences on behalf of users. Users of the system own their own personal data. Brokers within the network may operate on behalf of the user, and releases information or money only with the agent's explicit consent. The purpose of this principle is to engender trust in the system and to ensure privacy when dealing with multiple agencies.
4. DRM in eduSource Use Cases
The eduSource architecture development process employed a standard methodology, preceding from the vision document, though a set of use cases, and the creation of a UML diagram describing the overall system. The Digital Rights Management package participated in this part of the development.
Use cases provided by the DRM package described typical procedures whereby a person (using IMS DRI terminology, an 'infoseeker') would search for, select, and ultimately purchase an online learning resource through eduSource.
Figure 1. eduSource Use Case Diagram - Overview. Paquet, et.al., 2003
In figure 1, several features of the DRM system to be described below are evident. Digital rights functionalities are provided by two major actors within the eduSource system, the 'purchaser broker' and the 'provider broker' (sometimes documented as the 'vendor broker'). Financial transaction between the two brokers are managed by an external payment agency, such as PayPal or a credit card transactions company. The purchaser broker, in turn, interacts with the LO Searcher (infoseeker), while the provider broker interacts with the provider. This process is displayed in more detail in figure 2.
Figure 2. eduSource Use Case Diagram - Digital Rights Management. Paquette, et.al., 2003
As this expanded diagram shows, the provider (or 'publisher') works with the provider broker to create or select a 'rights model'. Information about this rights model is then embedded in learning object metadata. When a searcher retrieves the learning object metadata, he or she may then locate the rights model, which is provided on request by the provider broker. If specified by the rights model, a payment is made for use of the object, via the purchaser broker, and access to the learning object is granted, which is then returned to the infoseeker.
The process of assigning and employing rights is included in the overall eduSource process diagram:
Figure 3. eduSource Process Model - Digital Rights Management. Paquet, et.al., 2003
The process diagram in figure 3 is more explicit about the payment and delivery mechanism. What should be noted is that the payment is made, not directly to the provider or even to the provider broker, but rather, to the purchaser broker. The purchaser broker then notifies the vendor broker of the payment, which in turn returns a key that provides access to the learning object.
5. Explanation of the Use Cases
The digital rights model proposed in the use cases introduces some major new features to online digital rights management. First, it introduces the idea of the purchaser broker, in addition to a vendor broker (which, under various names, may be found in other systems, such as the Microsoft Rights Management Server). Second, instead of embedding digital rights metadata in an object or object metadata, it stores only a pointer to that metadata. These are depicted in figure 4.
Figure 4. Distributed Digital Rights Management Model. Downes, 2004
The purpose of these features is to instantiate some of the requirements set out in the vision statement. In the vision statement, for example, it was proposed that eduSource be designed not as a single software application, but rather, as a set of related components. Thus, the various functions required of a digital rights system are displayed in the use cases as se
te actors. This proposal was adopted by the eduSource Vision Committee in order to ensure that there are no sole-source components of the system. Any given function performed by eduSource may be provided by any number of providers.
In practical terms, what this means is that, in eduSource, there is not only one vendor broker; there can be many, each vendor broker representing one or more vendors. In a similar manner, there is not only one purchaser broker, there may be many. This allows both vendors and purchasers to choose the entity that will provide digital rights management services. No vendor can lock in a purchaser to a given rights management service, and no purchaser can require than a vendor employ a given rights management service.
The division of the eduSource model into se
te actors also allows some actors to be bypassed if they are not needed. This performs a critical function for eduSource: it allows for the distribution of both free and commercial content in the same system. Because the digital rights management component, and in particular, the lock and key mechanism, is not an essential part of any eduSource service, it can be bypassed if not needed. Thus, even though free content is distributed through the same network as commercial content, it is not encumbered by the needs of a locking and payment system.
The addition of a purchaser broker into the system, in addition to protecting a purchaser's privacy and security, allows eduSource to "make it easier to buy than to steal." The price of learning resources, and particularly small items such as images, may be very low. Transactions involving such small amounts of money are called 'micropayments'. A major objection to micropayments is that the effort required to make a payment is greater than the payment is worth. There are financial transaction costs, and also what Szabi (1996) calls "mental transaction costs," the hesitation a user experiences when deciding to pay a minute amount for a learning resources.
Typically, the purchase of an inexpensive item occurs as a part of a purchase of a larger item. This practice, known as 'bundling', typifies most online content sales. Corbis, for example, sells not a single image but access to an image library. Elsevier sells access not to a single journal article but to a journal library. However, this approach creates barriers for both content providers and content consumers. Content providers must assemble and market bundles of content, usually through a publisher, before they can enter the marketplace. Moreover, free content is not bundled (since there is no need) and may be excluded from the set of available content. And users, when accessing content through a bundle, are able to search and use only resources provided by the vendor of a particular bundle.
The eduSource digital rights management system addresses these problems by bundling, not content, but financial transactions. Through the use of vendor and purchaser brokers, many small transactions from different vendors may be lumped into a single payment. A purchaser, therefore, may opt to use only one purchaser broker, making a single monthly payment, and even pre-authorize transactions under a certain amount. A vendor, in turn, may work with a single vendor broker, receiving (and managing) only a single monthly payment, no matter how may purchasers are supplied.
Figure 5. Distributed Digital Rights Management Analogy. Downes, 2004
Though new to online management of digital rights, the use of vendor and purchaser brokers is widespread in other commercial communities, as the analogy shown in figure 5 suggests. Vendors typically employ wholesalers to distribute their products. And purchasers typically access goods from a wide variety of marketers through their local store. It is rare, indeed, that a purchaser pays a provider directly for a good or service.
Finally, the use of a rights model, rather than an embedded description of rights, was necessitated by the commitment to a distributed system. Once metadata is released by content providers, it is beyond their reach. Thus, once an offer is made, through the provision of rights metadata, it cannot be rescinded or amended. This makes it difficult for vendors to adjust the prices of their products to react to changing consumer demand, timeliness of the information, or changing economic needs. By maintaining the rights metadata in a se
te environment, one that is within the vendors control, the terms for the use of an object may be changed at any time up to the point of purchase. Additionally, the use of rights models allows one model to be applied to many objects, greatly simplifying the creation and maintenance of rights metadata for the vendor.
6. The eduSource Architecture
In order to enable a distributed network of object repositories involving many different search and distribution models, the eduSource architecture was designed around a set of commonly available web services. At the heart of these services is the Edusource Communications Layer (ECL). Instances of particular eduSource components, such as a repository or search service, are expressed to the network as a whole through eduSource registries. Common tasks, such as providing object identifiers, are provided by the same means.
Figure 6. eduSource General Functional Diagram. Cogigraph Technologies, 2002
In the eduSource architecture, the digital rights management system is one of five major software packages; the others are the ECL communications kernel, e-learning middleware, metadata repository services, and resource management services. Since any function from any service must be available to all eduSource instances, communication and data transfer is handled through the use of web services. Thus the eduSource architecture committed the digital rights management system to providing a certain set of web services.
The eduSource architecture defines a 'broker' as "A software agent representing a person that wants to publish a new Learning Object to a metadata repository or to modify rights metadata of an existing LO. The Provider Broker presents a set of rights metadata models to the Provider. Each model includes secondary metadata that specify conditions, for example a certain form of payment that must be fulfilled in order to gain access to the object. The Provider selects a model and fill out specific conditions that are associated by the Provide Broker to the LO to be integrated by the Repository Builder."
In particular, a 'provider broker' is "A software agent representing a person that wants to publish a new Learning Object to a metadata repository or to modify rights metadata of an existing LO. The Provider Broker presents a set of rights metadata models to the Provider. Each model includes secondary metadata that specify conditions, for example a certain form of payment that must be fulfilled in order to gain access to the object. The Provider selects a model and fill out specific conditions that are associated by the Provide Broker to the LO to be integrated by the Repository Builder." And a 'purchaser broker' is "A software agent acting on behalf of a person that want to buy access to an object, obtains rights metadata and asks the purchaser (a utilizer) for payments prescribed in the rights metadata. It sends any required payment to an External Payment System," where an 'external payment system' is a "A computerized system that receives payment from a infoseeker or its Purchaser Broker in a DRM system. It informs the Provider of the learning object so that it can send a credential (a key) to the infoseeker." (Paquette, et.al., 2003a)
7. eduSource DRM Architecture
Based on the eduSource architecture and use cases, eduSource DRM functionality was expressed in greater detail through a set of DRM use cases. For example, figure 7 describes the requests that an LCMS must be able to make of the eduSource DRM system.
Figure 7. Request Digital Rights Information. Babin, et.al., 2003
Use cased were incorporated into the overall architecture of the DRM system. This architecture first captured in a sequence diagram to describe the steps of the DRM process (figure 8). An system data flow architecture was employed to specify more precisely the communications requirements between the various systems (figure 9). It describes the two brokers along with the end user, learning object repository and external broker system.
Figure 8. Digital Rights Management Sequence Diagram. Babin and Downes, 2003
The Sequence Diagram provides a preliminary understanding of how the digital rights will flow within a network.
- A Learning Resource Provider sets up an account with a Vendor System.
- The Vendor System generates a username and a password for each Learning Resource Provider.
- After logging into the Vendor System, the Learning Resource Provider is presented with an ODRL Wizard which can be used to express rights in a XML format.
- The generated ODRL File is stored on the Vendor Broker System and a REF# to the record is generated.
- Based on the requirements expressed in the ODRL file a Composite Key is generated.
- The REF# and in some cases a KEY are returned to the Learning Resource Provider.
- The Learning Resource Provider then associates the REF# to an object in a Learning Object Repository.
- The Learning Resource Provider also associates a KEY to an object in a Learning Object Repository.
- The REF# is be added to the LOM Metadata and the LOM is be stored in the Learning Object Repository.
- The metadata containing the REF# is harvested by some harvesters.
- The harvester stores the metadata containing a pointer to the ODRL file in its database.
- An object consumer searches for Learning Objects via a search agent.
- The search results contain MetaData, of which one element is a pointer to the ODRL file
- In some cases the Learning Object Consumer or his client software requests the Digital Rights information .
- The Vendor Broker System sends out the ODRL file for reading.
- If a key is required (that is, there is some cost or condition of access expressed in the ODRL) the Learning Object Consumer asks the Purchaser broker for a key.
- The Purchaser Broker asks the vendor broker for the purchasing information and compares this to the consumer's profile file.
- The Purchaser Broker receives the information and acts accordingly, either acting automatically or requesting confirmation from the consumer.
- If necessary money will be requested from an external payment system.
- The Purchaser Broker receives the money. Because of the small amounts the Purchaser Broker may deduct from an account rather than conducting a transaction with an external system every time a learning object is requested.
- The Purchaser Broker then contacts the Vendor Broker System to buy the key.
- The Vendor Broker request permission to withdraw from the purchaser broker's account.
- The Vendor Broker receives OK to withdraw
- The Vendor Broker requests money from external system. Again this may be done on an account basis if transaction costs exceed object costs.
- The Vendor Broker receives money from the external system.
- The Vendor Broker sends the key to the Purchaser Broker.
- The key is forwarded to the object consumer (the one who did the search)
- The object consumer presents a request for an object + the proper key to the LOR
- The LOR validates the key and returns the object
Figure 9. System Data Flow Architecture Diagram. Babin and Downes, 2003
The DRM System works in conjunction with other Systems such Search Agents, LORs, Harvesters, External Payment Systems. Keep in mind that this system is designed for a near future where there will be many low cost or free objects available with most transactions happening transparently at a machine level. A learning resource provider (LRP) wishing to sell objects (LO) sets up an account on the Vendor System. The Learning Resource Provider uses a wizard to create an ODRL XML rights description file which is going to be stored on the Vendor System. The ODRL file is parsed and a key token is created for every ODRL item requiring a key. The key tokens are aggregated into a composite key. The ODRL file and key are stored the Vendor System Database generating a REF# id. The Learning Resource Provider receives the REF# and the Composite Key.
To transform a LO into a Rights Enabled Learning Object (RELO) the Learning Resource Provider will associate the REF#/Composite Key to one or more of the Learning Object Repository (LOR) Learning Objects. The Harvester plays an important role in this model. As LOR get harvested the REF# become visible to end users thereby making it possible to access the ODRL files from the Vendor Broker System. A Rights Enabled Learning Object Repository (RELO) will be able to process keys and release info upon presentation of a proper key. The REF# will be exposed to harvesters but the composite key will not.
8. Provider Broker Web Interface
The Provider Broker providers a web interface where resource vendors may manage their account. The Provider Broker demonstration is available at http://drm.elg.ca/ProviderBrokerSystem/ProviderBrokerSystemLRP
The following figures demonstrate Provider Broker functionality. Figure 10 displays the account management screen and the list of functions available in the eduSource Provider Broker: Manage Account, ODRL Wizard, Manage ODRL Files, Search Report, Manage Purchasing Agent Accounts, Manage Provider Accounts, Invoices, and Monthly Cheques.
Figure 10. eduSource Provider Broker Manage Accounts.
In order to create an ODRL model, a provider accesses the ODRL wizard. This program is available at http://drm.elg.ca/english/ODRLGenerator
The ODRL wizard allows the user to create a rights model automatically, by selecting one of several preset options, as demonstrated in Figure 11.
Figure 11. eduSource Provider Broker ODRL Wizard Preset Options.
Additionally, the wizard allows a vendor to customize the present options or generate a new offer or agreement from scratch by selecting from the web based form. A partial screen shot is shown in figure 12.
Figure 12. eduSource Provider Broker ODRL Wizard Modify Options.
When the user desires, the Wizard generates ODRL for the current set of options. This XML listing may then be edited at the source level, if desired (note: this is generally not recommended). The output display is demonstrated in figure 13.
Figure 13. eduSource Provider Broker ODRL Wizard Generated ODRL Markup.
When the ODRL XML listing has been generated, the vendor may now save the file as an ODRL model by giving the file a name and selecting key options. The model may also be displayed in human readable form (English, French and Spanish output is currently supported). Figure 14 demonstrates the creation of an ODRL model. Subsequent to creation, a vendor may edit an ODRL file by selecting the rights model from a list provided on the 'Manage ODRL Files' screen. A sample ODRL file generated by the system may be found at http://drm.elg.ca/GetODRL?id=38
Figure 14. eduSource Provider Broker ODRL Wizard Create ODRL Model.
9. Provider Broker - Tagger Interaction
A 'tagger' is a tool used by learning object authors to create metadata for a learning object. It may be a stand-along tool, or it may be incorporated as a part of a more comprehensive authoring tool. The eduSource Repository in a Box includes a tagger as part of the software set available to users.
Once a vendor has created an account with a Provider Broker, the functionality of the Provider Broker may be accessed from within the tagging tool through the use of web services. Figure 15 is a mock-up of what such an interface would look like. The list of ODRL Models available is shown in the drop-down. The tagger obtains this list from the Provider Broker using a web service.
Figure 15. eduSource Provider Broker Tagger Interface.
When the rights model is selected, a second web service is called by the tagger, and the Provider Broker returns the address of the ODRL model. The tagger then inserts this address into the rights description field of the Learning Object Metadata (or the appropriate field if a different XML format is being used). The resulting rights XML is as follows:
Figure 16. ODRL Model Reference in Learning Object Metadata.
10. Purchaser Broker
As described above, a purchaser broker acts as an agent for a content purchaser (or 'infoseeker'). To use the Purchaser Broker, the infoseeker creates a purchaser broker account. Included as part of the account, as depicted in Figure 17, are conditions for pre-authorized purchases. As noted, the creation of pre-authorized purchases eliminates the mental transaction costs associated with micropayments.
Figure 17. eduSource Purchaser Broker Manage Account.
Though services offered from one Purchaser Broker to the next may vary, the idea is that a purchaser may employ any number of payment methods, including monthly invoice, addition to an Internet Service Provider billing, credit card payment, or online payment service such as PayPal. Figure 18 displays this selection in the Purchaser Broker Account Manager.
Figure 18. eduSource Purchaser Broker Manage Account.
11. Learning Object Browser
To demonstrate the functionality of the eduSource DRM system, a learning object browser (LOB) has been created. The LOB conducts a search across the eduSource network and displays the search results. http://drm.elg.ca/ObjectBrowser/ObjectBrowser
The LOB provides a user with access to Purchaser Broker functions. Figure 19 displays the LOB search form, with a choice of Purchaser Brokers displayed (recall that a user may opt to use one or more purchaser brokers). By selecting a purchaser broker, the user determines which of these services will conduct transactions on his or her behalf.
Figure 19. Learning Object Browser Purchaser Broker Select.
12. LOB - Vendor Broker Interaction
When search results are returned and displayed to an infoseeker, client software should also retrieve rights information automatically (using the URL located in of the metadata to retrieve the ODRL rights file from the rights broker). Displays may vary, of course, but an infoseeker would not typically click 'rights' -- they would select an action (view, print, etc). *If* rights clearance is required in order to perform the action, then the rights subroutines take effect; if no rights clearance is required, then the action simply happens.
For example, a person types in a search request that is sent to eduSource: 'Roman History' eduSource returns a set of LOM records. In each LOM record is a reference to an ODRL file. The person's client requests each ODRL file. This information is now displayed together.
For example, imagine the possible set of search results:
History of the Roman Empire
Fred's Roman History $
New Edited Roman History
All the Romans in the World $$
No Romans No More $
Rome Are Us
We can see from this display that some resources have a cost, and others are free. You do not need to click on anything to see this.
If a person clicks on the title of a free resource, it simply displays (that is, a request is sent directly to the provider's learning object repository, the resource is returned, and then displayed to the viewer).
If a person clicks on the title of a pay resource (indicated with $), then the request is sent instead to the purchaser broker. The purchaser broker retrieves the ODRL file from the vendor. In some cases, the payment is preapproved, so it simply conducts the transaction and sends a key to the users client, which then presents the key along with the request to the provider's learning object repository. In other cases, it must ask the user to select from a set of one or more options (offers) to approve (or reject) payment. If payment is rejected, the transaction terminates. If payment is made, then the transaction is conducted, a key obtained, and sent to the client program, which makes the request from the learning object repository.
We do not display ODRL information (except in rare cases). We use ODRL information to make decisions.
13. DRM Security Model
Digital rights management has three major aspects:
- Expression ? the description of the resource, ownership of the resource, and the terms and conditions of use
- Authentication ? verification that the person using the resource has the right to use the resource, and
- Protection ? means, such as encryption, to ensure only authorized users have access
In addition, DRM may be applied in any of three domains:
- Resource ? a particular document or digital resource ? for example, a document may be locked or encrypted
- Access Point ? a content server, such as a website ? for example, a website may require a login
- Network ? the connections between servers ? for example, ATM network
This creates a DRM design decision metric, as displayed in figure 20.
Figure 20. DRM Design Decision Metric.
In the decision metric, it is possible to identify increasing degrees of security, as demonstrated in Figure 21.
Figure 21. DRM Degrees of Security.
We may therefore distinguish between: weak DRM, where expression is in the resource only, there is no authentication and no protection, as in a web page with a copyright notice, book with a copyright page, property with a ?keep out? sign; and strong DRM, where expression is in the resource, access point, or network, authentication is in the network using a single login, and protection is network wide, as in the ATM Bank Machine system requires that you provide credentials to use the system, and encrypts all data and communication.
In the debates regarding DRM, two major positions have evolved, corresponding to these degrees of security:
- DRM is too weak: in networks like the web and Napster, expression alone is insufficient to ensure that rights are respected
- DRM is too strong: proposed DRM systems require a unique userid (eg., MS Passport) and fully secured network (eg., Rights management server, ?trusted? applications), violate privacy, fair use
The DRM mechanism proposed by eduSource DRM is a 'middle way' between these two extremes. Expression is supported at the network level through the use of a rights expression language (and specifically, ODRL). Authentication is supported at the access level through the use of keys. And protection is supported at the document level with locks or encryption.
Criticism regarding the proposed system has, not surprisingly, originated from both extremes. From one point of view, the eduSource DRM system is too strong. Advocates of open content, for example, fear any DRM system will prevent people from freely sharing content. However, it is arguable weak enough. In order to use free resources, rights must be declared, and any further level of authentication and protection is at the discretion of the resource owner. On the other hand, others have argued that the eduSource DRM system is too weak. Commercial providers, for example, want stronger protection, such as authentication at the network level, to prevent file sharing. But in response, it may be argued that it's strong enough. A key system makes it difficult to obtain unauthorized access to content, but leaves it easier to buy content than to steal it.
Critics of eduSource DRM must ask themselves, "What causes file sharing?" There are two answers. When DRM is too weak, there is no incentive to go through the extra work and cost to pay for content; commercial content is not viable. But when DRM is too strong, free content is not viable, and the transaction cost is too high, so it is easier to look elsewhere for the same content.
References
Babin, et.al., 2003. EduSource DRM Statement of Requirement. Version 2.0 Final. Gilbert Babin, Stephen Downes and Luc Belliveau. May 25, 2003. eduSource, http://www.edusource.ca
CanLOM, 2003. CanLOM. Web site. http://canlom.telecampus.edu/my/index.cfm?fuseaction=login
CAREO, 2003. CAREO. Web site. http://www.careo.org/
Cogigraph Technologies, 2002. Software Development and Integration Work Package Plan. Version 0.3. eduSource. http://www.edusource.ca
Downes, et.al., 2002. EduSource Vision. Version 3. Stephen Downes, Toni Roberts, Rory McGreal, Norm Friesen, John King, Terry Anderson, Michael Magee, Mike Mattson, Gilbert Paquette, Griff Richards. eduSource. http://www.downes.ca/files/vision3.doc
Downes, 2004. Distributed Digital Rights Management. Presentation to TeleEducation Online Forum, January 27, 2004. Power Point Slides. http://www.downes.ca/files/ddrm.ppt
eduSplash, 2003. Splash. Web site. http://www.edusplash.net/
Ianella, 2002. Open Digital Rights Language (ODRL) Version 1.1 W3C Note 19 September 2002. Renato Ianella. http://www.w3.org/TR/odrl/
LGPL, 1999. GNU Lesser General Public License. Version 2.1, February 1999. Free Software Foundation, Inc. http://www.gnu.org/copyleft/lesser.html
McGreal, et.al., 2003. eduSource: Creating learning object repositories in Canada. Rory McGreal, Griff Richards, Norm Friesen, Gilbert Paquette and Stephen Downes. Learning Technology, Volume 5, Issue 1. IEEE Computer Society Learning Technology Task Force. http://lttf.ieee.org/learn_tech/issues/january2003/#1
Paquette, et.al., 2003. eduSource Suite of Tools Use Cases Specifications Version 0.6. Gilbert Paquette, Anis Masmoudi, Gérard Lévy, Terry Anderson, Chris Hubrick, Stephen Downes, Gilbert Babin, Mike Matson, Marek Hatala and Griff Richards. June 7, 2003. eduSource. http://www.edusource.ca
Paquette, et.al., 2003. eduSource Suite of Tools Glossary of Terms Version 1.0. Gilbert Paquette, Karin Lundgren-Cayrol, Gérard Levy and Stephen Downes. eduSource. September 29, 2003. http://www.edusoruce.ca
Szabo, 1996. The Mental Accounting Barrier to Micropayments. Unpublished. http://szabo.best.vwh.net/micropayments.html
Technologies Cogigraph, 2003. Explor@. Web site. http://www.cogigraph.com/en/explora.htm
