2.2.3 Distribution Model In the general DMP Distribution Model the following Users operate: 1. 2. 3. 4. Content Providers providing Content to End-Users and Service Providers; License Providers providing Licenses to End-Users and Service Providers; DRM Tool Providers providing DRM Tools to End-Users and Service Providers; Service Providers providing Services to End-Users.
Figure 6 Conceptual diagram of DMP Distribution Model A specific Value-Chain need not involve all types of Users indicated in the Figure above, e.g. 1. Service Provider may Deliver Content to End-Users with License and DRM Tools Bundled within it. In this case the Service Provider makes and Registers a new Content Item out of Content, License and DRM Tools received from other Users. This is represented in the top line of the figure. 2. Service Provider may not be required as the End-User individually Accesses Content, License and DRM Tools. This is represented by removing the first line of the figure 3. DRM Tool Provider may not be required, e.g. when Governed Content is Delivered without the use of DRM Tools. This is represented by removing the bottom line in the figure. Note that Service Provider makes and Registers a new Content Item out of Content, License and DRM Tools that he receives from other Users. 2.2.4 Delivery Model For the purpose of this specification all types of Data to be Delivered between Device Entities can be Represented as Content Elements, in particular Content, Licenses, DRM Tools and DRM Information. These Content Elements can be variously combined between themselves and other Content Elements.
DCI is a Representation of Content that, along with the relevant Content Elements, can be Processed by a Device. However, DCI is not suitable for Delivering Content between Devices. The Package Function enables Delivery of a Content Item over a variety of specific Delivery mechanisms. Chapter 3 supports Delivery as a File (DCF), on an MPEG-2 Transport Stream (DCB) and on a Real-Time Protocol transport (DCS). The Package Function includes Insert DCI in the selected transport mechanism Extract DCI from the selected transport mechanism
2.2.5 DRM Tool Model The following figure describes the DRM Tool Model.
Figure 7 Handling of DRM Tools in a Device Packaged Content is Delivered to a Device because the Device has Accessed it or another Device has Delivered it. The Parser extracts the DCI from the Packaged Content. In general the DCI Parser extracts the following from the DCI: 1. 2. 3. 4. 5. 6. Resources Metadata DRM Information DRM Tools or Tool Packs Licenses Keys.
Resources and Metadata are passed to the appropriate decoding pipelines while DRM Information, DRM Tools or Tool Packs, Licenses and Keys are passed on to the DRM Processor, a module within a Device that executes DRM-related Functions in a Trusted fashion. The Device may already have all required DRM Tools e.g. because they are:
1. Embedded in the Device 2. Stored after having been previously Accessed 3. Bundled within the Content Item currently Accessed. If none of the above holds, then the DRM Processor will Access the missing DRM Tools from the DRM Tool Provider Device. Once Used, all DRM Tools are kept in the Secure Storage of the Device. The DRM Processor controls the critical points internal to a Device. As an example, in Figure 7 there are 7 such control points (indicated as black nodes). The DRM Processor, using the DRM Information, instantiates the required DRM Tools as plug-in modules (called DRM Tool Bodies), and instructs them to operate on the specific control points along the Resource decoding pipelines. As described above, DRM Tools represent one or more DRM Functions such as Authenticate, Decrypt, detect watermark signal or extract watermark payload, etc. The DRM Processor handles instantiation, initialisation, Authentication, and supervision of DRM Tools Bodies. However, DRM Tools can also be aggregated into a DRM Tool Group. In this case a DRM Tool Agent performs the same tasks above for the DRM Tools in a DRM Tool Group. The combination of a DRM Tool Agent and its DRM Tool Group is called DRM Tool Pack (see Figure 8). Note that a mandatory requirement for a DRM Processor is that it can interface with DRM Tool Agents and DRM Tools. By using a DRM Tool Pack, sensitive information about the way a Resource is Governed can be placed in the DRM Tool Agent instead of placing it in the DCI. However, in those cases where a simple DRM Tool configuration is required, e.g. one DRM Tool performing AES Decryption on a Governed video stream, a single DRM Tool configuration may be a simpler option.

3.2.14 Represent DRM Messages 3.2.14.1 Introduction This section provides the means to Represent Information exchanged between different components on a Device, such as two DRM Tools or a DRM Processor and a DRM Tool. DRM Messages are a translation of messages originally defined in the MPEG-2 and MPEG-4 IPMPX standards (see [12] and [14]) from a binary representation to XML. See Annex A.5 MPEG-2/4 IPMP Extension for an overview of those standards. Note: In the sub-sections below a DRM Tool can be either a single DRM Tool or a DRM Tool Agent of a DRM Tool Pack 3.2.14.2 Containers for DRM Messages As specified in Sections 3.2.8 Represent DRM Tool and 3.3.7.2 DRM Processor DRM Tools Protocols, the DRM Processor instantiates a DRM Tool to Govern a Content Element every time it encounters a ipmpinfo:Tool element within the Governed Content Representation in the DCI. The DRM Processor assigns an Identifier to each instance of DRM Tool, named the DRM Tool Context ID. The Tool Context ID serves a different role from the DRM Tool ID. In particular, two instances of a DRM Tool with a common DRM Tool ID will be assigned different values of Tool Context ID. Once the DRM Tool is instantiated, the Governance of the Governed Content Element through the DRM Tool may involve the exchange of information between the DRM Processor and the DRM Tool or between the various DRM Tools. This information is coded in DRM Messages, which are encapsulated in two different containers depending on the way the Message is originated: 1. MessageFromDCI: this container Message is sent from the DRM Processor to a DRM Tool conveying information extracted from the DCI and addressed to the DRM Tool (e.g. a Key to Decrypt a Resource); 2. MessageFromTool: this container Message is sent either from the DRM Processor or from a DRM Tool to another DRM Tool and contains information originated internally by the sender. For example, a Message requesting mutual Authentication. Both Containers: MessageFromDCI and MessageFromTool, share the same abstract XML element Base Type: ipmpmsg:IPMPBaseType, shown in Figure 91: <complexType name="IPMPBaseType" abstract="true"/> Figure 91: The ipmpmsg:IPMPBaseType type
3.2.14.2.1 ipmpmsg:ToolMessageBase
All DRM Message Containers are based on the ipmpmsg:ToolMessageBase element, defined in Figure 92: <element name="ToolMessageBase" type="ipmpmsg:ToolMessageBaseType" abstract="true"/> <complexType name="ToolMessageBaseType" abstract="true"> <complexContent>

3.2.18.6 User The mxmd:User element is defined in Figure 131: <element name="User" type="mxmd:UserType"/> <complexType name="UserType"> <complexContent> <extension base="mxmd:DomainBaseType"> <sequence> <element ref="mxmd:UserIDList"/> <element ref="mxmd:MaximumNumberOfUsers" minOccurs="0"/> <element ref="mxmd:MaximumFrequencyOfUpdateUser" minOccurs="0"/> <element ref="mxmd:UserRevocationList" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> Figure 131: The mxmd:User element
The mxmd:User element conveys a set of properties associated with Users in a Domain. This conveys the following: the mxmd:UserIDList, as defined in Figure 132 the mxmd:MaximumNumberOfUsers, the maximum number of Users allowed in a Domain the mxmd:MaximumFrequencyOfUpdateUser: the shortest duration permitted between a User leaving and re-registering with this Domain. Note that the UserID shall not be removed from the UserIDList until after the time indicated in the mxmd:MaximumFrequencyOfUpdateUser element. the mxmd:UserRevocationList: the list of Users which are no longer allowed to be members of this Domain.
3.2.18.7 UserIDList The mxmd:UserIDList element is defined in Figure 132: <element name="UserIDList"> <complexType> <sequence minOccurs="0" maxOccurs="unbounded"> <element ref="mxmd:UserID"/> <element ref="mxmd:Expiration"/> </sequence> </complexType> </element> Figure 132: The mxmd:UserIDList element This element is used to convey a list of User Identifiers associated with this Domain. Each User has an expiration time, allocated by the Domain Managed Device at the time of joining the Domain. 3.2.18.8 Device The mxmd:Device element is defined in Figure 133: <element name="Device" type="mxmd:DeviceType"/> <complexType name="DeviceType"> <complexContent> <extension base="mxmd:DomainBaseType"> <sequence> <element ref="mxmd:DeviceIDList"/> <element ref="mxmd:MaximumNumberOfDevices" minOccurs="0"/> <element ref="mxmd:MaximumFrequencyOfUpdateDevice" minOccurs="0"/> <element ref="mxmd:DeviceRevocationList"/> </sequence> </extension> </complexContent> </complexType> Figure 133: The mxmd:Device element 154

