Jan 09, 2010
This Proceedings Article published as Managing Digital Rights Using JSON in 6th IEEE International Workshop on Digital Rights Management Jan 09, 2010. IEEE - CCNC [Link] [Info] [List all Publications]
Presentation of this paper
PDF text of this paper
Abstract
Prior art in the expression of digital rights using XML is demonstrated to require a process of interpretation or parsing, as is characteristic with language processing, and in addition to be subject to the cross-domain scripting problem. The expression of digital rights using JSON, however, represents a novel approach, bypassing the need for language processing, and in addition, solving the cross-domain scripting problem.
Kewords
Digital Rights Management, JSON, Rights Expression
Overview
Significant resources are expended in the tracking and registering of copyrights associated with digital resources. A person desiring to access and use a digital resource must manually confirm having the right to do so, which increases the cost of using resources, even free resources. Mechanical systems have been proposed, but these are subject to certain patent restrictions and to significant processing overhead. This again increases the cost of using resources.
In this paper, an alternative mechanism for managing copyrights is proposed. It offers a low-cost and distributed mechanism that can be maintained for little cost and effort. It is a novel solution, providing significant advantage over existing mechanisms. It takes advantage of existing capability built into web browsers and other internet reading devices.
This paper describes the use of JavaScript Object Notation – JSON – for the purpose of managing digital rights. It demonstrates a functioning system whereby the location of rights information, expressed in JSON, is stored in the metadata describing a resource, available in the search process that reveals that resource, and used to inform client-based processes that use the resource.
What is JSON?
JavaScript (not to be confused with Java) is an object-oriented programming language used primarily to manage web browser interactions with web content. JavaScript is typically located on a web page and is read and processed entirely within the browser accessing that web page. This is a critical security feature of JavaScript. JavaScript applications work within the browser only; files are not saved outside the browser environment, and processes inhabiting one web page are insulated from those inhabiting another page.
This makes JavaScript very different from other programming languages or environments. All other web processing is managed either by server-side scripts, such as .asp pages, Java server environments, or CGI scripts, or by browser plug-ins, such as Flash, Java applets, or QuickTime. None of these server side or plug-in applications has JavaScript's security constraints. Additionally, all of them depend on the creation and processing of compiled computer code that is run outside the browser environment. As such, none of them is a part of the web page itself, with direct access to the Document Object Model (DOM), as JavaScript is.
JSON is the notation used to store data inside JavaScript. Strictly speaking, JSON is not a programming language at all. It is a method for defining part of the Document Object Model directly. Like other parts of JavaScript, JSON may be encoded directly as a part of a web page or imported from an external file. JSON files are plain text ASCII files and can be created using any common word processor. Unlike computer code (such as found in plug-ins or server side processing) JSON is never compiled and executed.
The syntax employed in a JSON object is used to identify parts of the data. The basic structure of a JSON object is to connect labels to data. For example, an expression such as
name:Stephen
Figure 1.
is a typical JSON construction. Such a construction is in no way processed or evaluated; it is, rather, the subject of processing or evaluation.
The following example demonstrates the employment of brackets and quotation marks in a JSON object:
{"menu": {
"id": "file",
"value": "File",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"},
{"value": "Open", "onclick": "OpenDoc()"},
{"value": "Close", "onclick": "CloseDoc()"}
] } }}
Figure 2. Source: http://www.json.org/example.html
As can be seen from the example, the employment of brackets and quotation marks is used to delimit names and values. They serve no processing function. Rather, they create a nested, hierarchical structure in JSON data. Specifically, the value of a JSON label may be either (a) a string, denoted with quotation marks (""), (b) a set of JSON objects, denoted with curly brackets ({}), or (c) an ordered list of JSON objects, denoted with square brackets ([]}.
Again, note, a JSON object is not parsed or interpreted in any way. When it is included in a web page, it is a part of the web page, contained inside the Document Object Model.
Rights Expressions
A rights expression is a statement of the permissions and duties associated with the use of a resource. An expression may vary from fully restrictive (for example: "All rights reserved") to fully permissive (for example: a statement declaring the resource to be in the public domain). In Canada and the United States, a rights expression in not required; resources are assumed upon creation to be fully copyrighted by their creators. Nor are rights expressions fully stipulative; a rights expression does not supersede either the expiry of copyright or the freedoms allowed under fair dealing or fair use.
That said, rights expressions are widely used in order to modify the presumptions ordinarily made under law, and in particular, to clarify ownership of copyright (which may have been assigned by the creator) and to allow specific uses not automatically granted under copyright. Instances of rights expressions include licenses and assignments of copyright or ownership. Rights expressions have elements in common, and these elements are replicated digitally in the form of rights expression languages.
1. Rights holder – the identity and coordinates of the person or entity holding copyright over a resource
2. Resource – the unique identity of the resource over which copyright is held
3. Action – the specific use to which the resource will be put (for example, ‘displayed' or ‘printed' or ‘resold')
4. Condition – the constraint or duty applied to a user who desires to perform the action with the specified resource
In rights expressions, the assignee is implicit, and is presumed to be the reader of the rights expression. A rights contract may exist when a document specifies both the rights holder and the assignee.
Examples of rights expressions may be found in both the Open Digital Rights Language (ODRL) and the MPEG Rights Expression Language (MPEG-REL, formerly XrML). In ODRL, they are known as ‘party', ‘asset', ‘permission' and ‘prohibition' respectively. (Ianella & Guth, 2007) And in MPEG-REL they are called ‘issuer', ‘resource', ‘right' and ‘condition' respectively (in MPEG-REL, ‘right' and ‘condition' taken together are called a ‘grant'). (Wang, deMartini, Barney, Paramasivam, & Barlas, 2005)
Probably the most widely used rights expression today is the Creative Commons rights expression. At least 130 million works are licensed under Creative Commons. (Creative Commons, 2009) Creative Commons is a set of licenses that express different sets of permissions on resources. Licenses may be varied by allowing or not allowing derivatives or commercial usage, and by requiring or not allowing attribution and sharing using the same license. (Creative Commons, 2009) These correspond, respectively, to actions and constraints. Creative Commons licenses are represented using both plain text and legal text descriptions. Additionally, the Creative Commons Rights Expression Language (ccREL) is now a W3C submission. (World Wide Web Consortium, 2008) The rights expression model identifies two major elements: work properties, and license properties. License properties express the actions and constraints; work properties express the work and the rights holder. (Cover, 2008)
Prior Art of Rights Expression
Numerous patents and patent applications exist that describe mechanisms for expressing and enforcing digital rights. Various licensing schemes exist. For example, in a European patent application filed by Lucent, EP20060744803, "a system checks for content rights and if a license is required, then the license is obtained and stored as a persistent file. (Cookson & Furlong, 2006) And ContentGuard has a series of patents related to licensing systems and access controls. Patent US 7290699, for example, describes a centralized rights repository that issues licenses to qualified clients to enable them to open content stored on trusted clients. (Reddy, Lao, & Budo-marek, 2005)
Various applications propose the employment of a plug-in or some other support software to run alongside the web browser. For example, another ContentGuard patent, US 7237125, describes "a client device, having a standard application program for accomplishing a task related to the product [a browser or viewer of some sort] and a rights management module operatively coupled to the server and said client device and configured, upon a request to access the content, to determine if security components are coupled to the application program." (Raley, Chen, Wu, & Ta, 2003) Similarly, a patent application filed in 2001 by IBM contemplates the use of a Java Virtual Machine (JVM) alongside the browser application in order to manage access. (Koved, Mourad, Munson, Pacifici, Pistoia, & Youssef, 2001)
Probably the most significant of the patents extant are held by ContentGuard, including one in which "a rights expression system and method for facilitating creation and/or modification of rights expressions in a rights expression language based on one or more schemas are provided." (Nguyen, Fung, Yee, & Tran, 2002) The patent describes a mechanism for representing "rights expressions in a rights expression language (REL)." The extent of this patent is not clear; there is no extant legal action from ContentGuard, either with respect to the use of ODRL (as for example) by the Open Mobile Alliance, or with respect to Creative Commons licenses, which have both made use of rights expressions. In the documentation, the application asserts that "a rights expression is a syntactically and semantically correct language construct, based on a defined grammar that conveys rights information". It is clear that the authors have the use of XML in mind, as the example provided is of XrML, and as the languages are informed by XML schema.
Another ContentGuard patent describes "a computer implemented method for processing a rights expression for association with an item for use in a digital rights management system." (Ta & et.al., 2003) This patent, like the other ContentGuard patents, is specific to "grammar-based language wherein said rights expression specifies a manner of use of said item for enforcement on a device, and said rights expression is encoded with a grammar-based expression language," which is what it understands XML to be.
Though the patents are intended to be general, it is clear that they were developed with XML in mind and were written so as to define the term "markup language" as generally as possible. However, the patents cover specific actions based on the nature and structure of XML, not the use of XML itself. This is seen by the continued filing of patents related to the use of XML in rights expression; for example, a European patent application filed by Vodaphone, EP1638292, refers to a ‘rights object', "for example, an XML document expressing permissions and constraints associated with a piece of DRM content." (Irwin, Wright, & Mulligan, 2005)
Using XML Rights Expressions
All three of XrML, ODRL and ccRML are expressed in a form of XML. XML, which stands for eXtensible Markup Language, is a World Wide Web Consortium recommendation. (World Wide Web Consortium, 2008)
XML may be used in a web environment in one of two major ways:
1. Translation – the XML data is directly translated, using XSL Transformations (XSLT), into a viewer-friendly format, such as HTML, which can be used by web browsers. (World Wide Web Consortium, 2009) The idea of XSLT is that data contained in a single XML document may be presented to readers in a variety of document formats
2. Parsing – the XML data is indirectly translated, using an XML parsing function, into data that may be managed by computer programs, such as database tables. An example of an XML parser is the Universal XML parser, authored by Mark Pilgrim. (Pilgrim, 2006) A parser translates the XML into a data structure; this data structure is then used by the computer code for subsequent processing or display. Parsing functions may use XSLT documents to manage parsing, or they may use native parsing functions, such as the Simple API for XML (SAX), for custom parsing applications. (Megginson, 2004)
XML may be used in one of two major processing environments:
1. Server side – XML is processed by a web data provider, such as a web site or web service. The web data provider acts as an intermediary between the ultimate data user (the ‘client') and the XML data. The XML data is retrieved by the web provider, parsed or translated, and then processed or presented to the client.
2. Client side – XML is processed by the client interface program. This is typically, but not necessarily, the web browser. The XML and (if necessary) XSLT is accessed directly by the client software, translated or parsed, and then processed or presented to the client.
Client side processing may be accomplished in one of two ways:
a. Natively – that is, the XML is processed by the web browser or client software directly, without access to external software. A ‘native' web browser is definable as an application that instantiates all or part, and only, the specifications described by the World Wide Web Consortium. Examples of native XML processing would be processing using XSLT or processing using JavaScript. (World Wide Web Consortium, 2009)
b. With Support – a supplementary program, known variously as a ‘helper application' or a ‘plug-in', is used by the web browser to translate or parse XML. Examples of plug-in or helper applications include those authored in Microsoft Silverlight, Adobe Flash or Java, or readers such as the Adobe Reader. These applications form separate processes outside the web browser process, and bypass or ignore web browser limitations.
There are two major web browser limitations. These limitations are imposed by the World Wide Web Consortium in order to maintain browser security:
1. Beyond very narrowly defined ‘cookie' files, web browsers may not alter the file system of the client computer.
2. Web application technologies apply origin restrictions to network requests. Specifically, these limitations prevent data from one origin from being used by processes or another origin. (World Wide Web Consortium, 2008)
These constraints create what is commonly known as the ‘cross domain scripting problem'. (Kraan, 2003) In essence, either XML and native processing (such as XSLT or JavaScript) must originate from the same domain, or non-native parsing of the XML file must be performed, either by a plug-in or by a server side process. There is, according to the cross domain scripting problem, no way to process XML files using only the web browser.
In the sections that follow, the response to the cross-domain scripting problem is described. It proceeds in two major steps: first, the employment of JSON, rather than XML, to express digital rights, and second, the employment of the ‘tag hack' to manage the transfer of rights information across domains.
The ‘Tag Hack
The ‘tag hack' is a mechanism for placing JavaScript data from one domain into a web page that originates in another domain. It is essentially a direct response to the cross domain scripting problem. (Crockford, 2009)
JavaScript scripts may be embedded into an HTML web page using the
PDF text of this paper
Abstract
Prior art in the expression of digital rights using XML is demonstrated to require a process of interpretation or parsing, as is characteristic with language processing, and in addition to be subject to the cross-domain scripting problem. The expression of digital rights using JSON, however, represents a novel approach, bypassing the need for language processing, and in addition, solving the cross-domain scripting problem.
Kewords
Digital Rights Management, JSON, Rights Expression
Overview
Significant resources are expended in the tracking and registering of copyrights associated with digital resources. A person desiring to access and use a digital resource must manually confirm having the right to do so, which increases the cost of using resources, even free resources. Mechanical systems have been proposed, but these are subject to certain patent restrictions and to significant processing overhead. This again increases the cost of using resources.
In this paper, an alternative mechanism for managing copyrights is proposed. It offers a low-cost and distributed mechanism that can be maintained for little cost and effort. It is a novel solution, providing significant advantage over existing mechanisms. It takes advantage of existing capability built into web browsers and other internet reading devices.
This paper describes the use of JavaScript Object Notation – JSON – for the purpose of managing digital rights. It demonstrates a functioning system whereby the location of rights information, expressed in JSON, is stored in the metadata describing a resource, available in the search process that reveals that resource, and used to inform client-based processes that use the resource.
What is JSON?
JavaScript (not to be confused with Java) is an object-oriented programming language used primarily to manage web browser interactions with web content. JavaScript is typically located on a web page and is read and processed entirely within the browser accessing that web page. This is a critical security feature of JavaScript. JavaScript applications work within the browser only; files are not saved outside the browser environment, and processes inhabiting one web page are insulated from those inhabiting another page.
This makes JavaScript very different from other programming languages or environments. All other web processing is managed either by server-side scripts, such as .asp pages, Java server environments, or CGI scripts, or by browser plug-ins, such as Flash, Java applets, or QuickTime. None of these server side or plug-in applications has JavaScript's security constraints. Additionally, all of them depend on the creation and processing of compiled computer code that is run outside the browser environment. As such, none of them is a part of the web page itself, with direct access to the Document Object Model (DOM), as JavaScript is.
JSON is the notation used to store data inside JavaScript. Strictly speaking, JSON is not a programming language at all. It is a method for defining part of the Document Object Model directly. Like other parts of JavaScript, JSON may be encoded directly as a part of a web page or imported from an external file. JSON files are plain text ASCII files and can be created using any common word processor. Unlike computer code (such as found in plug-ins or server side processing) JSON is never compiled and executed.
The syntax employed in a JSON object is used to identify parts of the data. The basic structure of a JSON object is to connect labels to data. For example, an expression such as
name:Stephen
Figure 1.
is a typical JSON construction. Such a construction is in no way processed or evaluated; it is, rather, the subject of processing or evaluation.
The following example demonstrates the employment of brackets and quotation marks in a JSON object:
{"menu": {
"id": "file",
"value": "File",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"},
{"value": "Open", "onclick": "OpenDoc()"},
{"value": "Close", "onclick": "CloseDoc()"}
] } }}
Figure 2. Source: http://www.json.org/example.html
As can be seen from the example, the employment of brackets and quotation marks is used to delimit names and values. They serve no processing function. Rather, they create a nested, hierarchical structure in JSON data. Specifically, the value of a JSON label may be either (a) a string, denoted with quotation marks (""), (b) a set of JSON objects, denoted with curly brackets ({}), or (c) an ordered list of JSON objects, denoted with square brackets ([]}.
Again, note, a JSON object is not parsed or interpreted in any way. When it is included in a web page, it is a part of the web page, contained inside the Document Object Model.
Rights Expressions
A rights expression is a statement of the permissions and duties associated with the use of a resource. An expression may vary from fully restrictive (for example: "All rights reserved") to fully permissive (for example: a statement declaring the resource to be in the public domain). In Canada and the United States, a rights expression in not required; resources are assumed upon creation to be fully copyrighted by their creators. Nor are rights expressions fully stipulative; a rights expression does not supersede either the expiry of copyright or the freedoms allowed under fair dealing or fair use.
That said, rights expressions are widely used in order to modify the presumptions ordinarily made under law, and in particular, to clarify ownership of copyright (which may have been assigned by the creator) and to allow specific uses not automatically granted under copyright. Instances of rights expressions include licenses and assignments of copyright or ownership. Rights expressions have elements in common, and these elements are replicated digitally in the form of rights expression languages.
1. Rights holder – the identity and coordinates of the person or entity holding copyright over a resource
2. Resource – the unique identity of the resource over which copyright is held
3. Action – the specific use to which the resource will be put (for example, ‘displayed' or ‘printed' or ‘resold')
4. Condition – the constraint or duty applied to a user who desires to perform the action with the specified resource
In rights expressions, the assignee is implicit, and is presumed to be the reader of the rights expression. A rights contract may exist when a document specifies both the rights holder and the assignee.
Examples of rights expressions may be found in both the Open Digital Rights Language (ODRL) and the MPEG Rights Expression Language (MPEG-REL, formerly XrML). In ODRL, they are known as ‘party', ‘asset', ‘permission' and ‘prohibition' respectively. (Ianella & Guth, 2007) And in MPEG-REL they are called ‘issuer', ‘resource', ‘right' and ‘condition' respectively (in MPEG-REL, ‘right' and ‘condition' taken together are called a ‘grant'). (Wang, deMartini, Barney, Paramasivam, & Barlas, 2005)
Probably the most widely used rights expression today is the Creative Commons rights expression. At least 130 million works are licensed under Creative Commons. (Creative Commons, 2009) Creative Commons is a set of licenses that express different sets of permissions on resources. Licenses may be varied by allowing or not allowing derivatives or commercial usage, and by requiring or not allowing attribution and sharing using the same license. (Creative Commons, 2009) These correspond, respectively, to actions and constraints. Creative Commons licenses are represented using both plain text and legal text descriptions. Additionally, the Creative Commons Rights Expression Language (ccREL) is now a W3C submission. (World Wide Web Consortium, 2008) The rights expression model identifies two major elements: work properties, and license properties. License properties express the actions and constraints; work properties express the work and the rights holder. (Cover, 2008)
Prior Art of Rights Expression
Numerous patents and patent applications exist that describe mechanisms for expressing and enforcing digital rights. Various licensing schemes exist. For example, in a European patent application filed by Lucent, EP20060744803, "a system checks for content rights and if a license is required, then the license is obtained and stored as a persistent file. (Cookson & Furlong, 2006) And ContentGuard has a series of patents related to licensing systems and access controls. Patent US 7290699, for example, describes a centralized rights repository that issues licenses to qualified clients to enable them to open content stored on trusted clients. (Reddy, Lao, & Budo-marek, 2005)
Various applications propose the employment of a plug-in or some other support software to run alongside the web browser. For example, another ContentGuard patent, US 7237125, describes "a client device, having a standard application program for accomplishing a task related to the product [a browser or viewer of some sort] and a rights management module operatively coupled to the server and said client device and configured, upon a request to access the content, to determine if security components are coupled to the application program." (Raley, Chen, Wu, & Ta, 2003) Similarly, a patent application filed in 2001 by IBM contemplates the use of a Java Virtual Machine (JVM) alongside the browser application in order to manage access. (Koved, Mourad, Munson, Pacifici, Pistoia, & Youssef, 2001)
Probably the most significant of the patents extant are held by ContentGuard, including one in which "a rights expression system and method for facilitating creation and/or modification of rights expressions in a rights expression language based on one or more schemas are provided." (Nguyen, Fung, Yee, & Tran, 2002) The patent describes a mechanism for representing "rights expressions in a rights expression language (REL)." The extent of this patent is not clear; there is no extant legal action from ContentGuard, either with respect to the use of ODRL (as for example) by the Open Mobile Alliance, or with respect to Creative Commons licenses, which have both made use of rights expressions. In the documentation, the application asserts that "a rights expression is a syntactically and semantically correct language construct, based on a defined grammar that conveys rights information". It is clear that the authors have the use of XML in mind, as the example provided is of XrML, and as the languages are informed by XML schema.
Another ContentGuard patent describes "a computer implemented method for processing a rights expression for association with an item for use in a digital rights management system." (Ta & et.al., 2003) This patent, like the other ContentGuard patents, is specific to "grammar-based language wherein said rights expression specifies a manner of use of said item for enforcement on a device, and said rights expression is encoded with a grammar-based expression language," which is what it understands XML to be.
Though the patents are intended to be general, it is clear that they were developed with XML in mind and were written so as to define the term "markup language" as generally as possible. However, the patents cover specific actions based on the nature and structure of XML, not the use of XML itself. This is seen by the continued filing of patents related to the use of XML in rights expression; for example, a European patent application filed by Vodaphone, EP1638292, refers to a ‘rights object', "for example, an XML document expressing permissions and constraints associated with a piece of DRM content." (Irwin, Wright, & Mulligan, 2005)
Using XML Rights Expressions
All three of XrML, ODRL and ccRML are expressed in a form of XML. XML, which stands for eXtensible Markup Language, is a World Wide Web Consortium recommendation. (World Wide Web Consortium, 2008)
XML may be used in a web environment in one of two major ways:
1. Translation – the XML data is directly translated, using XSL Transformations (XSLT), into a viewer-friendly format, such as HTML, which can be used by web browsers. (World Wide Web Consortium, 2009) The idea of XSLT is that data contained in a single XML document may be presented to readers in a variety of document formats
2. Parsing – the XML data is indirectly translated, using an XML parsing function, into data that may be managed by computer programs, such as database tables. An example of an XML parser is the Universal XML parser, authored by Mark Pilgrim. (Pilgrim, 2006) A parser translates the XML into a data structure; this data structure is then used by the computer code for subsequent processing or display. Parsing functions may use XSLT documents to manage parsing, or they may use native parsing functions, such as the Simple API for XML (SAX), for custom parsing applications. (Megginson, 2004)
XML may be used in one of two major processing environments:
1. Server side – XML is processed by a web data provider, such as a web site or web service. The web data provider acts as an intermediary between the ultimate data user (the ‘client') and the XML data. The XML data is retrieved by the web provider, parsed or translated, and then processed or presented to the client.
2. Client side – XML is processed by the client interface program. This is typically, but not necessarily, the web browser. The XML and (if necessary) XSLT is accessed directly by the client software, translated or parsed, and then processed or presented to the client.
Client side processing may be accomplished in one of two ways:
a. Natively – that is, the XML is processed by the web browser or client software directly, without access to external software. A ‘native' web browser is definable as an application that instantiates all or part, and only, the specifications described by the World Wide Web Consortium. Examples of native XML processing would be processing using XSLT or processing using JavaScript. (World Wide Web Consortium, 2009)
b. With Support – a supplementary program, known variously as a ‘helper application' or a ‘plug-in', is used by the web browser to translate or parse XML. Examples of plug-in or helper applications include those authored in Microsoft Silverlight, Adobe Flash or Java, or readers such as the Adobe Reader. These applications form separate processes outside the web browser process, and bypass or ignore web browser limitations.
There are two major web browser limitations. These limitations are imposed by the World Wide Web Consortium in order to maintain browser security:
1. Beyond very narrowly defined ‘cookie' files, web browsers may not alter the file system of the client computer.
2. Web application technologies apply origin restrictions to network requests. Specifically, these limitations prevent data from one origin from being used by processes or another origin. (World Wide Web Consortium, 2008)
These constraints create what is commonly known as the ‘cross domain scripting problem'. (Kraan, 2003) In essence, either XML and native processing (such as XSLT or JavaScript) must originate from the same domain, or non-native parsing of the XML file must be performed, either by a plug-in or by a server side process. There is, according to the cross domain scripting problem, no way to process XML files using only the web browser.
In the sections that follow, the response to the cross-domain scripting problem is described. It proceeds in two major steps: first, the employment of JSON, rather than XML, to express digital rights, and second, the employment of the ‘tag hack' to manage the transfer of rights information across domains.
The ‘Tag Hack
The ‘tag hack' is a mechanism for placing JavaScript data from one domain into a web page that originates in another domain. It is essentially a direct response to the cross domain scripting problem. (Crockford, 2009)
JavaScript scripts may be embedded into an HTML web page using the