Requirements for new or extended IDP-3 technologies

The list below gives technologies that are either not supported or insufficiently supported by IDP-2.

Represent

• Represent Content
  • Motivations:
    • IDP-2 DCI provides a subset of functionalities
  • Requirements
    • Support for nested DCIs
      • A DCI may have a hierarchical relationship with one or more DCIs
      • There must be means to establish forms of persistent relationship between DCIs
• Represent License
  • Motivation:
    • The Creative Commons licensing scheme is already widely used by Creators throughout the world: As REL does not provide all the elements to express Creative Commons licenses, IDP-2 unnecessarily restricts the number of Use Cases that can be covered by DMP and is possibly discriminatory against Creators willing to Release Content using Creative Commons licensing schemes.
  • Requirements
    • Proven ability to express all Permissions expressed in Creative Commons Licenses, including but not limited to
    • Ability to express in a License that Rights are granted to Everyone
    • Ability to express in a License that usages of Content are unlimited (e.g. unlimited Reuse of Works)
    • Ability to express in a License that Derivative Works must be governed by the same license
    • Extend the IDP-2 technology for Represent License
    • If this is impossible present a valuable alternative to the IDP-2 technology for Represent License
• Represent Rights Data (RRD)
  • Motivation:
    • Currently only AD #6 provides some semantics for Functions. This may not be sufficient to support all usages of Governed Content. The DMP requires support for use of Content throughout the Value Chain and has specified a set of Functions and Entities defined in the DMP Terminology.  The DMP also provides a succinct Creation Model (dmp0652) that structures IP in interdependent levels.
      Given the development of different ontologies related to the use of Content, it is of interest to the DMP to be made aware of the degree of support that technologies provide to the DMP Creation Model and current set of DMP Terminology or to a reasonable equivalent.
  • Requirements:
    • RRD shall support all value chain usages and become a full-fledged component of AD #3. The following is required
      • Support the DMP Creation Model (or equivalent).
      • Support the Functions and Entities defined in the DMP Terminology (or equivalent)
      • Support representation of all Permissions that a Value Chain User is willing to License to another Value Chain User
      • Can demonstrate the ontology implementation in DMP based use cases.
      • Provide means for extending the ontology.
      • Is a formal ontology i.e. fully automatable such as OWL.
  • Criteria for evaluation
    • Automatable.
    • Ease of use and implementation.
    • Comprehensiveness i.e. inclusion and richness of terms and definitions relevant to all holders of IP Rights in the Value Chain.
    • Simplicity i.e. minimum and sufficient semantic versus richness of meaningful relationships between Functions and Entities.
    • Clarity and ease for extending the proposed ontology.
    • Demonstrable i.e. automated means to interact with the tool to run use cases etc.
• Represent Use Data (RUD)
  • Motivation:
    • Currently AD #3 only supports a restricted set of Use Data, i.e. to enable simultaneous usage detection
  • Requirements: RUD shall support a broad range of usage description, e.g.
    • Typical usage within a home Domain
    • Use of IP Entities, e.g. diffuse Use of IP Entities
• Represent Metadata for protected DCI
  • Motivation:
    • A DCI may be protected, however, access to Clear-text Metadata shall be possible without applying the required Function to unprotect the DCI
  • Requirements:
    • The same structure for protected and unprotected DCI shall be used
    • In case of a nested DCI, a Clear-text description of the hierarchy of Metadata is required
    • The Representation shall be computationally affordable
    • It shall be possible to also have Metadata that are in the protected portion of the DCI
    • Once the protected portion of the DCI is unprotected the resulting DCI conforms to AD #3 Represent Content
• Represent Metadata for End User purposes
  • Motivation:
    • End User must be able to search for what he wants. However, IDP-2 only supports a subset of TV Anytime Metadata
  • Requirements:
    • A minimum sufficient and possibly small set of Metadata that can be packaged for End User distribution
    • The set shall be extensible to cover the needs of as many Value Chain Users as possible
    • The role of each Value Chain User shall be expressible to the End User
    • The technology is not meant to replace the existing ability to reference any Metadata scheme.
• Represent Metadata for inter-Value Chain User relationship
  • Motivation:
    • A minimum set of Metadata that can be used across all the Value Chain by all Value Chain Users
  • Requirements:
    • Ability to represent all Permissions that a Value Chain User is willing to License to another Value Chain User in terms of the RRD ontology
    • Status of the DCI, e.g. promotional, no further distribution

Protocols

• Protocols to Identify Content and DRM Tools
  • Motivation:
    • A standard Protocol to Identify Content and DRM Tools is required for Device interoperability
  • Requirements:
    • The relevant Resources Identifiers and DRM Tools are conveyed as specified by AD #3
    • The Content and DRM Tools Identifier establishes a unique, persistent and trusted correspondence between the Identifier and the Content and DRM Tools it Identifies
    • The Registration Agencies are an integral part of the DMP Trust set up