3.3.3.5.3 Un-Licensed Simultaneous Use
All the Devices in a Domain that simultaneously Used Content Elements part of a Content Item belonging to a Content Group are considered as having performed un-Licensed Simultaneous Use. This is detected by Devices or DMD through inspection of the Use Data. If the Use Data has any overlapped records in time then the Devices indicated by the DeviceID in the overlapped record are considered to have incurred un-Licensed Simultaneous Use. However, if a Content Item is Licensed to more than one ContentGroupID, then the Use is allocated to the ContentGroupID that avoids un-Licensed Simultaneous Use. This is assessed at the time the Use Data is merged or the totality of Use Data are Delivered to the DMD. 223
Figure 229 describes how Un-Licensed Simultaneous Use is detected. In this figure, Device A Uses Content1 during the period of time shown by the thick line. Similarly Device B is shown Using Content2 during the thick line segment of the lower line. In this case, the usage of Content1 on Device A and the usage of Content2 on Device B occur at the same time, shown by the overlapping of their respective thick line segments. Both Content1 and Content2 are given CG1 as a ContentGroupID. As this ContentGroupID is subject to the rule that only one content item from the group shall be Used at any time this is an example of Un-Licensed Simultaneous Use. Figure 229 also shows Device C Using firstly Content3 and later Content4 during the time shown by the two thick line segments of the Device C timeline. In this case, the usage of Content1 on Device A and the usage of Content3 on Device C overlap in time. However, Content1 and Content3 are given different ContentGroupId values so this case does not violate the rule.
Figure 229 Un-Licensed Simultaneous Use Schematic The usage of Content2 on Device B and the usage of Content4 on Device C also overlaps in time. As Content4 is given both CG1 and CG2 as ContentGroupIDs CG2 will be chosen in order to avoid unnecessary detection of Un-Licensed Simultaneous Usage.

<r:digitalResource> <r:nonSecureIndirect URI="urn:myPresentations:presentation:444"/> </r:digitalResource> </r:grant> <!-- Every Device can Move the presentation--> <r:grant> <bpx:governedMove/> <r:digitalResource> <r:nonSecureIndirect URI="urn:myPresentations:presentation:444"/> </r:digitalResource> </r:grant> <r:issuer> <r:keyHolder> <r:info> <dsig:KeyName>Leonardo_s Certificate</dsig:KeyName> </r:info> </r:keyHolder> </r:issuer> </r:license> </dmp2rl:License> </dmp2_ipmpinfo:License> </dmp2_ipmpinfo:RightsDescriptor> </dmp2_ipmpinfo:LicenseCollection> </dmp2_ipmpinfo:IPMPGeneralInfoDescriptor> </Statement> </Descriptor> <Item> <Descriptor> <Statement mimeType="text/xml"> <dmp1_dii:Identifier>urn:Leonardo:Licenses:HumanReadableLicense:12</dmp1_dii:Identifier> </Statement> </Descriptor> <Component> <Resource mimeType="text/plain"> This License allows you to: 1. Play a. Time of Use: i. until conference ends (Users who are conference participants) ii. after conference ends (all Users in Italy) b. # of times: unlimited 2. Store: unrestricted 3. Print PowerPoint file: unrestricted 4. Move: unrestricted 252
5. Copy: unrestricted </Resource> </Component> </Item> <Item> <Descriptor> <Statement mimeType="text/xml"> <dmp1_dii:Identifier>urn:Leonardo:AudioRecording:1234</dmp1_dii:Identifier> </Statement> </Descriptor> <Descriptor> <Statement mimeType="text/xml"> <dmp2rc:DMPInformation> <dmp2rc:Metadata> <dmp2rc:StructuredData ref="urn:mpeg:mpeg7:schema:2001"> <!-- Metadata for audio track--> </dmp2rc:StructuredData> </dmp2rc:Metadata> </dmp2rc:DMPInformation> </Statement> </Descriptor> <Component> <Resource mimeType="application/mp21-ipmp"> <dmp2_ipmpdidl:ProtectedAsset mimeType="audio/mpeg"> <dmp2_ipmpdidl:Info> <dmp2_ipmpinfo:IPMPInfoDescriptor> <dmp2_ipmpinfo:RightsDescriptor> <dmp2_ipmpinfo:LicenseReference>urn:myLicenses:6789A</dmp2_ipmpinfo:LicenseReferenc e> </dmp2_ipmpinfo:RightsDescriptor> </dmp2_ipmpinfo:IPMPInfoDescriptor> </dmp2_ipmpdidl:Info> <dmp2_ipmpdidl:Contents ref="AudioRecording1234.mp3"/> </dmp2_ipmpdidl:ProtectedAsset> </Resource> </Component> </Item> <Item> <Descriptor> <Statement mimeType="text/xml"> <dmp1_dii:Identifier>urn:Leonardo:VideoRecording:5678</dmp1_dii:Identifier> </Statement> </Descriptor> <Descriptor> <Statement mimeType="text/xml"> <dmp2rc:DMPInformation> 253

4.9 Use Case and Value Chain no. 8 Personal photography
4.9.1 Rationale Great Red Cameras (GRC) is a camera manufacturer who senses the growing demand on the part of its customers to retain control of their photos when they make a copy to their friends. Their latest model GRC-1 provides a new functionality that GRC hopes will encounter the favour of its customers. This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation. 4.9.2 Tools for walkthrough #1
4.9.2.1 Creation Shoji has bought a GRC camera and taken some pictures with it. Now he wants to send a selection of those pictures to Kenji. These are the steps he performs: Who Perform What Notes IDP Tool Ref. Shoji Encrypt Resources.jpg files Out of (camera) scope Shoji Move Resources To his PC using a Trusted Application None (camera) provided by GRP Shoji (SAV) Make Licence Licence terms are, e.g. Represent 2.10 1. For one week Licence 2. Unlimited number of times 3. Simultaneously on all the Devices of the friends Domain Registration Identify Licence None Agency Shoji (SAV) Store Licence To Shojis Licence Provider Device None Shoji (SAV) Make Content With the selected pictures (with Represent 2.1 Item whatever other Resources and Content Metadata (e.g. EXIF) the User will decide to add), pointer to Licence and Identifiers of Resources, Metadata and Licence Registration Identify Content None Agency Item Shoji (SAV) Represent Identifier To Content Item Represent 2.1 Content Shoji (SAV) Package Content For Delivery Package 4.1.1 Item Content Shoji (SAV) Copy Content To Kenji (SAV) Out of Item scope
4.9.2.2 Consumption Kenji, after receiving a notification that Shojis pictures have been Delivered, performs the following: Who Kenji (SAV) Kenji (SAV) Kenji (SAV) Kenji (SAV) Perform UnPackage Parse Access Play What Content Item DCI Licence Pictures Notes Using the Delivered DCF IDP Tool Package Content Represent Content From Shojis Licence Provider Access Licence as Device File None Ref. 4.1.1 2. 3.5.2
4.10 Use Case and Value Chain No. 9 Open Broadcast

