Home | XMCL Initiative | Specification | Press Release | About Us | Q&A
This document specifies the Syntax and Semantics of XMCL, an eXtensible Media Commerce Language. Digital media in a rights management system flows through a number of steps on its journey to a consumer's eyes and ears. The steps are: create, package, publish, distribute, license, and consume. At least a subset of these abstract steps is implemented by all rights management systems today. The service or business owner that manages one or more of these steps varies widely depending on the relationships negotiated for a specific piece of content. However, there is a natural break between the back-end systems for publishing and licensing on one side and the trusted system that packaged the content and enforces the business rules for the content on the other. This division is between the systems that describe the business rules for the content and the specific implementation that enforces those rules.
XMCL is a "rights specification language", as defined by the Association of American Publishers [DRMEBOOKS]. The purpose of XMCL is for interchange of business rules to be applied to media between business systems (e.g. web store fronts, customer tracking and management) and trusted delivery and playback systems (e.g. a DRM implementation that will enforce the rights described in the XMCL document). Through the use of XMCL business systems are completely free of knowledge of specific trusted system implementations. This separation of the business systems and the trusted system allow businesses to support one or more trusted systems and provides the option of changing trusted systems as conditions change without changes to the business systems.
XMCL describes the minimum, self-complete set of business rules under which digital media is licensed for consumer use. These business rules support multiple business models including rental, subscription, ownership, and video on demand/pay-per-view. When a business system authorizes a customer transaction for digital media, it generates a XMCL document that is then acted upon and enforced by a specific trusted system. The generated XMCL document is submitted to the trusted system through the APIs of the trusted system (e.g. HTTP POST, RPC call, API call).
This document does not define interoperability end-to-end, but takes an important first step in that direction. As noted in the summary of the recent W3C Workshop on DRM, none of the standards efforts they evaluated "[deal] with what we think of as the essential first step for the Web: the simple expression and communication of IPR information and policies." [WWWDRM].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:
"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"
Consequently, we use these capitalized keywords to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions[XSCHEMA-STRUCTURE] unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the XML-namespace specification [XMLNAMES] is described as "REQUIRED."
<xmcl>
(clientInfo)?
(license)+
(auth)?
</xmcl>
Ed note: are there any more significant business models that should be included?
Ed note: reference [MM] after description of DC use is done
Ed note: need to describe this example. The <subscriptionRenewalURL> element is just an idea, there may be more primitive elements that gain the same functionality.
Ed note: How should ownership be designated? The length attribute is a Schema duration type which doesn't take the value "infinite" and the <validPeriod> element requires and end date. Digital Certificate theory tells us certs must have end periods but ownership of something doesn't end.
Ed note: <copy> element isn't included in syntax. It's obvious what it's intent is but it's expression is not consistent with the rest of the syntax. Are there a common set of allowed "destinations" like CD, VHS, DVD, PD (portable device), PM (portable media), that they can be described?
Or something like:
<allowedUse>
<param name="burnToCD"
value="true"/>
<param name="copyToPD"
value="true"/>
<param name="copyToPC"
value="false"/>
</allowedUse>
Ed note: are there other processing rules?
Schema Definition:
<element name="xmcl">
<complexType>
<sequence>
<element ref="clientInfo" minOccurs="0"/>
<element ref="license" maxOccurs="unbounded"/>
<element ref="revocationList" minOccurs="0"/>
<element ref="auth" minOccurs="0"/>
</sequence>
</complexType>
</element>
DTD: <!ELEMENT xmcl (clientInfo?, license+, revocationList?, auth?)>
Schema Definition:
<element name="clientInfo">
<complexType>
<sequence>
<element ref="param" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
DTD: <!ELEMENT clientInfo (param+)>
Ed note: Should clientInfo be better defined, not defined at all? Something that is outside the XCML fragment all together?
Schema Definition
<element name="param">
<complexType>
<attribute name="id" type="ID"/>
<attribute name="name" type="string"/>
<attribute name="value" type="string"/>
<attribute name="valuetype" use="default" value="data">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="data"/>
<enumeration value="ref"/>
<enumeration value="object"/>
</restriction>
</simpleType>
</attribute>
<attribute name="type" type="string"/>
</complexType>
</element>
DTD: <!ELEMENT param EMPTY> <!ATTLIST param id ID #IMPLIED name CDATA #IMPLIED value CDATA #IMPLIED valuetype (data | ref | object) #IMPLIED type CDATA #IMPLIED >
Schema Definition
<element name="license">
<complexType>
<sequence>
<element ref="contentInfo"/>
<element ref="validPeriod"/>
<element ref="usageRights"/>
<element ref="copyRights" minOccurs="0"/>
<element ref="transferRights" minOccurs="0"/>
</sequence>
<attribute name="numCopies" type="integer" use="default"
value="1"/>
<attribute name="allowTransfer" type="boolean" use="default"
value="false"/>
</complexType>
</element>
DTD: <!ELEMENT license (contentInfo, validPeriod, usageRights, copyRights?, transferRights?)> <!ATTLIST license numCopies CDATA #IMPLIED allowTransfer CDATA #IMPLIED >
Schema Definition:
<element name="contentInfo">
<complexType>
<sequence>
<element ref="contentID" minOccurs="0"/>
<element ref="ds:KeyInfo" minOccurs="0"/>
<any namespace="http://purl.org/dc/elements/1.1/"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
DTD: <!ELEMENT contentInfo (contentID?, ds:KeyInfo?, *)>
Schema Definition:
<element name="contentID" minOccurs="0">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="type" use="default" value="guid">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="guid"/>
<enumeration value="????"/>
</restriction>
</simpleType>
</attribute>
</extension>
</simpleContent>
</complexType>
</element>
DTD: <!ELEMENT contentID (#PCDATA)> <!ATTLIST contentID type CDATA #IMPLIED >
Ed note: need to define values for the type attribute. What standard id formats are there? Use another name or merge the attribute?
Schema Definition:
<element name="KeyInfo" type="ds:KeyInfoType"/>
<complexType name="KeyInfoType" mixed="true">
<choice maxOccurs="unbounded">
<element ref="ds:KeyName"/>
<element ref="ds:KeyValue"/>
<element ref="ds:RetrievalMethod"/>
<element ref="ds:X509Data"/>
<element ref="ds:PGPData"/>
<element ref="ds:SPKIData"/>
<element ref="ds:MgmtData"/>
<any processContents="lax" namespace="##other"/>
<!-- (1,1) elements from (0,unbounded) namespaces -->
</choice>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
</element>
DTD:
<!ELEMENT KeyInfo
(#PCDATA|KeyName|KeyValue|RetrievalMethod|
X509Data|PGPData|SPKIData|MgmtData %KeyInfo.ANY;)* >
<!ATTLIST KeyInfo
Id ID #IMPLIED
>
Schema Definition:
<element name="key">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="algorithm" type="uriReference"
use="required"/>
</extension>
</simpleContent>
</complexType>
</element>
DTD: <!ELEMENT key (#PCDATA)> <!ATTLIST key algorithm CDATA #REQUIRED >
Schema Definition:
<element name="validPeriod">
<complexType>
<attribute name="start" type="dateTime" use="required"/>
<attribute name="end" type="dateTime" use="required"/>
</complexType>
</element>
DTD: <!ELEMENT validPeriod EMPTY> <!ATTLIST validPeriod start CDATA #REQUIRED end CDATA #REQUIRED >
Schema Definition:
<element name="usageRights" type="rights">
<complexType name="rights">
<all>
<element ref="useDuration" minOccurs="0"/>
<element ref="useCount" minOccurs="0"/>
<element ref="userInteraction" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="require" minOccurs="0" maxOccurs="unbounded"/>
<element ref="allowedUse" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="impRights" minOccurs="0" maxOccurs="unbounded"/>
</all>
</complexType>
</element>
DTD: <!ELEMENT usageRights (useDuration?, useCount?, userInteraction*, require*, allowedUse*, impRights*)>
Schema Definition:
<element name="copyRights" type="rights">
<complexType name="rights">
<all>
<element ref="useDuration" minOccurs="0"/>
<element ref="useCount" minOccurs="0"/>
<element ref="userInteraction" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="require" minOccurs="0" maxOccurs="unbounded"/>
<element ref="allowedUse" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="impRights" minOccurs="0" maxOccurs="unbounded"/>
</all>
</complexType>
</element>
DTD: <!ELEMENT copyRights (useDuration?, useCount?, userInteraction*, require*, allowedUse*, impRights*)>
Schema Definition:
<element name="transferRights" type="rights">
<complexType name="rights">
<all>
<element ref="useDuration" minOccurs="0"/>
<element ref="useCount" minOccurs="0"/>
<element ref="userInteraction" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="require" minOccurs="0" maxOccurs="unbounded"/>
<element ref="allowedUse" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="impRights" minOccurs="0" maxOccurs="unbounded"/>
</all>
</complexType>
</element>
DTD: <!ELEMENT transferRights (useDuration?, useCount?, userInteraction*, require*, allowedUse*, impRights*)>
Schema Definition:
<element name="useDuration">
<complexType>
<attribute name="begin" use="default" value="firstUse">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="firstUse"/>
<enumeration value="issue"/>
</restriction>
</simpleType>
</attribute>
<attribute name="length" type="duration" use="required"/>
</complexType>
</element>
DTD: <!ELEMENT useDuration EMPTY> <!ATTLIST useDuration begin (firstUse | issue) #IMPLIED length CDATA #REQUIRED >
Schema Definition:
<element name="useCount">
<complexType>
<attribute name="count" type="integer" use="required"/>
<attribute name="threshold" type="duration" use="optional"/>
</complexType>
</element>
DTD: <!ELEMENT useCount EMPTY> <!ATTLIST useCount count CDATA #REQUIRED threshold CDATA #IMPLIED >
Ed note: The intent of the require element is to describe conditions that the trusted system are to require for playback. It should include things like employment water marking technology, use of a specific decompressor implementation, etc.
Schema Definition: <element name="require" type="string"/>
DTD: <!ELEMENT require (#PCDATA)>
Ed note: The intent of the userInteraction element is to describe something that requires user interaction before use of the licensed content will be allowed. This includes things like accepting a "click-wrap" license agreement at each playback.
Schema Definition: <element name="userInteraction" type="string"/>
DTD: <!ELEMENT userInteraction (#PCDATA)>
Ed note: The intent of the allowedUse element is to describe things like the content can only be included as a whole vs. included in a larger work.
Schema Definition: <element name="allowedUse" type="string"/>
DTD: <!ELEMENT allowedUse (#PCDATA)>
Schema Definition:
<element name="impRights">
<complexType>
<sequence>
<element name="param" maxOccurs="unbounded"/>
</sequence>
<attribute name="implementationID" type="uriReference"
use="required"/>
</complexType>
</element>
DTD: <!ELEMENT impRights (param+)> <!ATTLIST impRights implementationID CDATA #REQUIRED >
Ed Note: Should pull in <switch> element and systemRequired element from SMIL 2.0 for this section so a XMCL doc could describe implementation specific rights for multiple implementations and the parsing application could correctly pick the right one.
Ed Note: Need to describe extension mechanisms.
Ed Note: Should the attributes listed below be considered core or extensions?
Schema Definition:
<element name="revocationList">
<complexType>
<sequence>
<element ref="revokeItem" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
DTD: <!ELEMENT revocationList (revokeItem+)>
Schema Definition:
<element name="revokeItem">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="type" use="default" value="guid">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="guid"/>
<enumeration value="hash"/>
</restriction>
</simpleType>
</attribute>
</extension>
</simpleContent>
</complexType>
</element>
DTD: <!ELEMENT revokeItem (#PCDATA)> <!ATTLIST revokeItem type (guid | hash) #IMPLIED >
Ed note: another type collision. What types of item formats are appropriate?
Schema definition: <element name="auth"/>
DTD: <!ELEMENT auth (#PCDATA)>
Ed note: Use XML Signature for this? Allow for inclusion of X.509 certs? XML Cert?
[DCE11] "Dublin Core Metadata Element Set", Dublin Core Metadata Initiative, July, 1999. Available at http://purl.org/dc/elements/1.1/
[DCUSAGE] "Using Dublin Core", Diane Hillmann, April 2001. Available at http://dublincore.org/documents/usageguide/
[DCEMS-XML] "An XML Encoding of Simple Dublin Core Metadata", D. Beckett, E. Miller, D Brickly, December 2000. Available at http://dublincore.org/documents/2000/11/dcmes-xml/
[DRMEBOOKS] "Digital Rights Management for Ebooks: Publisher Requirements Version 1.0" Association of American Publishers, Inc, November, 2000.http://www.publishers.org/home/drm.pdf (see http://www.publishers.org/home/press/ebookpr.htm for more info)
[MM] "MusicBrainz Metadata Initiative", a portable and flexible means of storing and exchanging metadata related to digital audio and video tracks. Work in progress. http://www.musicbrainz.org/MM/
[SMIL20] "Synchronized Multimedia Integration Language (SMIL 2.0)". W3C Proposed Recommendation, work in progress. Available at http://www.w3.org/TR/smil20/
[URI] "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax" T. Berners-Lee, R. Fielding, L. Masinter, August 1998. http://www.ietf.org/rfc/rfc2396.txt
[WWWDRM] "W3C Workshop on Digital Rights Management for the Web: Workshop Report" J. Erickson, R. Iannella, R. Wenning, January, 2001. Workshop Report at http://www.w3.org/2000/12/drm-ws/workshop-report.html
[XML] "Extensible Markup Language (XML) 1.0 Specification", T. Bray, J. Paoli, C. M. Sperberg-McQueen, 10 February 1998. Latest version available at: http://www.w3.org/TR/REC-xml
[XMLDSIG] "RFC 3075: XML-Signature Syntax and Processing" (XML Digital Signatures) D. Eastlake, J. Reagle, D. Solo, March 2001. Available at http://www.w3.org/TR/xmldsig-core/
[XMLNAMES] "Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14 January 1999. XML namespaces provide a simple method for qualifying names used in XML documents by associating them with namespaces identified by URI. Latest version available at: http://www.w3.org/TR/REC-xml-names
[XSCHEMA-STRUCTURE] "XML Schema, XML Schema Part 1: Structures". W3C Recommendation 2 May 2001. Available at http://www.w3.org/TR/xmlschema-1/
[XSCHEMA-DATATYPES] "XML Schema Part 2: Datatypes", Paul V. Biron and Ashok Malhotra, eds., W3C, 2 May 2001. Available at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
[ ALGORITHMS] "XML Encryption Syntax and Processing: 6.1Algorithm Identifiers and Requirements" Available at http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/att-0024/01-XMLEncryption_v01.html#_Toc501424263
[XHTML]
"The Extensible HyperText Markup Language: A Reformulation of HTML 4.0 in
XML 1.0". W3C Recommendation 26 January 2000,
Available at http://www.w3.org/TR/xhtml1/
[KEYWORDS]
"RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner.
March 1997.
http://www.ietf.org/rfc/rfc2119.txt