• Protocols to Identify Domain
  • Motivation:
    • A standard Protocol to Identify Domain created by a Domain Management Device is required for Device interoperability
  • Requirements:
    • Unique Identification
    • Avoid repudation
• Protocol to Identify Device (software)
  • Motivation:
    • A standard Protocol to Identify a (software) Device is required for Device interoperability
  • Requirements
    • It must rely on Device Information
    • It must be able to manage the “evolution” of the Device
• Protocols to Authenticate Content
  • Motivation:
    • A standard Protocol to do so is required to Authenticate Content before Use
  • Requirements:
    • The Protocol shall be designed so that Authentication can at least withstand hash attacks
    • The Protocol shall also include User Authentication
• Protocol to Authenticate Device with unique device data
  • Motivation:
    • A full Protocol to Authenticate a Device with unique device data is required
  • Requirements:
    • The ability for two Devices, at least one of them with unique device data, to Authenticate possibly via a proxy
• Protocol to Verify (software) Device
  • Motivation:
    • A Protocol to Verify, i.e. to check the Integrity of a Device is required
  • Requirements
    • Ability to detect typical attacks (e.g. corruption of software)
    • Ability to assess nature of the failure of the previous bullet point
    • Ability to resolve the result of the previous bullet point
• Protocol to Manage Processing Tool
  • Motivation:
    • Support dynamic addition of any type of processing on Content Elements to a Device
  • Requirements
    • Shall be a compatible extension to the Manage DRM Tool protocols
• Protocols to Deliver (Store, Move, Copy, Export, Backup, Access, Import, Restore.)
  • Motivation:
    • Currently AD #3 makes reference to several Delivery-related Functions. A standard version is required
  • Requirements:
    • Protocols shall exactly implement the semantics defined in AD #6
• Protocol to establish a SAC
  • Motivation:
    • This protocol is required by many data exchange protocols
  • Requirements
    • Must be an extension of the existing protocol to establish a SAC for DRM Tools
• Protocols to Negotiate License
  • Motivation:
    • IDP-2 assumes that a User obtains a License that has been determined by the Licensor. However, it may not always be possible for a Licensor to foresee all possible actions a Licensee may be willing to perform on a Content Item. As a consequence a License may prevent Licensees from performing actions on Content, even if they would have been willing to obtain such a License.
  • Requirements:
    • End-Users can express their agreement or disagreements with proposed License terms
    • The Protocol shall support changes to any parameter of the License (e.g. Principal, types of Use such Play, Copy)
    • The Protocol shall support automatic negotiation of license terms (e.g. Users can preselect the answers for certain types of Users and Use, Users need only intervene personally in case of doubt)
    • At every step a human readable license must be provided
    • The protocol shall enable the setting of certain parameters as non subject of negotiation, e.g. setting “no copy” or “time-shifted Use” as a mandatory feature of the License
    • The protocol shall allow the determination of the degree of confidentiality (no eavesdrop) of the protocol
    • The protocol shall not require revealing the real identities until the protocol has been successfully concluded
• Protocols to Manage Use Data Confidentiality
  • Motivation:
    • User A should be able to negotiate with User B the use that User B will make of Use Data of User A
  • Requirements:
    • Be based on Represent Use Data
    • Shall be able to identify and describe usages of Use Data in a machine processable form
    • Shall support the same features of “Protocols to Negotiate License”

Miscellanea

• Architecture of End-User Device
  • Motivation:
    • Currently AD #3 does not provide a full architecture
  • Requirements:
    • The architecture shall be
      • Generic so that it does not constrain the freedom of a designer and is open to future extensions
      • Specific so that interoperability between component parts of a Device is ensured
  • To be submitted
    • A description of the proposed architecture
    • A block diagram
    • Functional description of the blocks with interfaces
• Means to model Value Chains
  • Motivation:
    • IDP-2 establishes a foundation that allows building business functions (i.e. Functions recursively composed starting from Primitive Functions or Functions) and Value Chains. However, this feature is not actually exercised as an abstract framework that allows Value Chain Users to easily define business functions and Values Chains.
    • DMP requires an architectural approach and a technology to solve the gap between stable Primitive Functions on the one hand and mutable business functions and Value Chains on the other.
  • Requirements:
    • A component model and an architecture shall be proposed
    • The component model shall be aligned with the most robust IT standardization efforts (e.g. Web Service and Service Oriented Architecture);
    • The component model shall preserve interoperability at the Interoperable DRM Platform level, and business functions and Value Chains level;
    • The architecture shall preserve the independence of each User in Value Chain definition at technological level (i.e. each User in a Value Chain is free to offer the Business Functions he likes using the implementation of his choice);
    • The architecture shall allow any Value Chain to interoperate with any other Value Chain.
• Completion of existing technologies: e.g. Protocols
  • Motivation:
    • Further details may be needed to enable a bit-by-bit implementation
  • Requirements
    • Provide the necessary details