</digitalResource> </grant> <grant> <m1x:identityHolder licensePartIdRef="domainA"/> <m1x:governedCopy governanceRule="acme:CopyOnce"/> <r:digitalResource licensePartIdRef="news"/> </grant> <issuer> <keyHolder> <info> <dsig:KeyName>Rights Issuer Public Key Name</dsig:KeyName> </info> </keyHolder> </issuer> </license> Figure 263 Licence example 7 Once this broadcast program is copied to other device, new copied Licence may be shown like following. <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-RNS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-RELM2X-NS.\idp-2\rel-m2x-dac-v1.xsd"> <grant> <m1x:identityHolder licensePartId="domainA"> <m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM00001000</m1x:idSystem> <m1x:idValue>BSI:2232111123</m1x:idValue> </m1x:identityHolder> <mx:play/> <digitalResource licensePartId="news"> <r:nonSecureIndirect URI="urn:broadcast:news:2005_07_10-12H-00M"/> </digitalResource> </grant> <issuer> <keyHolder> <info> <dsig:KeyName>Rights Issuer Public Key Name</dsig:KeyName> </info> </keyHolder>
</issuer> </license> Figure 264 Licence example 8
4.13 Use Case and Value Chain No. 12 TVA Broadcaster
4.13.1 Rationale The TV Anytime Forum has developed specifications with a native Rights Expression language called RMPI. In this Use Case it is assumed that broadcasting is effected using RMPI but that once Content is received by the SAV it is Imported as a file and Stored. This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation. 4.13.2 Tools for walkthrough #1 Free-To-Air Content The following example shows a possible combination of rights granted to a given piece of content broadcast free-to-air: 11. Content is not scrambled and will remain unscrambled after domain acquisition. 12. No possibility is granted to acquire new rights. 13. In the receiving domain, Play, Analogue Export, Digital Export (both HD and SD) are granted. Proximity Control is the only restriction that applies. Required security level in the TVA security system is the lowest. 14. Only Play, Analogue Export are granted in any other domain. No Proximity Control applies but Geographic Control (only Germany) does. A medium security level in the TVA security system is required to enforce that restriction. 4.13.2.1 Expression with RMPI namespace <?xml version="1.0" encoding="UTF-8"?> <TVAMain xmlns="urn:tva:metadata:2005" xmlns:tva2="urn:tva:metadata:extended:2005" xmlns:tva="urn:tva:metadata:2005" xmlns:rmpi="urn:tva:rmpi:2005" xmlns:mpeg21="urn:tva:mpeg21:2005" xmlns:mpeg7="urn:tva:mpeg7:2005" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:tva:metadata:extended:2005 tva2_metadata_3-3_v111.xsd" xsi:type="tva2:ExtendedTVAMainType"> <tva2:RMPITable xml:lang="en-us"> <tva2:RMPIDescription RMPIDescriptionId="String"> <rmpi:AncillaryRMPI> <rmpi:RMPITypeFlag>RMPI-MB</rmpi:RMPITypeFlag> <rmpi:VersionOfRMPI>0</rmpi:VersionOfRMPI> <rmpi:OriginOfRMPI>FTABroadcasterDE</rmpi:OriginOfRMPI> <rmpi:Cipher>no cipher</rmpi:Cipher> <rmpi:MBScramblingControl>maintain</rmpi:MBScramblingControl>

4.17 Use Cases and Value Chain Number 16 Value Chain Roles
4.17.1 Rationale Groups of individuals sporadically and often spontaneously, work together to create Content that may become distributed on the internet. They do this by exchanging preliminary computer files (text, audio, audio visual, image) known as Resources which serve to represent the different related IP Entities each are responsible for. Eventually, these Resources can become part of Products that are used and traded on the internet. These individuals are also recognized between each other by virtue of sets of specific actions they perform on or with specific IP Entities, different sets of these actions constitute Roles for example, a Creator authors, a Performer interprets and so on with the Roles of arranger, producer publisher and distributor. These Roles are thus associated with specific IP Entities that in turn qualify the digital objects that represent them. Also, IP Entity to IP Entity and Role to Role relationships are direct corollaries of one another. However and presently, the process of formalising and recording interactions between Users that assume Roles is performed through disparate means that are sometimes only partially mechanised and certainly not interoperable. Therefore, there is a clear need for a common machine readable method for representing the relationships between: 1. IP Entities 2. IP Entities and Roles 3. Roles A way to achieve the above is by implementing formal (machine readable) Ontologies that allow capturing definitions and their relationships in a constant and consistent fashion. One such ontology based on the DMP Creation Model is the RRD. This Use Case illustrates how the RRD as specified in Chapter 3 of IDP 3.1 can be used by several different Users to mutually declare complementary roles vis vis a common Content Item. 324
This Use Case is considered for illustrative purposes. Therefore it is not specifically recommended for implementation. 4.17.2 Tools for walkthrough #1 George has an MP3 file on his computer that he wishes to be used exclusively as a Manifestation of his Work in lieu of a written score and not as a performance for distribution to the general public. George is a registered user of RRD Ontology Access (ROA), an on line service where he can access an Ontology Application that runs an API that interfaces the latest version of the DMP RRD Ontology maintained as a standard OWL file format. The RRD Ontology supports the Roles: Creator, Adaptor, Instantiator, Producer and Distributor. Thus, George can Register his DCI as representing his Manifestation of his Work. The following table includes a step by step description of how George would achieve this. Who George Perform Make/ Register/ Identify George Enter George/ROA Mutually Authenticate George Access What DCI Notes User Creates, Registers and Identifies a DCI to Represent his Resource User accesses ROA The ROA uses a SAC The RRD application consists of a user interface that accesses the RRD OWL The ROA requires the Content Item for its Authentication The ROA needs to Authenticate the DCI and its ID A Role must be associated to identified User with respect to Content Items ID. With the Users declaration of Role, the RRD Application + RRD OWL knows what IP Entities can apply. The RRD Application offers the User the relevant IP-Entity options corresponding to the Role in this case: Work in Work-ManifestationCopy. 325 IDP Tool Represent Content none Out of scope RRD Ontology/API 2.10 Ref. 2.5.1

8.2.2.6.4

Protocol to Access Key
This Chapter 8 points to the reference implementation of the Access Key Protocol for Key Provider Device Any other Device. Package
8.2.3.1 Package as File This Chapter 8 points to the reference implementation of Package as File Tool for Content Creation Device Any other Device unPackaging a DCI in a file.
8.2.3.2 Package as Stream This Chapter 8 points to the reference implementation of Package as Stream Tool for Content Provider Device Any other Device unPackaging a DCI in a stream. Devices
8.2.4.1 Introduction A Value-Chain is typically made of a number of Devices managed by Users. Devices interact with other Devices using Protocols to exchange Data that are Represented as specified in AD #3. Therefore testing a Device for conformance makes only sense in the context of a particular ValueChain, even though it should be possible to isolate and test a set of Primitive Functions in a Device for conformance. A Content Creation Device can be tested for conformance in its ability to successfully Authenticate with another Device Register a Content Item with a Content Registration Agency Make a Content Item that is syntactically correct Etc.
A Content Consumption Device (SAV) can be tested for conformance in its ability to successfully Authenticate with another Device Join a Domain Management Device Authenticate a Content Item with a Content Registration Agency Use a Content Item, after o Accessing a License from a License Provider Device o Accessing a DRM Tool from a DRM Tool Provider Device Etc. 427
This Chapter 8 points to the reference implementation of the following reference Devices: Device Identification Device Content Creation Device Content Identification Device Content Provider Device License Provider Device DRM Tool Provider Device Domain Management Device Content Consumption Device (SAV)
These can be used as a basis for extending the functionality of reference Devices needed for setting up Conformance testing environments for specific Value-Chains.

8.3 Certification issues

A Device shall have been designed and manufactured so that the cost for an attacker to 1. 2. 3. 4. Extract cryptographic secrets Alter embedded identities Defeat Authentication, DCI decoding and Rights Expression interpretations Defeat Encryption/Decryption functionalities

<xsd:complexContent> <xsd:extension base="rel-r:LicensePart"> <xsd:sequence> <xsd:element ref="rel-r:anXmlPatternAbstract" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="varName" type="rel-r:VariableName"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:element name="grant" type="rel-r:Grant" substitutionGroup="rel-r:resource"/> <xsd:element name="grantGroup" type="rel-r:GrantGroup" substitutionGroup="relr:resource"/> <xsd:element name="keyHolder" type="rel-r:KeyHolder" substitutionGroup="relr:principal"/> <xsd:element name="issue" block="#all" substitutionGroup="rel-r:right" final="#all"> <xsd:complexType> <xsd:complexContent> <xsd:extension base="rel-r:Right" /> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:element name="issuer" type="rel-r:Issuer"/> <xsd:element name="license" type="rel-r:License"/> <xsd:element name="licensePart" type="rel-r:LicensePart"/> <xsd:element name="obtain" type="rel-r:Obtain" substitutionGroup="rel-r:right"/> <xsd:element name="possessProperty" type="rel-r:PossessProperty" substitutionGroup="relr:right"/> <xsd:element name="propertyAbstract" type="rel-r:PropertyAbstract" substitutionGroup="rel-r:resource"/> <xsd:element name="principal" type="rel-r:Principal" substitutionGroup="rel-r:resource"/> <xsd:element name="principalPatternAbstract" type="rel-r:PrincipalPatternAbstract" substitutionGroup="rel-r:resourcePatternAbstract"/> <xsd:element name="propertyPossessor" type="rel-r:PropertyPossessor" substitutionGroup="rel-r:principalPatternAbstract"/> <xsd:element name="resource" type="rel-r:Resource" substitutionGroup="relr:licensePart"/> <xsd:element name="resourcePatternAbstract" type="rel-r:ResourcePatternAbstract" substitutionGroup="rel-r:anXmlPatternAbstract"/> <xsd:element name="right" type="rel-r:Right" substitutionGroup="rel-r:licensePart"/> <xsd:element name="serviceDescription" type="rel-r:ServiceDescription" substitutionGroup="rel-r:licensePart"/> <xsd:element name="serviceReference" type="rel-r:ServiceReference" substitutionGroup="rel-r:resource"/> <xsd:element name="trustedRootIssuers" type="rel-r:TrustedRootIssuers" substitutionGroup="rel-r:trustRoot"/> 613

<simpleContent> <extension base="mpeg7:TextualType"> <attribute name="preferred" type="boolean" use="optional"/> </extension> </simpleContent> </complexType> </element> <element name="Definition" type="mpeg7:TextualType" minOccurs="0"/> </sequence> <attribute name="href" type="mpeg7:termReferenceType" use="required"/> </complexType> <complexType name="TVAAgentType"> <sequence> <choice minOccurs="0" maxOccurs="unbounded"> <element name="PersonName" type="mpeg7:PersonNameType"/> <element name="PersonNameIDRef"> <complexType> <attribute name="ref" type="tva:TVAIDRefType" use="required"/> </complexType> </element> <element name="OrganizationName" type="mpeg7:TextualType"/> <element name="OrganizationNameIDRef"> <complexType> <attribute name="ref" type="tva:TVAIDRefType" use="required"/> </complexType> </element> </choice> </sequence> </complexType> <attributeGroup name="fragmentIdentification"> <attribute name="fragmentId" type="tva:TVAIDType" use="optional"/> <attribute name="fragmentVersion" type="unsignedLong" use="optional"/> </attributeGroup> <annotation> <documentation xml:lang="en"> ======== Section 5.3.4 DESCRIPTION</documentation> </annotation> <complexType name="KeywordType"> <simpleContent> <extension base="mpeg7:TextualType"> <attribute name="type" use="optional" default="main"> <simpleType> <restriction base="NMTOKEN"> <enumeration value="main"/> 626
<enumeration value="secondary"/> <enumeration value="other"/> </restriction> </simpleType> </attribute> </extension> </simpleContent> </complexType> <complexType name="GenreType"> <complexContent> <extension base="tva:ControlledTermType"> <attribute name="type" use="optional" default="main"> <simpleType> <restriction base="string"> <enumeration value="main"/> <enumeration value="secondary"/> <enumeration value="other"/> </restriction> </simpleType> </attribute> </extension> </complexContent> </complexType> <simpleType name="SynopsisLengthType"> <restriction base="string"/> </simpleType> <complexType name="SynopsisType"> <simpleContent> <extension base="mpeg7:TextualType"> <attribute name="length" type="tva:SynopsisLengthType" use="optional"/> </extension> </simpleContent> </complexType> <complexType name="RelatedMaterialType"> <sequence> <element name="HowRelated" type="tva:ControlledTermType" minOccurs="0"/> <element name="Format" type="tva:ControlledTermType" minOccurs="0"/> <element name="MediaLocator" type="mpeg7:MediaLocatorType"/> <element name="PromotionalText" type="mpeg7:TextualType" minOccurs="0" maxOccurs="unbounded"/> <element name="SourceMediaLocator" type="mpeg7:MediaLocatorType" minOccurs="0"/> </sequence> </complexType> <complexType name="CreditsItemType"> 627

</owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:about="#PublicCommunication"/> </rdfs:subClassOf> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Transfer a file or program from a central computer to a smaller computer or to a computer at a remote location</rdfs:comment> </owl:Class> <owl:Class rdf:ID="MakeWorkManifestation"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >The action of making a Manifestation from Work.</rdfs:comment> <owl:disjointWith> <owl:Class rdf:ID="MakeAdaptationManifestation"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#RightGivenBy"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:ID="Creator"/> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="ResultsIn"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:ID="WorkManifestation"/> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Class rdf:about="#MakeManifestation"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#CreateWork"> <owl:disjointWith> <owl:Class rdf:about="#ModifyCopy"/> </owl:disjointWith> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >The action of creating a Work without any previous meterial.</rdfs:comment> <owl:disjointWith> <owl:Class rdf:about="#MakeCopy"/> </owl:disjointWith> 651
<owl:disjointWith> <owl:Class rdf:about="#MoveContent"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Produce"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#MakeAdaptation"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#MakeInstance"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#MakeManifestation"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Synchronization"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#PublicCommunication"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Restriction> <owl:valuesFrom> <owl:Class rdf:ID="Work"/> </owl:valuesFrom> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> <owl:onProperty> <owl:ObjectProperty rdf:about="#ResultsIn"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#Distribute"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:about="#Action"/> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Render"/> </owl:Class> <owl:Class rdf:ID="Adaptation"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A Work that is derived from another Work.</rdfs:comment> <rdfs:subClassOf> <owl:Class rdf:ID="IPEntity"/> </rdfs:subClassOf> 652

parameterOrder="authReqString"> <wsdl:input message="impl:processAuthReqRequest" name="processAuthReqRequest" /> <wsdl:output message="impl:processAuthReqResponse" name="processAuthReqResponse" /> </wsdl:operation> <wsdl:operation name="processLeaveDevice" parameterOrder="leaveDeviceString"> <wsdl:input message="impl:processLeaveDeviceRequest" name="processLeaveDeviceRequest" /> <wsdl:output message="impl:processLeaveDeviceResponse" name="processLeaveDeviceResponse" /> </wsdl:operation> </wsdl:portType> <wsdl:binding name="LeaveDeviceProcessorSoapBinding" type="impl:LeaveDeviceService"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="processAuthReq"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="processAuthReqRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://services.dmd.chillout.dmp.org" use="encoded" /> </wsdl:input> <wsdl:output name="processAuthReqResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost:8080/chillout_dmd/services/LeaveDeviceProcessor" use="encoded" /> </wsdl:output> </wsdl:operation> <wsdl:operation name="processLeaveDevice"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="processLeaveDeviceRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://services.dmd.chillout.dmp.org" use="encoded" /> </wsdl:input> <wsdl:output name="processLeaveDeviceResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost:8080/chillout_dmd/services/LeaveDeviceProcessor" 710
use="encoded" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="LeaveDeviceServiceService"> <wsdl:port binding="impl:LeaveDeviceProcessorSoapBinding" name="LeaveDeviceProcessor"> <wsdlsoap:address location="http://localhost:8080/chillout_dmd/services/LeaveDeviceProcessor" /> </wsdl:port> </wsdl:service> </wsdl:definitions> Figure 388 The Leave Device Protocol WSDL description

F.4.6 Leave user

<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="http://localhost:8080/chillout_dmd/services/LeaveUserProcessor" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://localhost:8080/chillout_dmd/services/LeaveUserProcessor" xmlns:intf="http://localhost:8080/chillout_dmd/services/LeaveUserProcessor" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <wsdl:message name="processLeaveUserRequest"> <wsdl:part name="leaveUserString" type="xsd:string" /> </wsdl:message> <wsdl:message name="processAuthReqResponse"> <wsdl:part name="processAuthReqReturn" type="xsd:string" /> </wsdl:message> <wsdl:message name="processAuthReqRequest"> <wsdl:part name="authReqString" type="xsd:string" /> </wsdl:message> <wsdl:message name="processLeaveUserResponse"> <wsdl:part name="processLeaveUserReturn" type="xsd:string" /> </wsdl:message> <wsdl:portType name="LeaveUserService"> <wsdl:operation name="processAuthReq" parameterOrder="authReqString"> <wsdl:input message="impl:processAuthReqRequest" name="processAuthReqRequest" /> <wsdl:output message="impl:processAuthReqResponse" name="processAuthReqResponse" /> </wsdl:operation>

conduct their business, it is hard to define today what kinds of standards are required, much less to forecast what kinds of standard will be needed in the future. The DMP approaches the problem of DRM Interoperability by specifying individual technologies that DMP calls Tools required to implement what DMP calls Primitive Functions. These are smaller functions obtained when the functions value-chain users perform when they do business between themselves are broken down into more atomic elements. It is expected that, while functions may undergo substantial changes as a consequence of the evolution of the media business in the value-chain, Primitive Functions will generally remain more stable and may just need to be augmented with new technologies. Therefore the DMP is not developing a universal DRM standard capable of providing interoperability between every variety of different Users in arbitrary Value-Chains or across different Value-Chains. The DMP provides specifications of Tools enabling Primitive Functions along with examples of how Value-Chains serving specific goals can be set up using the standard Tools. The DMP specifications are developed in phases, so as to achieve gradual development of standards technologies. The DMP approach to DRM standardisation is based on the following process 1. 2. 3. 4. 5. 6. For each phase Use Cases deemed to be significant are identified and documented; Primitive Functions required to implement the selected Use Cases are singled out; Requirements for Primitive Functions are developed through inputs from relevant Users; Tools serving the needs represented by the Use Cases are standardised; Calls for Proposals for Tools with the identified requirements are issued; The Tools are selected and documented through an open process. DMP favours Tools that have already been developed, standardised or adopted by other bodies, possibly adapting them to DMP needs; 7. Specifications of how Tools can be assembled to implement the selected Use Cases are developed; 8. In subsequent phases, Calls for Proposals for additional Tools needed to support new Primitive Functions or additional functionalities of existing Tools are issued. The DMP calls the ensemble of all standardised DRM Tools Interoperable DRM Platform (IDP). The IDP provides several major advantages: 1. The specifications are industry agnostic, i.e. Users are free to build a great variety of ValueChains that suit their business models by combining just the Tools that are appropriate for them; 2. The capabilities of a Value-Chain or new Value-Chains can be extended by adding more Tools, possibly through additional standardisation; 3. The cost to access standardised Tools may be reduce because in general Tools have multiple usages and may be provided by multiple suppliers; 4. Full interoperability can be achieved within a Value-Chain; 5. An enhanced degree of interoperability can be achieved between different Value-Chains; 6. Innovation can be continuously fed in the system.

3.2.13.2.1

ipmpmsg:ToolMessageBase
All DRM Message Containers are based on the ipmpmsg:ToolMessageBase element, defined in the following Figure: <element name="ToolMessageBase" type="ipmpmsg:ToolMessageBaseType" abstract="true"/> <complexType name="ToolMessageBaseType" abstract="true"> <complexContent> <extension base="ipmpmsg:IPMPBaseType"> <sequence> <element name="Sender" type="xsd:unsignedInt"/> <element name="Recipient" type="xsd:unsignedInt"/> </sequence> </extension> </complexContent> </complexType> Figure 81: The ipmpmsg:ToolMessageBase element The abstract element ipmpmsg:ToolMessageBase extends ipmpmsg:IPMPBaseType by adding Sender and Recipient elements to the message. These elements contain an unsigned integer 125
representing the unique Identifier that the DRM Processor assigns to each instance of a DRM Tool, the DRM Tool Context ID. The DRM Processor shall be Identified by the value 0.

3.2.13.2.2

ipmpmsg:Data_BaseClass
All DRM Messages extend the ipmpmsg:Data_BaseClass element, as specified in the Figure below: <element name="Data_BaseClass" type="ipmpmsg:Data_BaseClassType" abstract="true"/> <complexType name="Data_BaseClassType" abstract="true"> <complexContent> <extension base="ipmpmsg:IPMPBaseType"> <sequence> <element name="dataID" type="unsignedInt"/> </sequence> </extension> </complexContent> </complexType> Figure 82: The ipmpmsg:Data_BaseClass element The abstract element ipmpmsg:Data_BaseClass extends the ipmpmsg:IPMPBaseType element by adding the dataID element, which shall contain an unsigned integer value identifying a Message. The same value of dataID shall be used in any reply to that message.

3.2.13.2.3

ipmpmsg:MessageFromDI
Any DRM Message extracted from the DCI during its Parsing by the DRM Processor and addressed to a DRM Tool shall be conveyed to that DRM Tool by encapsulation in a ipmpmsg:MessageFromDI message, which is specified in the Figure below: <element name="MessageFromDI" type="ipmpmsg:MessageFromDIType" substitutionGroup="ipmpmsg:ToolMessageBase"/> <complexType name="MessageFromDIType"> <complexContent> <extension base="ipmpmsg:ToolMessageBaseType"> <sequence> <element ref="ipmpmsg:Data_BaseClass" minOccurs="0" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType> Figure 83: The ipmpmsg:MessageFromDCI element The ipmpmsg:MessageFromDCI element (indirectly) extends the ipmpmsg:ToolMessageBase element by adding a sequence of DRM Messages extending the ipmpmsg:Data_BaseClass.

<complexContent> <extension base="msdp:DomainProtocolType"> <sequence> <element name="ChildDomainID" type="msd:DomainIDType"/> <element name="ChildDomainCredentials" type="msd:DomainCredentialType"/> <element name="ParentDomainID" type="msd:DomainIDType"/> <element name="ParentDomainCredentials" type="msd:DomainCredentialType"/> </sequence> </extension> </complexContent> </complexType> Figure 150: The dmp-msdpx:AddDomainRequest element 3.2.19.21 ConnectChildDomain The ConnectChildDomain message is sent by the DMD managing the child domain to the DMD managing the father Domain if the Domains involved in the AddDomain protocol are not managed by the same DMD. As shown in the figure below, the ConnectChildDomain contains the ChildDomainInfo element conveying information about the Domain that will become child Domain. <element name="ConnectChildDomain" type="dmp-msdpx:ConnectChildDomainType"/> <complexType name="ConnectChildDomainType"> <complexContent> <extension base="msdp:DomainProtocolType"> <sequence> <element ref="dmp-msdx:ChildDomainInfo"/> </sequence> </extension> </complexContent> </complexType> Figure 151: The dmp-msdpx: ConnectChildDomain element 3.2.19.22 ConnectParentDomain The ConnectParentDomain message is sent in response to a ConnectChildDomainInfo message. As shown in the figure below, the ConnectParentDomain conveys the ParentDomainInfo of the requested Domain in order to share with the DMD managing the child Domain the DomainCredential of the parent Domain. <element name="ConnectParentDomain" type="dmp-msdpx:ConnectParentDomainType"/> <complexType name="ConnectParentDomainType"> <complexContent> <extension base="msdp:DomainProtocolType"> <sequence> <element ref="dmp-msdx:ParentDomainInfo"/> </sequence>
</extension> </complexContent> </complexType> Figure 152: The dmp-msdpx: ConnectParentDomain element 3.2.19.23 UpdateParentDomain The UpdateParentDomain message is sent to all DMDs managing a parent Domain when DomainManageInfo is updated as a result of an AddDomain, LeaveDomain, AddDevice, Leave Device, AddUser and LeaveUser protocol. In case of a hierarchy of Domains, UpdateParentDomain messages are also sent recursively until all parent Domains have been notified. <element name="UpdateParentDomain" type="dmp-msdpx:UpdateParentDomainType"/> <complexType name="UpdateParentDomainType"> <complexContent> <extension base="msdp:DomainProtocolType"> <sequence> <element name="ParentDomainCredentials" type="msd:DomainCredentialType"/> <element ref="dmp-msdx:ChildDomainInfo"/> </sequence> </extension> </complexContent> </complexType> Figure 153: The dmp-msdpx: UpdateParentDomain element 3.2.19.24 UpdateChildDomain The UpdateChildDomain message is sent to all DMDs managing a child Domain when DomainManageInfo is updated as a result of an AddDomain, LeaveDomain, AddDevice, Leave Device, AddUser and LeaveUser protocol. In case of a hierarchy of Domains, UpdateChildDomain messages are also sent recursively until all child Domains have been notified. <element name="UpdateChildDomain" type="dmp-msdpx:UpdateChildDomainType"/> <complexType name="UpdateChildDomainType"> <complexContent> <extension base="msdp:DomainProtocolType"> <sequence> <element name="ChildDomainCredentials" type="msd:DomainCredentialType"/> <element ref="dmp-msdx:ParentDomainInfo"/> </sequence> </extension> </complexContent> </complexType> Figure 154: The dmp-msdpx: UpdateChildDomain element

ii) a valid License ID is specified in the request c) Verifies that there is a License on the system, or that the requesting Device is entitled to be Issued a License (1) for the specific Content ID or (2) for a specific Resource identified by the ResourceID parameter contained within a Content Item identified by the ContentID parameter 7) In the case the request can be satisfied, the License Provider Device: a) generates a msap:RequesLicenseResult message [Figure 133] containing the License. The License may include decryption Keys that are encrypted with: i) The Device public Key in the case of Device License; ii) The Domain public Key in case of Domain License; b) Delivers the msap:RequesLicenseResult message to the requesting Device: 8) In the case the request cannot be satisfied, the License Provider Device generates and sends to the requesting Device an msdp:Ack message [Figure 125] conveying the information related to the reason of failure. 9) The requesting Device: a) receives the message from the License Provider Device, verifies the message contents and: b) (optionally) replies with a msbp:Ack message [Figure 125] 3.3.4.3 Protocol to Access DRM Tool Body This protocol is performed by a SAV or a CCD when the DRM Tool Body is not available on the SAV (and not conveyed in the DCI) for allowing the access to Protected Resources or on the CCD for Protecting Resources. This Protocol comprises of the following steps: 1) The requesting Device and the TPD mutually Authentiate (See 3.3.2.1 Protocols to Authenticate Device); 2) The requesting Device a) Mutually Authenticates with the DRM Tool Provider Device. The URL of the DRM Tool Provider Device is contained in the ipmpinfo:Remote element in the DI b) Sends a msap:RequestIPMPToolBody message [Figure 127] to the IPMP Tool Provider Device, containing: i) The requested IPMP Tool ID ii) The Represent Device Information Structure describing the hardware and software characteristics of the Device on which the requested DRM Tool will run. iii) The digital Signature of the whole message 3) The DRM Tool Provider Device: a) Receives the message; b) Verifies the signature if present; c) Reads Device Information d) Locates the DRM Tool Body matching the requesting Device's characteristics contained within Device Information e) Wraps the DRM Tool Body in an ipmpinfo-msxToolBody structure; f) Delivers the msap:RequestIPMPToolBodyResponseToolBody [Figure 128] to the requesting Device. 4) The requesting Device: a) Receives msap:RequestIPMPToolBodyResponse 217

<dmp2rc:Metadata> <dmp2rc:StructuredData ref="urn:mpeg:mpeg7:schema:2001"> <!-- Metadata for video track--> </dmp2rc:StructuredData> </dmp2rc:Metadata> </dmp2rc:DMPInformation> </Statement> </Descriptor> <Component> <Resource mimeType="application/mp21-ipmp"> <dmp2_ipmpdidl:ProtectedAsset mimeType="video/mpeg"> <dmp2_ipmpdidl:Info> <dmp2_ipmpinfo:IPMPInfoDescriptor> <dmp2_ipmpinfo:RightsDescriptor> <dmp2_ipmpinfo:LicenseReference>urn:myLicenses:6789A</dmp2_ipmpinfo:LicenseReferenc e> </dmp2_ipmpinfo:RightsDescriptor> </dmp2_ipmpinfo:IPMPInfoDescriptor> </dmp2_ipmpdidl:Info> <dmp2_ipmpdidl:Contents ref="VideoRecording5678.mpg"/> </dmp2_ipmpdidl:ProtectedAsset> </Resource> </Component> </Item> <Item> <Descriptor> <Statement mimeType="text/xml"> <dmp1_dii:Identifier>urn:Leonardo:Presentations:2222</dmp1_dii:Identifier> </Statement> </Descriptor> <Descriptor> <Statement mimeType="text/xml"> <dmp2rc:DMPInformation> <dmp2rc:Metadata> <dmp2rc:StructuredData ref="urn:mpeg:mpeg7:schema:2001"> <!-- Metadata for the slide presentation--> </dmp2rc:StructuredData> </dmp2rc:Metadata> </dmp2rc:DMPInformation> </Statement> </Descriptor> <Component> <Resource mimeType="application/mp21-ipmp"> <dmp2_ipmpdidl:ProtectedAsset mimeType="application/vnd.ms-powerpoint"> <dmp2_ipmpdidl:Info> <dmp2_ipmpinfo:IPMPInfoDescriptor> 238
<dmp2_ipmpinfo:RightsDescriptor> <dmp2_ipmpinfo:LicenseReference>urn:myLicenses:6789A</dmp2_ipmpinfo:LicenseReferenc e> </dmp2_ipmpinfo:RightsDescriptor> </dmp2_ipmpinfo:IPMPInfoDescriptor> </dmp2_ipmpdidl:Info> <dmp2_ipmpdidl:Contents ref="conferencePresentation33.ppt"/> </dmp2_ipmpdidl:ProtectedAsset> </Resource> </Component> </Item> </Item> </Container> </DIDL> Figure 211 Example DCI for the Open Release Content 4.2.2.2 Consumption End User Luigi, a conference participant, wishing to Use an Open Release Content Item, performs the following steps: Who Luigi Luigi Luigi Perform Access Un-Package Use What Content Item Content Item Content Item Notes IDP Tool Access Content Package Content Represent Content Elements Ref. 3.6.1 4.1.1 2.

4. The Board of Directors shall select and propose the appointment of one candidate Certification Authority to the General Assembly within 180 days of the deadline indicated in the Call for Participation for submitting Applications; 5. The General Assembly shall appoint the Certification Authority based on the proposal made by the Board of Directors; 6. Once appointed, the Certification Authority may receive applications from applicants wishing to become Certification Agencies; 7. The Certification Authority shall review the application for compliance with the Certification Policy; 8. In case an application is rejected, the applicant may appeal to the Board of Directors; 9. The Board of Directors will issue a final judgement on the appeal; 10. The Board of Directors will inform the Certification Authority and the appealing Certification Agency of its decision within 90 days of the date of appeal; 11. If a Certification Authority, resigns the matter will be brought to the attention of the General Assembly for action. 5.2.2 Qualification Requirements for a Certification Authority To qualify for appointment as a Certification Authority an organization shall demonstrate that: 1. It is a legal entity; 2. It has been in existence for no less than five years; 3. It enjoys a sound financial structure; 4. It is familiar with the field in which it applies to operate as an Authority; 5. It has employees who are technically competent in Certification of the relevant Entity and are in number deemed to be sufficient to handle the expected workload; 6. It does not have a direct economic stake in the related business; 7. It commits to function in its capacity as a Certification Authority for a minimum of ten years; 8. It has sufficient equipment resources (e.g., hardware, software) and communication facilities (e.g., postal street address, telephone, facsimile, e-mail, ftp and web site); 9. The fee structure, if one is envisaged, shall be for the purpose of cost recovery, and shall be approved as part of the appointment; 10. It shall require no financial contribution from DMP and its members; 11. It shall not become a Certification Agency. 5.2.3 Procedure to appoint a Certification Authority The following procedure shall be invoked whenever DMP identifies the need for a Certification Authority: 1. The General Assembly shall draft a Call for Participation; 2. The Board of Directors shall issue the Call for Participation by the time indicated by the General Assembly; 3. Prospective Certification Authorities shall submit an application indicating a. How the requirements of the Call for Participation are fulfilled; b. The time the Certification Authority will start accepting applications from candidate Certification Agencies; c. The criteria for accepting or rejecting applications for Certification Agencies to be applied in a strictly non-discriminatory fashion;

Figure 258 Chillout SAV package overview 361
7.4.1.3.1 The savmessenger package
The package contains the Talker classes that SAV uses to communicate with other devices via Web Services. The CommunicationManager class is the manager of all the talker classes. It instantiates talkers for CPD, DMD, LPD and TPD. Each talker sits in a separate folder. They function as the client side of the Web Services. They are implemented following the Java event model. When talker gets a response from the other party, it wraps up the request result object in an event object and dispatches it to listeners to notify them of the result.Relationship with other Devices

7.4.1.3.2 LPD

When a license is not bundled within the Content, CCD will talk to LPD to store the License in LPDs storage. This process is defined as CCD-LPD protocol. For more information, see the Store License walkthrough section in the introduction of LPD device.

7.4.1.3.3 DMD

As shown the figure below, DMD manages Domain in co-operation with DoID, LPD, SAV and DomainAdministrator. First of all, DomainAdministrator initiates the CreateDomain protocol to DMD. DMD creates DomainID and DomainaManageInfo for the newly created Domain with DoID. After the creation of Domain, the protocols between SAV and DMD are used to deliver the Domain membership to SAV.
Figure 259 Domain set up 7.4.1.4 Software prerequisites The chillout_sav library depends on the chillout_core and the chillout_auxiliary library. Additionally, in order to use the chillout_sav library the Apache Ant [59] software is required. 7.4.1.5 Usage

7.4.1.5.1 Playing a DCF

The SAV can be used to play DCFs (DMP Content Files), DCIs where Content Items are packaged as DCS (DMP Content Stream) as well as un-Governed Media Resources encoded in a number of formats. Some pre-encoded DCFs are available on the Chillout ftp repository at the following URL: http://wiki.dmpf.org/files/download/DCFs/.
7.4.1.5.2 Accessing a License from an LPD
If a valid License is not included in the DCI, but a License Reference is signaled in the DCI, the SAV will perform the Access License Protocol with the LPD specified in that field.

SAV can include in the message the ID of the content that it wants to consume and the License it wants to have (Intended License). In this case, LPD will validate the Intended License against all Licenses it finds in its DB for that specific content. 1.2.1 If the Intended License agrees with any of the Licenses in DB, the validation is regarded as successful. Then LPD will encrypt the content master key with SAVs public key, put the key in the Intended License, sign it and send it back to SAV. 1.2.2 If the Intended License agrees with none of the Licenses in DB, LPD will deny the request.
Get DomainInfo walkthrough This function is based on the LPD-DMD protocol and is currently under development. LPD Administration walkthrough This function is based on Webworks GUI and is currently under development. LPD User walkthrough This function is based on Webworks GUI and is currently under development. LPD database There are 3 tables in the LPD database: ? ? LicenseTemplate table: used to store the Licenses sent through from CCD devices. LicencingRecord table: used to keep record of Licenses that have been issued to different SAV devices. Resourceinfo table: stores information for content resource encryption.
7.4.5.3 Package description
Figure 274 Overview of the LPD package 1. In the Java source folder, there are the following packages:
Database package Its implemented based on Hibernate technology. a) base folder Base classes generated by Hibernate that map onto database tables. b) dao folder DAO objects that can be used by Business Logic layer. Users can extend them to add their own data access operations. iface interface classes other files utility classes that implement the iface interfaces c) Other files in the Database package Java classes that extend the Base DB-mapping classes. User can customize these classes to add their own properties and logics. 2. Management package This package includes the classes that connect Hibernate-based DAO layer with the Springbased Business Logic layer 3. Services package This package includes the classes that implement the Web services of LPD. It is the core package of the LPD device. In the Resources folder, there are configuration files for DB, logging and internationalization.
The webapp folder contains supporting files for web interfaces of LPD.
The Test folder contains client applications that can be used to test and debug the LPD Web Services. 7.4.5.4 Relationship with other Devices

7.4.5.4.1 CCD

When CCD wants to store a license in LPD, it should start the license storage process as described above in the Store License walkthrough.

7.4.5.4.2 SAV

When SAV want to use a content that is governed by a License that is not bundled with the content, it should talk to LPD to ask for a License. The process should be carried out as described in the Issue License walkthrough.

7.4.6.2.2 DID database

The Device Identification Device stores device id information in a database which is based on MYSQL.Table name is tbl_didemap. 7.4.6.3 Package description
Figure 276 Overview of the DID package
7.4.6.3.1 The core package
The core package contains the all core classes needed to create a X.509 certificate. The following classes are defined in this package: l Base64 This class implements a BASE64 Character encoder/decoder as specified in RFC1521. l CreateSerialNumber This class is use for generate a serial number. l DIDXmlProc
o Parse request message. o marshal dmp2mdi:DeviceID message l EJBCAProc This class is use for operation EJBCA
7.4.6.3.2 The dao package
The dao package contains the all classes needed to operate database. The following classes are defined in this package: l HibernateSessionFactory This class Configures and provides access to Hibernate sessions, tied to the current thread of execution. l DideDao This class define all functions need to operate database. l DideMap This class is a map layer from database table to java class.
7.4.6.3.3 The webservice package
The webservice package contains webservice interface and its implement classes. The following are defined in this package: l IdentifyDeviceProtocolService Webservice interface. l IdentifyDeviceProtocolServiceImpl Webservice interface implement. 7.4.6.4 Relationship with other Devices

7.4.6.4.1 CCD

7.4.6.4.2 SAV

7.4.6.4.3 LPD

7.4.6.4.4 CPD

7.4.6.4.5 CID

7.4.6.4.6 DMD

7.4.6.4.7 TPD

This feature is currently under development. 7.4.6.5 Software prerequisites The chillout_did library depends on the chillout_core and the chillout_auxiliary library. Additionally, in order to use the chillout_did library the EJBCA and MYSQL software is required. 7.4.6.6 Usage The Device Identification Device supports the following functionalities: 7.4.7 DMD 7.4.7.1 Scope The Domain Management Device enables the creation of groups of Devices of Users. 7.4.7.2 Overview As shown the figure below, DMD manages Domain in co-operation with DoID, LPD, SAV and DomainAdministrator. First of all, DomainAdministrator initiates the CreateDomain protocol to DMD. DMD creates DomainID and DomainaManageInfo for the newly created Domain with DoID. In this process, LocalDomainID created by DoID is sent to DMD by using LocalDomainIDRequest and LocalDomainIDResponse messages,. Then its combined with DomainManagerID and becomes DomainID. After the creation of Domain, the protocols between SAV and DMD are used to deliver the Domain membership to SAV. When a Domain bound content is requested, LPD is informed DomainID by application dependant means, then the LPD issues RequestKey protocol to DMD to get the corresponding DomainKey. Finally the domain bound license can be created by encrypting the content key with the DomainKey.

<complexType name="AlternateGroupType"> <attribute name="groupID" type="positiveInteger" use="required"/> </complexType> <element name="LicenseCollection" type="ipmpinfo-msaf:LicenseCollectionType"/> <complexType name="LicenseCollectionType" mixed="true"> <sequence> <element ref="ipmpinfo-msaf:RightsDescriptor" maxOccurs="unbounded"/> </sequence> </complexType> </schema> Figure 303: The ipmpinfo-msaf schema C.10 The Media Streaming IPMPINFO extensions schema The schema characterised by the following URI: urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007 is given below. <?xml version="1.0"?> <schema targetNamespace="urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ipmpinfomsx="urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:rmsaf="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:ipmpinfo-msaf="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS" xmlns:mpeg4ipmp="urn:mpeg:mpeg4:IPMPSchema:2002" elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.01"> <import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-coreschema.xsd"/> <import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/> <import namespace="urn:mpeg:mpeg4:IPMPSchema:2002" schemaLocation="http://www.dmpf.org/schemas/mpeg4ipmp.xsd"/> <!-- elements--> <!--********************************* --> <!-ToolBody --> <!--********************************* --> <element name="ToolBody" type="ipmpinfo-msx:ToolBodyType"/> <complexType name="ToolBodyType"> <sequence> <choice maxOccurs="unbounded"> <element ref="ipmpinfo-msx:SingleTool"/> <element ref="ipmpinfo-msx:ToolPack"/> </choice> <element ref="dsig:Signature" minOccurs="0"/> 500

<whiteSpace value="collapse"/> </restriction> </simpleType> <simpleType name="TVAIDRefType"> <restriction base="string"> <whiteSpace value="collapse"/> </restriction> </simpleType> <simpleType name="TVAIDRefsType"> <list itemType="tva:TVAIDRefType"/> </simpleType> <simpleType name="CRIDType"> <restriction base="anyURI"> <pattern value="(c|C)(r|R)(i|I)(d|D)://.*/.*"/> </restriction> </simpleType> <complexType name="CRIDRefType"> <attribute name="crid" type="tva:CRIDType" use="required"/> </complexType> <complexType name="FlagType"> <attribute name="value" type="boolean" use="required"/> </complexType> <complexType name="TVATimeType"> <sequence> <element name="TimePoint" type="mpeg7:timePointType"/> <element name="Duration" type="mpeg7:durationType" minOccurs="0"/> </sequence> </complexType> <complexType name="ControlledTermType"> <sequence> <element name="Name" minOccurs="0"> <complexType> <simpleContent> <extension base="mpeg7:TextualType"> <attribute name="preferred" type="boolean" use="optional"/> </extension> </simpleContent> </complexType> </element> <element name="Definition" type="mpeg7:TextualType" minOccurs="0"/> </sequence> <attribute name="href" type="mpeg7:termReferenceType" use="required"/> </complexType> <complexType name="TVAAgentType"> <sequence> <choice minOccurs="0" maxOccurs="unbounded"> 578
<element name="PersonName" type="mpeg7:PersonNameType"/> <element name="PersonNameIDRef"> <complexType> <attribute name="ref" type="tva:TVAIDRefType" use="required"/> </complexType> </element> <element name="OrganizationName" type="mpeg7:TextualType"/> <element name="OrganizationNameIDRef"> <complexType> <attribute name="ref" type="tva:TVAIDRefType" use="required"/> </complexType> </element> </choice> </sequence> </complexType> <attributeGroup name="fragmentIdentification"> <attribute name="fragmentId" type="tva:TVAIDType" use="optional"/> <attribute name="fragmentVersion" type="unsignedLong" use="optional"/> </attributeGroup> <annotation> <documentation xml:lang="en"> ======== Section 5.3.4 DESCRIPTION</documentation> </annotation> <complexType name="KeywordType"> <simpleContent> <extension base="mpeg7:TextualType"> <attribute name="type" use="optional" default="main"> <simpleType> <restriction base="NMTOKEN"> <enumeration value="main"/> <enumeration value="secondary"/> <enumeration value="other"/> </restriction> </simpleType> </attribute> </extension> </simpleContent> </complexType> <complexType name="GenreType"> <complexContent> <extension base="tva:ControlledTermType"> <attribute name="type" use="optional" default="main"> <simpleType> <restriction base="string"> <enumeration value="main"/> 579

Other content sharing with members of a group is concurrent, where all members of the group witness a single rendering of the work simultaneously. Some types of content are typically for personal consumption (a book) this is an example of serial sharing, where the book can only be read by a single person at a time and is passed to other readers, either when the first reader has finished, or chapter-bychapter, between a husband and wife, for example.The book can be gifted or sold, with no infringement of the authors copyrights. Others are typically shared (newspapers, magazines) publishers of these works factor in the number of people that will typically consume a single copy into their business models, applying a multiplier to any sales of advertising impressions, for example.Newspapers and magazines are often supported entirely by advertising revenues. The marginal production cost of the additional impressions of an ad attributable to second and subsequent readers is precisely zero, since no additional copies of the ad have to be printed to make an impression, whereas the advertiser has accepted each copy to represent some multiple of impressions, agreed by reference to audited readership survey data.So there is economic advantage to the publisher of the magazine or newspaper in having the content shared. Some are typically enjoyed in a group (a movie, a broadcast) we like to gather in groups and watch things together, for the companionship of shared experience, to bond socially and to perhaps stimulate debate about the issues raised, after the movie or broadcast has finished.Sharing content with members of a group concurrently plays an important part in creating and maintaining social relationships. Some have both personal and group-wise consumption modalities (music) sometimes we listen to music to facilitate the euphoria of solitude, at other times to study it in concentrated detail, still other times as background sonic wallpaper to our daily activities and yet others as a group social event. Sometimes a member of the group, as the author of that work, owns the content that is shared, but often the contents author is a third party. 74 TRU to improve end-user The ability of an individual to create content and services that are experience expected to be of value to the end-user 75 TRU to choose security To choose a system on which enough trust can be put to use it together with sensitive information 76 TRU to restrict adaptation This is traditionally referred to as the right of adaptation and vests control in the creator over other's use of their work to create derivative works based on the original; in the event unauthorised adaptations are made, their copyright exists "without prejudice to the copyright in the original work" 77 TRU to restrict This is traditionally referred to as the right of performance and vests