DECE Technical Specification: Content Publishing Requirements€¦ · DECE Confidential 7-Apr-15...

DECE Confidential 7-Apr-15

DECE Technical Specification: Content Publishing RequirementsVersion 0.5-MovieLabs-SPE2+Movielabs2

Working Group: Technical Working Group

Date: 10-062711-14-09

THE DECE CONSORTIUM ON BEHALF OF ITSELF AND ITS MEMBERS MAKES NO REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, CONCERNING THE COMPLETENESS, ACCURACY, OR APPLICABILITY OF ANY INFORMATION CONTAINED IN THIS SPECIFICATION. THE DECE CONSORTIUM, FOR ITSELF AND THE MEMBERS, DISCLAIM ALL LIABILITY OF ANY KIND WHATSOEVER, EXPRESS OR IMPLIED, ARISING OR RESULTING FROM THE RELIANCE OR USE BY ANY PARTY OF THIS SPECIFICATION OR ANY INFORMATION CONTAINED HEREIN. THE DECE CONSORTIUM ON BEHALF OF ITSELF AND ITS MEMBERS MAKES NO REPRESENTATIONS CONCERNING THE APPLICABILITY OF ANY PATENT, COPYRIGHT OR OTHER PROPRIETARY RIGHT OF A THIRD PARTY TO THIS SPECIFICATION OR ITS USE, AND THE RECEIPT OR ANY USE OF THIS SPECIFICATION OR ITS CONTENTS DOES NOT IN ANY WAY CREATE BY IMPLICATION, ESTOPPEL OR OTHERWISE, ANY LICENSE OR RIGHT TO OR UNDER ANY DECE CONSORTIUM MEMBER COMPANY’S PATENT, COPYRIGHT, TRADEMARK OR TRADE SECRET RIGHTS WHICH ARE OR MAY BE ASSOCIATED WITH THE IDEAS, TECHNIQUES, CONCEPTS OR EXPRESSIONS CONTAINED HEREIN.

© 2009

DRAFT: SUBJECT TO CHANGE WITHOUT NOTICE


DECE LLC

www.dece.net


http://www.dece.net/

Contents

1 Introduction............................................................................................................................................... 41.1 Document Purpose............................................................................................................................ 41.2 Document Notation and Conventions................................................................................................4

2 Document Structure.................................................................................................................................. 62.1 Nature of Publishing Requirements...................................................................................................62.2 Scope and Structure of this Document..............................................................................................62.3 Relationship to Other DECE Specifications.......................................................................................7

2.3.1 Media Format Specification........................................................................................................72.3.2 Picture Format Specification.......................................................................................................72.3.3 Metadata Specification...............................................................................................................72.3.4 Coordinator Interface Specification............................................................................................72.3.5 DSP/Device Interface Specification............................................................................................82.3.6 DRM Profile Specification...........................................................................................................8

3 Publishing Information Model.................................................................................................................... 93.1 SKUProduct....................................................................................................................................... 93.2 Content and Rights............................................................................................................................ 9

3.2.1 Content Structure and Identification...........................................................................................93.2.2 Logical Asset............................................................................................................................ 113.2.3 Profile....................................................................................................................................... 113.2.4 Right and Rights Token............................................................................................................113.2.5 Bundle...................................................................................................................................... 12

3.3 Containers and Files........................................................................................................................133.3.1 Origin DECE Common Container (ODCC)...............................................................................13

3.4 Logical Asset................................................................................................................................... 133.5 Rights Profile................................................................................................................................... 133.6 Content Metadata............................................................................................................................ 14

3.6.1 Physical Asset.......................................................................................................................... 143.6.2 Provisioned DECE Common Container (PDCC)......................................................................143.6.3 File........................................................................................................................................... 153.6.4 File Metadata............................................................................................................................ 15

3.7 Logical to Physical Mapping (L2PM)...............................................................................................153.8 Encoding.......................................................................................................................................... 15

3.8.1 Source A/V Materials................................................................................................................153.8.2 Picture Format..........................................................................................................................16

3.9 Asset Metadata................................................................................................................................ 163.10 Physical Asset Metadata...............................................................................................................163.11 DRM.............................................................................................................................................. 16

3.11.1 Keyset.................................................................................................................................... 163.12 Picture Format............................................................................................................................... 173.13 Origin DECE Common Container (ODCC)....................................................................................173.14 Logical to Physical Mapping (L2PM)..............................................................................................173.15 Source A/V Materials.....................................................................................................................173.16 Rights Token................................................................................................................................. 18

3.16.1 License................................................................................................................................... 183.17 Provisioned DECE Common Container (PDCC)...........................................................................183.18 File................................................................................................................................................. 183.19 File Metadata................................................................................................................................. 193.20 Packaging (out of scope)e.............................................................................................................19

3.20.1 Package Manifest................................................................................................................... 203.21 DECE Participants......................................................................................................................... 20

4 Overview of Publishing Flow................................................................................................................... 214.1 On-boarding of DECE Roles............................................................................................................22

DECE Confidential 7-Apr-15 1

4.2 Product DefinitionCreation...............................................................................................................234.3 Product Product Authoring and CreationPackaging........................................................................234.4 B2B Product DistributionDelivery to Distribution..............................................................................244.5 Point-of-Sale.................................................................................................................................... 254.6 Product Fulfillment and License Fulfillmenting.................................................................................25

5 Content Publishinger Requirements.......................................................................................................275.1 General Requirements.....................................................................................................................27

5.2.1 DECE Identification and Naming..............................................................................................275.2.2 Uniquely Named Artifacts.........................................................................................................275.2.3 ISAN Mapping Best Practices (Informational)..........................................................................27

5.3 Product Definition............................................................................................................................ 275.3.1 Logical Asset Creation.............................................................................................................285.3.2 SKU and Bundle Creation........................................................................................................28

5.4 Rights Profile Rules.........................................................................................................................285.5 Each defined DECE Bundle MUST conform with the DECE Rights Profile bundling rules described in Section TBD of the DECE Content Provider Policy Document. (For example, any Bundle that includes HD Profile Rights for a particular Logical Asset will also include SD and PD Profile Rights for that Logical Asset)................................................................................................................................. 285.6 Identifier Selection........................................................................................................................... 285.7 For each DECE Bundle that it has defined, the publishing content provider MUST select unique DECE identifiers for:.............................................................................................................................. 285.8 the Bundle and all hierarchically included Bundles (BID), and Content Metadata Instances for each such Bundle (CID)................................................................................................................................. 285.9 all included Logical Assets (ALID), and Content Metadata Instances for each such Logical Asset (CID) 295.10 a Logical to Physical Mapping for each included ALID (L2PM ID).................................................295.11 all Physical Assets in each L2P Mapping (APID), and Physical Metadata Instances for each such Physical Asset (TBD)............................................................................................................................. 295.12 Common Container Creation.........................................................................................................29

5.12.1 Container Identification...........................................................................................................295.12.2 Container Constraints.............................................................................................................295.12.3 Content Encryption................................................................................................................. 30

5.13 Fulfillment Definition......................................................................................................................305.14 Publishing to the Coordinator........................................................................................................30

5.14.1 Posting Information................................................................................................................305.14.2 Updating Information..............................................................................................................305.14.3 Logical to Physical Mapping...................................................................................................315.14.4 Product Updates..................................................................................................................... 315.14.5 Product Takedowns...............................................................................................................31

5.15 Product Authoring and CreationPublishing to DSPs, LASPs and Retailers...................................315.15.1 Key Selection and Mapping....................................................................................................315.15.2 Bundle Metadata and Logical Asset Metadata Creation and Updates...................................31

5.16 B2B Product Distribution................................................................................................................315.16.1 DECE Mapping Instance and Metadata Instance Distribution................................................315.16.2 DECE Common Container Distribution..................................................................................315.16.3 DECE Common Container DRM Localization........................................................................325.16.4 Mezzanine A/V Master Distribution........................................................................................325.16.5 LASP Content Localization.....................................................................................................325.16.6 APID to File Name Mapping...................................................................................................325.16.7 Physical Fulfillment Package and Package Manifest Creation...............................................32

5.17 Point-of-Sale.................................................................................................................................. 325.17.1 Readiness Validation..............................................................................................................325.17.2 Rights Token Creation and Deposit........................................................................................32

5.18 Product Fulfillment......................................................................................................................... 325.18.1 DSP Fulfillment.......................................................................................................................32


5.18.2 LASP Fulfillment.....................................................................................................................325.18.3 Native DRM License Acquisition............................................................................................32

5.19 Publishing Considerations for On-boarding of DECE Roles..........................................................325.19.1 Content Provider On-boarding................................................................................................325.19.2 Retailer On-boarding..............................................................................................................325.19.3 DSP On-boarding...................................................................................................................325.19.4 DRM On-boarding.................................................................................................................. 325.19.5 Device On-boarding...............................................................................................................32

5.20 Exception Handling........................................................................................................................325.20.1 Product Updates..................................................................................................................... 335.20.2 Product Takedowns...............................................................................................................33

6 APPENDIX A – Key Publishing Requirements Issues............................................................................346.1 Closed Issues with Resolution History.............................................................................................346.2 Open Issues.................................................................................................................................... 35

7 APPENDIX B – Logical Publishing Information Model............................................................................367.1 SKUProducts and Bundles..............................................................................................................36

7.1.1 Logical Model........................................................................................................................... 367.1.2 Examples.................................................................................................................................. 36


1 Introduction

1.1 Document Purpose

The DECE Ecosystem defines a service-based architecture to enable interoperability of content from multiple providers across multiple retailers, devices, DRM’s, and fulfillment providers. Successful launch and ongoing operations of DECE depends upon ecosystem-wide consistency and reliability for certain aspects of:

(i) what content and other information is made available by each of the DECE roles

(ii) how published information is expressed or formatted

(iii) what rules or constraints must be observed within and among published artifacts

(iv) to which other DECE roles, and in what sequence, information must be made available

(v) which mechanisms, interfaces, or protocols are used to convey the information

Several other DECE specifications describe detailed information and other requirements regarding specific and focused aspects of the ecosystem (e.g. Coordinator Interfaces, DECE Common Container Format, and DSP/Device Interfaces). This Specification provides an overview of the DECE publishing process, including an end-to-end information model. It describes how information published to the ecosystem by a particular DECE roles flows through the ecosystem and is made available to and/or impacts downstream requirements on other DECE roles.

In addition to unifying the related specifications by providing an end-to-end description of the publishing flow, a primary purpose of this document is to define the scope of publishing requirements, and to enumerate a set of requirements, spanning all DECE roles, on the DECE publishing process.

1.2 Document Notation and Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119]. That is:

“MUST”, “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.

“MUST NOT” or “SHALL NOT” means that the definition is an absolute prohibition of the specification.

“SHOULD” or “RECOMMENDED” mean that there may be valid reasons to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

“SHOULD NOT” or “NOT RECOMMENDED” mean that there may be valid reasons when the particular behavior is acceptable, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.


“MAY” or “OPTIONAL” mean the item is truly optional, however a preferred implementation may be specified for OPTIONAL features to improve interoperability.

Terms defined to have a specific meaning within this specification will be capitalized, e.g. “Track”, and should be interpreted with their general meaning if not capitalized. Normative key words are written in all caps, e.g. “SHALL”


2 Document Structure

2.1 Nature of Publishing Requirements

DECE intends to take a minimalist approach to content publishing, based on a desire to preserve time-to-market, minimize ecosystem complexity, and preserve maximum flexibility while minimizing DECE-specific burdens for the various roles within the Ecosystem.

As such, the document is framed as a list of requirements that are introduced on the content publishing process. Firms in each of the DECE roles are free to implement this process as they see fit, provided that their chosen process complies with the content publishing requirements enumerated in this document.

Publishing requirements in this document fall into a variety of categories:

• Included Information, Expression, and Formats for Published Artifacts. These types of

requirements specify what information must be created by which DECE roles, and how that information should or in some cases must be expressed so that others in the ecosystem can reliably consume it. Note that it is possible to specify required information content without necessarily specifying a required form of expression. Further, it is possible to specify a required form of expression without specifying a publishing protocol or mechanism.

• Rules and Constraints regarding Published Artifacts. These types of requirements regard

constraints or rules about relationships among published artifacts as well as the information that they contain, for example; identifier uniqueness, business-driven rules regarding valid profile combinations in defined products, etc.

• Publishing Protocols and Mechanisms. In some cases published information must be

expressed through a particular specified protocol or mechanism (e.g. a web services API provided by the DECE coordinator).

• Rules regarding Publishing Targets and Sequencing. These types of requirements specify to

which DECE roles published information be conveyed, as well as any sequencing and/or timing constraints with respect to such actions.

2.2 Scope and Structure of this Document

The DECE ecosystem is a distributed information publishing, rights & device management, and fulfillment platform. Publishing requirements are derived from the scenarios and use cases that must be supported by various DECE roles, and reflect the information that must be created and distributed by other roles within the ecosystem to support those scenarios and use cases.

This Section 2 describes the nature of various requirements on the DECE publishing process, the scope and structure of this Specification, and its relationship to other DECE Specifications.

Section 3 provides an overview of the publishing information model. This is a high-level description of the information artifacts that must be created and managed by various DECE roles to support the in-scope use cases and scenarios.


Section 4 provides an overview of the DECE publishing process, by describing the end-to-end lifecycle of published DECE content and the related DECE information artifacts. This section also provides comments on aspects of the publishing process that are in-scope vs. out-of-scope for DECE publishing requirements.

Section 5 enumerates the publishing requirements derived from the in-scope use cases and scenarios for the various DECE roles, in the context of the overall lifecycle of DECE content. In some cases we include suggested best practices that are informative, but not required, by DECE stakeholders. This section also describes certain aspects of the process where publishing requirements are explicitly out of scope, with supporting comments.

Appendix A includes (for now) a history of key publishing requirements issues, and any remaining key open issues.

Appendix B includes a comprehensive, end-to-end logical view of the DECE Publishing Information Model, with some examples.

2.3 Relationship to Other DECE Specifications

2.3.1 Media Format Specification

The DECE Media Format Specification describes many requirements regarding the structure, information content, and constraints for the “DECE Common Container” (DCC). Because the DCC is one of the key artifacts published within the DECE ecosystem, this document refers extensively to the Media Format Specification, and delegates many publishing conformance requirements, by reference, to that specification.

2.3.2 Picture Format Specification

The DECE Picture Format Specification (a section of the DECE Media Format Specification) describes requirements and supported alternative video form factors and technical parameters (e.g. aspect ratios, frame rates, etc.) for each video track included in the DECE Common Container. This document delegates several publishing conformance requirements, by reference, to that specification.

2.3.3 Metadata Specification

The DECE Metadata Specification contains descriptions and schemas for several classes of metadata artifacts published within the DECE ecosystem. This document refers extensively to the DECE Metadata Specification, and delegates many publishing conformance requirements, by reference, to that specification.

2.3.4 Coordinator Interface Specification

The DECE Coordinator Interface Specification contains descriptions and schemas for service-oriented interfaces to the DECE Coordinator. In many cases, DECE artifacts must be expressed in the schemas specified in these interfaces, and published to the Coordinator using the mechanisms specified in the Coordinator Interface Specification. As such, this document refers extensively to the Coordinator Interface Specification, and delegates many publishing requirements, by reference, to that specification.


2.3.5 DSP/Device Interface Specification

The DECE DSP/Device Interface Specification describes a minimal fulfillment-side interface that must be supported all DECE DSPs and Devices. Because content published to the DECE ecosystem is ultimately made available to consumers through this interface, this document refers to the DSP/Device Interface Specification, and in some cases delegates requirements, by reference, to that Specification.

2.3.6 DRM Profile Specification

The DECE DRM Profile Specification, among other things, specifies required, permitted, and prohibited modifications that DSPs and approved DECE DRMs may make to DECE Common Containers that have been published to the ecosystem. The DRM Profile Specification also describes consistent information, and in some cases consistent publishing mechanisms, used to bind published DECE content to DRM-specific identifiers, and appropriate license keys.


3 Publishing Information Model

In order to best provide an overview of the publishing flow in the next section, this section describes the end-to-end information model used throughout the DECE ecosystem. In some cases, some or most of the information in the artifacts below are out-of-scope for DECE specification. However, all artifacts that include any DECE information that is the subject of publishing requirements are included in this section. What the Content Publishers publishes to the ecosystem is a subset of what gets delivered to the device.

This section provides a narrative description of the scope and purpose of each of the artifacts in the publishing information model, as well as the key relationships among those artifacts. The reader may also wish to refer to Appendix B, which provides a logical information model for each of these artifacts along with selected examples.

[SS note: Are the terms Content Provider and Content Publisher interchangeable? Both terms are used in this document and one could argue that they are different roles.] [CHS2: The correct term is Content Publisher and all references should be corrected.]

3.1 SKU Product

A SKUProduct (out of DECE scope) is a product definition construct shared between content provider(s) and retailer(s). The SKUProduct defines the boundaries of the product that is sold by the retailer, and is typically referenced in the commercial deal and deal terms between each content provider and retailer. SKUProducts may contain both DECE product offerings as well as non-DECE offerings (e.g. movie + popcorn, or Blu-ray disc + DECE HD/SD/PD content). SKUProduct information will typically include a definition of the included content, key commercial terms between the content provider and retailer, and any additional information needed to promote or market the SKUProduct. SKUProduct definitions and information are nearly completely out-of-scope for DECE. However Retailers and Content Providers do need:

• a consistent way to specify the “entertainment product boundaries” of DECE content that is

included in any SKUProduct

• a way to identify this DECE content so that when SKUProducts that include such content are sold

the associated DECE content can be indentified at point-of-sale and required actions can be taken within the DECE ecosystem such as the creation of a rights token

• retailers can reliably account for settlement with content providers as regards DECE content

Content providers and retailers will likely meet address these needs by embedding references to DECE product offerings DECE Bundle(s) in their SKUProduct definitions, although they are not required by DECE to do so. A DECE product offering may include multiple pieces of unique content or those pieces may be published individually as part of a bundle.

3.2 Content and Rights

3.2.1 Content Structure and Identification

A Content Identifier (CID) uniquely identifies metadata associated with content. This can be anywhere from a TV Show or movie to a TV Season or Show, a movie series, a miniseries, or a franchise containing


movies, television and games. Content Identifiers can also reference clips, mashups, “best-ofs” and other pieces or compilations.

The Content Publisher provides metadata for any of these entities and provides a unique Content Identifier for each.

In the following illustration, each box (the Show, each Season and each Episode) would have a unique CID.

Similarly, for movies, each movie in the series and the series itself would have a CID.

The following illustrates a non-standard structure; specifically, there exists an entity “Selected Scenes” that are portion of Episode 1. “Selected Scenes” would have its own CID.

The Content Publisher however has a choice as to what the product offering looks like. For example, the Content Publisher might package the product offering such that an entity is one episode or in such a way that an entity is a season. This latter approach has shortcomings; not least of these being that the metadata information is limited because there is no way to describe individual episodes.

Content Identification and Metadata are defined in DECE Metadata Specification.


3.2.2 Logical Asset

A DECE Logical Asset expresses a logical scope of content to which consumer usage rights (expressed through DECE Profiles), as well as a physical expression of the content scope (expressed through DECE Logical to Physical Mappings and a set of DECE Physical Assets) can be bound. Thus a Logical Asset maps to one or more Physical Assets. The basic DECE product offering is a single Logical Asset. Logical Assets are identified by Asset Logical IDs (ALIDs).

Each Logical Asset is associated with a single Content Identifier. This is the mechanism by which Logical Assets reference metadata.

Logical Assets and ALIDs are defined in DECE Coordinator API Specification.

3.2.3 Profile

DECE has defined four Profiles, each of which includes a consistent and well-defined set of consumer usage rights that are described in the DECE Policy Documents. The four DECE Profiles are:

• HD – High Definition

• SD – Standard Definition

• PD – Portable Definition

• ISO – SD DVD Burn

Each Logical Asset must have at least one Profile. The following rules apply to content offerings

• If HD is offered, SD, PD and ISO must be available

• If SD is offered, PD and ISO must be available

Business rules in the DECE policy documentsCcontent providerPublisher lLicensing Aagreement [REF] define valid combinations of DECE Profiles. For each DECE Profile made available to consumers for a defined Logical Asset, corresponding physical content must also be made available for fulfillment. Physical content published within the DECE ecosystem by content providers is therefore also tagged with a corresponding DECE Profile. This allows fulfilled physical content to be chained back to the corresponding Logical Asset plus Profile combination, and enables DSPs to validate (through the DECE Coordinator) that corresponding rights to physical content have been purchased prior to issuing DRM-specific licenses for such content. Since illegal [invalid]invalid combinations can be defined in the Coordinator (e.g. offering an HD profile without offering a corresponding SD or PD profile), a rules checking mechanism is necessary to ensure that such combinations are not created. [CHS2: As Retailers create Rights Tokens and the Coordinator checks, this statement is true, but I’m not sure it belongs here. We need to decide who we make responsible. By not constraining the Coordinator, we keep open business models not supported in V1, so I would prefer to put this in the Retailer’s agreement.]

[CHS: Where are Profiles defined?]

3.2.4 Right and Rights Token


A Right is a combination of Logical Asset and Profile. Each of an Account’s Rights are stored in a Rights Token. Rights Tokens are identified by Asset Logical Identifiers (ALIDs) and contain additional data about which Profiles the User has a Right.

Rights Tokens are defined in DECE Coordinator API Specification.

3.2.5 Bundle

Content is often sold as part of a grouping; for example, a season consisting of multiple episodes. Groups may also include “Best-of” or other groupings meaningful to the Content Publisher or Retailer. When the product is sold, without additional information it would be impossible for the Portal to reconstruct the context of the purchase (e.g., were episodes bought individually, as part of a season, or as part of a best-of offering). The A DECE Bundle mechanism defines provides the scope of an entertainment product from the perspective of the contentcontext for the acquisition of a Right.

Bundle references are optionally included in the Rights Token.

The following illustrates a bundle, for Season 2 of a show. The bundle contains reference (CID) to “Show”, “Season 2” and each episode (n entries).

included in the product, and the scope of consumer usage rights granted for each piece of content included in the product. Content providers publish an instance of a DECE Bundle for each entertainment product introduced to the DECE ecosystem, and refer to these published Bundles in commercial arrangements that they make with DECE Retailers. Retailers use Bundles published by Content Providers to maintain consistency between the offers that they make to DECE consumers and the product boundaries defined by Content Providers. Bundles also serve as a reliable way of expressing entertainment product boundaries so that DSPs can fulfill and license content in a manner that is consistent with what the consumer purchased, and what the content provider has licensed to the retailer.

DECE Bundles express content scope in terms of DECE Logical AssetsContent Identifiers (CIDs) and Asset Logical Identifiers (ALIDs)., and usage rights scope in terms of DECE Profiles. These are described in the following two subsections. Bundles are referenced with a globally unique Bundle Identifier.

Bundles can express hierarchy by including references to other published Bundles. Such reference expresses scope inclusion semantics (i.e. all content and rights included in the scope of the referent Bundle are also included in the scope of the referring Bundle).


Bundles also reference metadata describing the Bundle. Bundle metadata has the same type as Logical Asset metadata; both types of DECE artifacts use the same metadata schema. [Editor’s note: There is ongoing discussion as to whether or not this is optimal, and whether the schema for Bundle metadata should be tailored to better support grouping concepts and to improve alignment with existing content identification schemes such as ISAN].Bundles and Bundle Identifiers are defined in the DECE Coordinator API Specification. Bundle information is provided to the Coordinator through APIs defined in the DECE Coordinator API Specification.

3.3 Containers and Files

3.3.1 Origin DECE Common Container (ODCC)

The DECE Common Container format includes provisions for including a DRM-non-specific DECE identifier and DRM-non-specific information describing the layout of encrypted segments and tracks within the container. It also includes provisions for each approved DECE DRM system to embed DRM-specific information within the DCC. An Origin DECE Common Container (ODCC) is a DCC which includes the required DRM-non-specific information, but which does not include any DRM-specific information. ODCCs are created by content providers.

3.4 Logical Asset

A DECE Logical Asset expresses a logical scope of content to which consumer usage rights (expressed through DECE Profiles), as well as a physical expression of the content scope (expressed through DECE Logical to Physical Mappings and a set of DECE Physical Assets) can be bound.

DECE Logical Assets reference metadata describing the Logical Asset. Logical Asset metadata has the same type as Bundle metadata; both types of DECE artifacts use the same metadata schema. [Editor’s note: There is ongoing discussion as to whether or not this is optimal, and whether the schema for Logical Asset metadata should be tailored to better support leaf concepts and to improve alignment with existing content identification schemes such as ISAN].

Content providers have flexibility to optimize the granularity of Logical Assets, Bundles, and SKUs to best support their commercial objectives, including for example:

decisions regarding how they partition, localize, and license similar or “title-equivalent” content for distribution into multiple regions

• decisions regarding content scope and licensing exclusivity for particular regions or DECE

retailers

3.5 Rights Profile

DECE has defined four Rights Profiles, each of which includes a consistent and well-defined set of consumer usage rights that are described in the DECE Policy Documents. The four DECE Rights Profiles are:

• HD – High Definition Rights

• SD – Standard Definition Rights


• PD – Portable Definition RIghts

• ISO – SD DVD Burn Rights

DECE Rights Profiles intersect with the DECE Publishing Process because content providers define which rights are made available for each DECE Logical Asset within any Bundle that the content provider makes available for retailer(s) to sell to consumers. Business rules in the DECE policy documents define valid combinations of DECE Profiles. For each DECE Profile made available to consumers for a defined Logical Asset, corresponding physical content must also at some point be made available for fulfillment. Physical content published within the DECE ecosystem by content providers is therefore also tagged with a corresponding DECE Rights Profile. This allows fulfilled physical content to be chained back to the corresponding {Logical Asset | Rights Profile} combination, and enables DSPs to validate (through the DECE Coordinator) that corresponding rights to physical content have been purchased prior to issuing DRM-specific licenses for such content.

Permissible Picture Formats corresponding to each of the DECE Rights Profiles are defined in the Picture Format section of the DECE Media Format Specification. In order for a particular DECE Physical Asset to be identified as appropriate for fulfillment of a specified Rights Profile, the Picture Format(s) used within that Physical Asset must be consistent with the alternatives specified in the Picture Format Specification. [

3.6 Content Metadata

DECE Bundles and Logical Assets each include by reference an instance of DECE Content Metadata. Content Metadata is made available and maintained by the content provider and may be used by other DECE roles to support their ecosystem activities.

The Schema for Content Metadata is detailed in the DECE Metadata Specification.

3.6.1 Physical Asset

A DECE Physical Asset is ais a uniquely named and identified sequence of bits corresponding to playable DECE contentDECE Common Container as defined in the DECE Media Format Specification. DECE Physical Assets are not bound to files or filenames, and are intended to be usable by multiple DSPs, multiple retailers, and multiple devices within the DECE Ecosystem. DECE Physical assets are made available by Ccontent Pproviders.

One or more Physical Asset must exist for each RightEach {Logical Asset. | Rights Profile} combination maps to one or more Physical Assets, as defined in a DECE Logical to Physical Mapping. These Physical Assets are fulfilled by DSPs to DECE consumers and devices whenever that User has the {Logical Asset | Rights Profile}Right combination is used in a Bundle for which fulfillment is requested by the consumer(i.e., that User’s Account Contains a Rights Token that contains the Right).

Physical Assets are defined by Asset Physical Identifiers (APIDs). APIDs are defined in the DECE Metadata Specification.

3.6.2 Provisioned DECE Common Container (PDCC)

The Origin DECE Common Containers (ODCCs) provided to DSPs by content providers contain no DRM- or DSP-specific information. To support operations at scale, DSPs may add DRM-specific information as


specified in the Media Format Spec and the DRM Profile Spec, so that DRM Clients can more efficiently locate the license server and other DRM-specific services required to license and play the content within the DCC. After a DSP has added its DRM-specific information to the DECE Common Container, the container is referred to as a Provisioned DECE Common Container (PDCC).

PDCCs are used to optimize a common distribution path, however that path cannot be guaranteed. As described in more detail in the DRM Profile Spec, DRM Clients must therefore also be able to cope with an ODCC, or a PDCC that has been provisioned with DRM-specific information for a DRM other than its own.

3.6.3 File

Neither DECE Physical Assets nor DCCs are necessarily bound to files. Stated differently, the ways in which they may be bound to files by content providers for distribution to DSPs is out of scope of DECE and this specification.

By the time DCCs are delivered to consumers in the field they are likely bound to files on one or more content distribution networks, each with location and access protocol information.

DSPs are free to bind DCCs to files in ways that optimize their operations. The “same” DCC may be made available by multiple DSPs with different filename bindings, and made available to consumers through different content distribution networks with different location paths and access protocols.

The DSP/Device Interface Specification provides a minimal interface that must be supported between DECE devices and DSPs, so that DECE content can be reliably fulfilled by all DSP Devices in a DSP-independent manner.

3.6.4 File Metadata

Bindings made by DSPs from Physical Assets to Files and/or Publishing Locations will have associated file mapping metadata.

File Metadata is out of scope for DECE specification.

3.7 Logical to Physical Mapping (L2PM)

For each Right offered by Content Providers, a Logical to Physical Mapping (L2PM) is also published. The L2PM for a Right enumerates the Physical Assets included within that Right.

L2PMs are made available and maintained by content providers. L2PMs are used by DSPs to determine which Physical Assets should be fulfilled for each Logical Asset within a Bundle requested for fulfillment by a consumer.

Logical to Physical Mappings are defined the DECE Coordinator API Specification. L2PMs are provided to the Coordinator through APIs defined in the DECE Coordinator API Specification.

3.8 Encoding

3.8.1 Source A/V Materials


Content providers create and make available Physical Assets (published ODCCs) for each published Bundle as specified by the Logical Assets and corresponding Rights Profiles within the Bundle, and the L2PMs for each Logical Asset.

The published ODCC bitstreams can be used by DSPs in download fulfillment transactions, and by linked LASPs for streaming transactions. Non-linked LASPs, however, must create their own proprietary content encodings corresponding to each of the Physical Assets provided by content providers. So that they may do so, content providers must make available to them the appropriate Source A/V Materials corresponding to those that were required to author the ODCCs.

3.8.2 Picture Format

The DECE Media Format Specification defines a number of supported DECE Picture Formats. The video in each video track within a DECE Common Container conforms to one of the defined DECE Picture Formats.

Physical Assets provided by content providers for the purpose of fulfilling a particular DECE Rights Profile for a particular Logical Asset must include Picture Format(s) that are consistent with that Rights Profile.

3.9 Asset Metadata

DECE Bundles and Logical Assets each include by reference an instance of DECE Basic Metadata through the Content Identifier (CID).

Physical Assets must conform to the requirements described in the DECE Media Format Specification in order for them to be reliably used by other DECE roles. DECE has defined a “DECE Common Container” (DCC) Format. DECE Physical Assets map 1::1 to DCCs.

DECE Physical Assets include by value a subset of the Physical Asset Metadata described in the next section. This is described in more detail in the Media Format Specification.

3.10 Physical Asset Metadata

For each Physical Asset made available, content providers must also make available corresponding DECE Physical Asset Metadata.

Metadata can be made available and maintained by the Content Provider and may be supplied to other DECE Roles to support their ecosystem activities—this interface is out of scope.

Metadata included in the DECE Common Container is defined in the DECE Media Format Specification.Physical Metadata is made available and maintained by the content provider and may be used by other DECE roles to support their ecosystem activities.

The Schema for Physical Asset Metadata and Basic Metadata isare detailed in the DECE Metadata Specification. Metadata is provided to the Coordinator through APIs defined in the DECE Coordinator API Specification.

3.11 DRM

3.11.1 Keyset


The DECE Common Container corresponding to each DECE Physical Asset may include encrypted content. All such encrypted content uses a consistent content encryption mechanism as described more fully in the DECE Media Format Specification. Content providers choose which content tracks, and which segments within those tracks, within a DCC will be encrypted. Content providers also choose and manage the encryption keys used to encrypt any encrypted content.

A DECE Keyset is a data structure that captures how content within a DCC has been encrypted – which tracks, which segments within those tracks, and the encryption key used for each such segment. DECE Keyset information is provided by content providers. DRM License Servers used by various DSPs will need this information to be able to construct corresponding DRM-specific license(s) for the DCC.

A subset of the DECE Keyset information for each DCC (everything except the keys themselves) is also embedded within the DCC in a DRM-non-specific fashion as described in more detail in the Media Format Specification and the DRM Profile Specification. This allows DCCs to be used across multiple (current and future) approved DECE DRM systems.

3.12 Picture Format

The DECE Media Format Specification defines a number of supported DECE Picture Formats. The video in each video track within a DECE Common Container conforms to one of the defined DECE Picture Formats.

Physical Assets provided by content providers for the purpose of fulfilling a particular DECE Rights Profile for a particular Logical Asset must include Picture Format(s) that are consistent with that Rights Profile.

3.13 Origin DECE Common Container (ODCC)

The DECE Common Container format includes provisions for including a DRM-non-specific DECE identifier and DRM-non-specific information describing the layout of encrypted segments and tracks within the container. It also includes provisions for each approved DECE DRM system to embed DRM-specific information within the DCC. An Origin DECE Common Container (ODCC) is a DCC which includes the required DRM-non-specific information, but which does not include any DRM-specific information. ODCCs are created by content providers.

3.14 Logical to Physical Mapping (L2PM)

DECE Bundles define their comprising set of {Logical Asset | Rights Profile} combinations. For each Logical Asset published by content providers, a Logical to Physical Mapping (L2PM) is also published. The L2PM for a Logical Asset enumerates the Physical Assets included within the content scope of the Logical Asset, for each Rights Profile that has been made available for the Logical Asset.

L2PMs are made available and maintained by content providers. L2PMs are used by DSPs to determine which Physical Assets should be fulfilled for each Logical Asset within a Bundle requested for fulfillment by a consumer.

3.15 Source A/V Materials

Content providers create and make available Physical Assets (published ODCCs) for each published Bundle as specified by the Logical Assets and corresponding Rights Profiles within the Bundle, and the L2PMs for each Logical Asset.


The published ODCC bitstreams can be used by DSPs in download fulfillment transactions, and by linked LASPs for streaming transactions. Non-linked LASPs, however, must create their own proprietary content encodings corresponding to each of the Physical Assets provided by content providers. So that they may do so, content providers must make available to them the appropriate Source A/V Materials corresponding to those that were required to author the ODCCs.

3.16 Rights Token

When a consumer purchases a Bundle from a retailer licensed by a content provider to sell it, the retailer registers the sale with the DECE Coordinator, thereby creating a Rights Token managed by the Coordinator. The Rights Token includes a reference to the root Bundle of the transaction, and can therefore be used by the coordinator to approve or deny subsequent requests by DSPs to validate whether or not physical content should be licensed by the DSP.

3.16.1 License

DECE supports multiple approved DRM systems. Each DECE DSP supports one or more approved DRMs, and DECE retailers must contract with DSP such that the retailer supports all approved DRMs.

In order to play encrypted content held within DECE Common Containers, DECE devices (and their embedded DRM client) must be able to reliably identify DECE Physical Assets (both ODCCs and PDCCs), and obtain a license that corresponds to the Keyset with which the Physical Asset was encrypted. The license includes the keys required for the DRM client to play the content, appropriately protected in a DRM-specific manner.

Licenses are created by DSPs, for approved DRMs that they support, for content that was purchased from retailers with whom they have contracted. Licenses are created using and consistent with Keyset information for the corresponding Physical Asset(s) as provided to the DSP by the content provider.

The publishing process requires that linkages must be reliably maintained across: the Physical Asset on a device; a license request and resulting corresponding license; a request for purchase validation and rights token lookup within the Coordinator; the corresponding Bundles and L2PMs published and maintained by the content provider, and the Keyset used by the content provider to encrypt the Physical Asset.

3.17 Provisioned DECE Common Container (PDCC)

The Origin DECE Common Containers (ODCCs) provided to DSPs by content providers contain no DRM- or DSP-specific information. To support operations at scale, DSPs may add DRM-specific information as specified in the Media Format Spec and the DRM Profile Spec, so that DRM Clients can more efficiently locate the license server and other DRM-specific services required to license and play the content within the DCC. After a DSP has added its DRM-specific information to the DECE Common Container, the container is referred to as a Provisioned DECE Common Container (PDCC).

PDCCs are used to optimize a common distribution path, however that path cannot be guaranteed. As described in more detail in the DRM Profile Spec, DRM Clients must therefore also be able to cope with an ODCC, or a PDCC that has been provisioned with DRM-specific information for a DRM other than its own.

3.18 File


Neither DECE Physical Assets nor DCCs are necessarily bound to files. Stated differently, the ways in which they may be bound to files by content providers for distribution to DSPs is out of scope of DECE and this specification.

By the time DCCs are delivered to consumers in the field they are likely bound to files on one or more content distribution networks, each with location and access protocol information.

DSPs are free to bind DCCs to files in ways that optimize their operations. The “same” DCC may be made available by multiple DSPs with different filename bindings, and made available to consumers through different content distribution networks with different location paths and access protocols.

The DSP/Device Interface Specification provides a minimal interface that must be supported between DECE devices and DSPs, so that DECE content can be reliably fulfilled by all DSP Devices in a DSP-independent manner.

3.19 File Metadata

Bindings made by DSPs from Physical Assets to Files and/or Publishing Locations will have associated file mapping metadata.

It is not clear at this time to what extent such mappings are in scope for DECE publishing requirements.

3.20 Packaging (out of scope) e

[SS: Note. If we are not defining DECE Packaging then can this subsection can be deleted?][CHS2: I think we can delete and cover at an abstract level in Section 4.]

DECE Packages are a purchase fulfillment concept. The content and usage rights scope of each purchase of DECE content is defined by the Bundleproduct offering, published by the content provider, corresponding to the purchase.

As stated before a product offering may be a single Logical Asset or a bundle of one or more Logical Assets. Bundles may be hierarchical, and may also include multiple Each Logical Assets, each of which may include multiple Physical Assets. Therefore, fulfillment of a single purchase of DECE content may entail delivery and licensing of multiple DECE Physical Assets and their corresponding DCCs.

[SS Note: The following statement sounds like a requirement for another specification:] The DSP/Device Interface Specification must support the notion of multi-asset fulfillment. The publishing requirements cover this requirement through the notion of a DECE Package. A DECE Package is a data structure that enumerates all of the Files included in a particular content purchase, and where those Files may be obtained by a consumer’s device from the DSP that defined the Package.

Packages may also include Package metadata, which could include information used by the device to understand the semantics of the multiple DCCs included in the Package (e.g. that two DCCs are co-temporal and contain complementary information, and which one contains “default” information). Such metadata, if present, would need to be derived from the Bundle definition provided to the DSP by the content provider.

The working groups have not yet fully explored the notion of Packages, how they support multi-Asset fulfillment, how they are supported by the Device/DSP Interface Spec, and whether or not Packages can support content in addition to DECE Physical Assets.


3.20.1 Package Manifest

One simple way to support multi-asset fulfillment is for the DSP to express the Package information in a single document, the Package Manifest. This document would be the first document delivered to the DECE client, and would include sufficient information for the client to initiate fulfillment of other required Files within the Package.

An alternative proposal has been to use compression-less .zip files to provide a packaging structure that DECE Devices could parse and interrogate.

The DSP/Device Interface Specification must define this mechanism in more detail.

3.21 DECE Participants

Various roles within the ecosystem have self-descriptive data models associated with them, that must be published and maintained each DECE participant. These are used primarily by the DECE customer-facing UI; they may also be used by DECE B2B customer support.

DECE participants in the following roles each publish and maintain a self-descriptive data structure that is defined in the DECE Coordinator Interface Specification:

• Content Provider

• Retailer

• DSP

• Device

• DRM

• Household

• User


4 Overview of Publishing Flow

This section is informative.

The figure below provides an overview of the DECE Ecosystem publishing flow. Many parts of this flow are out-of-scope for DECE Publishing Requirements, but are included to provide a relatively complete view of information flow and linkages within the ecosystem. The accompanying text provides a narrative description of the key activities within the publishing flow, offering context for the publishing requirements enumerated in the next section.

[Need updated diagram. Using Alex’s sketch for now, thanks Alex!]

4.1 On-boarding of DECE Roles

Before each DECE role is introduced to the DECE ecosystem, various on-boarding tasks are completed. These involve selecting unique namespace prefixes corresponding to the new entity that will be maintained by DECE, and publishing self-descriptive information to the DECE Coordinator for use within the DECE consumer-facing user interface, and DECE B2B support interfaces.

4.2 Product Definition Creation

The publishing flow is initiated by the content provider with a product definitiondefinition that defines the contents activities.

Motivated content providers create a DECE Bundle that defines the content and rights scope of a set of content to bethe product offering to be made available for sale within. the ecosystem. Content providers and retailers refer to the created Bundle product offering in their bi-lateral content deals which are out of scope for DECE. Either the Content Publisher or the Retailer may bundle product items into a Bundle.

As part of the product definition process, content providers may partition the product for distribution in various regionsmarkets, for example with various preferred languages and subtitles, etc. Content providers may also decide to create unique products for distribution in a particular region market or through a particular retailer. The content provider determines which profiles will be sold.

The product definition for each Bundle includes: the Bundle hierarchy (if any); the Logical Asset(s), and and the associated technical and descriptive metadata instances. Usage Rights for each, included in the Bundle; the Logical to Physical Mapping for each included Logical Asset; and the Picture Format(s) to be used for each Physical Asset. The content provider selects a unique ALIDs for each BundleLogical Asset. The product definition may also include a Bundle hierarchy.

, Logical Asset, L2P Mapping, and Physical Asset, as well as unique IDs for Content Metadata Instances for each Bundle and Logical Asset.

Content providers can maintain the various artifacts published as part of the product definition throughout the lifecycle of the product. Updates can be published for Bundle definitions, L2P Mappings, Content Metadata describing Bundles and Logical Assets, and Physical Asset Metadata. Updated Physical Assets can also be introduced by including them in updated L2P Mappings.

Content providers may provide certain product definition information to Retailers and the DECE Coordinator, to enable sale of product in advance of the product’s availability for fulfillment.

4.3 Product Product Authoring and Creation Packag ing

Once a DECE product is defined, the associated artifacts must be authored and created. The content provider authors and encodes content for each profile that will be offered: PD, SD and HD. For each Physical Asset within the product definition, the content provider assigns a unique APID. If part of the product offering includes an ISO then that is created and assigned an APID. For each profile, the content provider creates ALID to APID mappings.

Content Encryption Keys (CEK) are generated and the mapping to the APID is created. Once a DECE product is defined, the associated artifacts must be authored and created. The content provider creates a metadata instance for each Bundle, Logical Asset, and Physical Asset within the product definition. For

each Physical Asset within the product definition, the content provider creates creates a Keyset, and an ODCC that includes the content that all metadata including CIDs consistent . [CHS2: The metadata in the container is a to-be-defined subset of what is provided to the Coordinator.] The container contents are encrypted with the CEKs. [CHS2: There may be multiple keys for a Container.]

with that Keyset.[SS Note: also unique IDs for Content Metadata Instances for each Bundle and Logical Asset?]

4.4 B2B Product Distribution Delivery to Distribution

The content provider makes the product information offering available to other DECE roles in the ecosystem.

Product definition offering information including ALIDs, available profiles, Bundle instances if applicable, Logical to PhysicalALID to APID mMappings, Content Metadata instances for each Bundle and Logical Asset, and Physical Asset Metadata are published to the DECE Coordinator.

The content publisher delivers metadata and business information to the Retailer. Business information includes ALIDs and ALID to APID mapping and includes all the parameters around the selling of the product. This information is delivered in a manifest, conceptually a packing list that sets the parameters around what can be sold. The manifest is a transient entity used for the transfer from content publisher to the retailer. The method of this delivery could be anything from fully electronic and automated, to entirely manual and is out of scope of DECE. Ancillary files, such as promotional material, might also be provided. The retailer constructs a database entry of the ALID along with available profiles and associated metadata together with the retail data.

At this time the Retailer may create a bundle using the same process as a content publisher’s creation of a bundle and post information on that bundle to the Coordinator.

The content publisher delivers ALIDs, APIDs, ALID to APID mappings, license generation information including keysets, Common Containers and ISO imagesKeysets and Physical Assets are delivered by the content provider to those DSPs and used by retailers to whom the content provider has licensed to sell the product. The DSP creates a database entry for the delivered information.

The DSP and Retailer will then coordinate as necessary but with no participation from the ecosystem.

The content provider also delivers appropriate Source A/V Materials to any Linked LASPs that the content provider has licensed to stream the product. Each of these Linked LASPs prepares content for use within their delivery system.

Upon receipt of each ODCC, receiving DSPs may [SS note: “will”?][CHS2: We don’t have distinct definitions for ODCC and PDCC, so it would be difficult to mandate a transformation. I can envision certain superdistribution models where the DSP uses the container provided by the CP. This is particularly important with respect to references to license managers. We should talk this through. In the meantime, ‘may’ is more general.] create a corresponding PDCC. The DSP(s) of each retailer licensed to sell the product also receives a Keyset for each of the product’s included Physical Assets. Those DSPs add the key information and perform any required DECE ID to Native DRM ID within (each of) their native DRM systems. The DSP may write license server links into Container. The DSP configures License Servers to map from APID to CEK in order to issue Native DRM licenses.

Each receiving DSP also binds included Physical Assets to File Names and device-accessible fulfillment locations, creates any required fulfillment packages (Package Manifests, or .zip files), and stages each required fulfillment artifact in preparation for B2C distribution to the device. [CHS2: If we ever get around to defining a Download Manager, there may be additional requirements.]

The content provider also delivers ALIDs, appropriate Source A/V Materials and mappings, and metadata to any Linked LASPs that the content provider has licensed to stream the product. Each of these Linked LASPs prepares content for use within their delivery system. The LASP creates a database entry for the ALID, profile and associated metadata and content mappings in preparation for making the content available for streaming.

4.5 Point-of-Sale

4.5.1

The Retailers validates with their designated DSP(s) when that products that they have licensed from content providers are ready for sale and fulfillment.

The retailer creates and presents the product offering to consumers for each ALID profile or bundle. When a Bundle product offering is sold, retailers manage the registration of the sale with the DECE Coordinator, creating a rights token for each included {Logical Asset and| Rights Profile} combination.

The User purchases content through the Retailer. Only Retailers may sell content, but there are several mechanisms that may take a User to the Retailer including but not limited to, a Retailer’s web site, a device interface to a Retailer (typically a device manufacturer’s store) and tools that allow Users to purchase content delivered through superdistribution.

The User identifies content via human readable metadata, such as Title, Jacket Pictures, Actors, P-date, language, Profile, etc. at the Coordinator, the Retailer or the Device GUI. The Coordinator metadata is in scope of DECE whereas the Retailer and Device metadata are out of scope. The User or the Device determines a location where rights may be purchased (e.g. from a URL in file). The User buys the product offering and the Retailer links to the DECE User Identity and the DECE Account.

From the perspective of the DECE ecosystem, the purchase occurs when Tthe Retailer creates a Rights Token for each ALID and Profile that was sold. The Rights Token contains information about the Profiles, the rights within the profile, burn counts, purchase information, metadata identifiers and, if applicable, bundle identifiers. If ALIDs were in a bundle, rights token includes BundleID. Also in the Rights Token are iInformation about the sale, links to the retailer and links to license server are included in the Rights Token.

The Retailer may only create Rights Tokens for a User if it has authorization. [CHS2: We need to make sure this is air tight. The case I’m thinking of is someone buying a season before it is aired. The Retailer will need to add Rights Tokens at airing, but can’t ask the User to log in. A blanket OAuth is too broad, or is it?]

4.6 Product Fulfillment and License Fulfillment ing

Consumers Users can request fulfillment for products of Logical Assets that they have purchased from the retailerin their Rights Locker. They may obtain the Physical Assets from a DSP or streams from a

LASP. The DSP may be associated with the Retailer where the Asset was purchased or from an DSP willing to fulfill it. Typically, the original Retailer’s DSP will be used as they are obligated to provide a limited number of downloads to the purchaser. from which they purchased it, or from another retailer to which the content provider has licensed the product.

Generally, a User would start from a view of their Rights Locker at a Retailer/DSP, the Coordinator, or a Device. From that view, they would select the Assets they wish to download. If the view is from the DSP, the Container can be downloaded. If the view is from another entity, a reference to a DSP is provided. In particular, the Rights Token includes a reference to the Retailer that sold the Asset and upon request the Coordinator redirects the User to that Retailer. DECE provides Basic Metadata with the express intention of facilitating this referral process. The request may be based on a metadata description or and APID included in an ALID and Profile for which the user has rights. The User may have gone directly to the Retailer or may have gone to the Coordinator who refers the User to the Retailer using the information in the Rights Token.

Product Fulfillment involves conveying the required fFile(s) to a consumer’s device. License FulfillmentLicensing involves ensuring that the Device also has any required DRM-specific license(s) and other information required for the device to play the file(s). The DSP designated by the chosen Rretailer is responsible for both Product Fulfillment and License Fulfillmentlicensing. In some use cases Product Fulfillment may have already occurred through an out-of-band mechanism (e.g. side-loaded content initiated by the consumeri.e., superdistribution). The DSP downloads file to the user’s device and the file makes its way to where the DRM Client has access to it.

License FulfillmentLicensing cantypically occurs after the file has been downloaded. [CHS2: original statement not true. The file can hypothetically be pre-licensed.] The User identifies the file by one of several means, usually by its metadata, like Title or thumbnail, or by the filename.The licensing process is initiated when the The User tries to play thean unlicensed file. and iIf the license is not available for the chosen the DRM on the Device, the DRM Client goesfirst locates and then communicates with the appropriate to license manager [SS Note: mechanism to be discussed] and requests a license. The license arrives using a mechanism that is defined by the DRM and is out of scope of DECE. Once licensed, and the content plays.

In the case of non-linked LASPs, product and license fulfillment occur using the proprietary files and mechanisms that the LASP has created for secure streaming using the LASPs delivery infrastructure. Streaming occurs over a DECE approved secure streaming mechanism.

[SS Note: Still be resolved is additional file distribution and license acquisition data and behavior necessary to support the use cases in an interoperable way, even though implementations of those are out of scope. ]

5 Content Publishing er Requirements

This section enumerates requirements for each area of the DECE publishing process, noting the DECE role(s) to which each requirement applies.

5.1 General Requirements

5.2

5.2.1 DECE Identification and Naming

[Requirements regarding identification and naming of artifacts within the publishing process]

5.2.2 Uniquely Named Artifacts

The Content Publisher SHALL create identifiers in accordance with rules defined in The following published artifacts MUST be named uniquely by the content provider using the naming conventions in section “1.2.1.1 Naming Conventions” of the DECE Coordinator Interface Specification [REF].:

• Bundles – (Bundle ID)

• Bundle Metadata Instance – (Content ID, CID)

• Logical Assets – (Asset Logical ID, ALID)

• Logical Asset Metadata Instance – (Content ID, CID)

• Physical Assets – (Asset Physical ID, APID)

• Physical Asset Metadata Instance – (TBD)

• Keyset – (TBD)

[File Naming Requirements? (for DSPs)]

5.2.3 ISAN Mapping Best Practices (Informational)

This section is INFORMATIVE ONLY, and provides best practices for mapping DECE identifiers to ISAN standard identifiers in cases where relevant ISAN standard identifiers either already exist or content providers choose to create them.

5.2.3.1 ISAN

[To be provided by Dave Benson]

5.3 Product Definition

5.3.1 Logical Asset Creation

5.3.1.1 Logical Asset Identification

The Content Publisher SHALL identify a Logical Asset to be offered as a Right. A unique ALID and one or more Profiles SHALL be defined for each Right. Profiles offered SHALL be consistent with Content Publisher Policies [REF?]

5.3.1.2 Metadata

Metadata SHALL be created for the Logical Asset. A unique Content ID (CID) SHALL be created for this metadata.

Metadata MAY be created for Content that is parent to the Logical Asset. Each metadata node SHALL be identified with a unique Content ID (CID).

Metadata for the Logical Asset SHOULD reference parent Content if it exists.

5.3.2 SKU and Bundle Creation

5.3.2.1 Bundle Creation

The Content Publisher MAY create one or more Bundles that contain the Logical Asset ID. For each DECE product that a content provider licenses for sale to one or more DECE Retailers, the content provider MUST create one or more DECE Bundles that define the content and rights scope of the product.

Each such defined Bundle MUST conform with the DECE Bundle Schema Definition defined in section TBD of the DECE Metadata Coordinator API SpecificationSpecification. [CHS: Currently a bundle does not contain profile. Note that it is not intended to define the right, only the grouping for display after the purchase. Does this work?]

5.4 Rights Profile Rules

5.5 Each defined DECE Bundle MUST conform with the DECE Rights Profile bundling rules described in Section TBD of the DECE Content Provider Policy Document. (For example, any Bundle that includes HD Profile Rights for a particular Logical Asset will also include SD and PD Profile Rights for that Logical Asset).

5.6 Identifier Selection

5.7 For each DECE Bundle that it has defined, the publishing content provider MUST select unique DECE identifiers for:

5.8 the Bundle and all hierarchically included Bundles (BID), and Content Metadata Instances for each such Bundle (CID)

5.9 all included Logical Assets (ALID), and Content Metadata Instances for each such Logical Asset (CID)

5.10 a Logical to Physical Mapping for each included ALID (L2PM ID)

5.11 all Physical Assets in each L2P Mapping (APID), and Physical Metadata Instances for each such Physical Asset (TBD).

5.12 Common Container Creation

The Content Publisher SHALL define Original DECE Common Containers (ODCCs) associated with each Right. The ODCC SHALL conform with the DECE Media Format Specification.

The following sections define additional constraints on the ODCC.

5.12.1 Container Identification

Each ODCC SHALL be identified by a unique APID.

5.12.2 Container Constraints

5.12.2.1 Metadata Constraints

[TBD]

5.12.2.1.1 Required

5.12.2.1.2 Optional

5.12.2.2 Picture Format Video Selection Constraints

[TBD]

5.12.2.2.1 Picture Format Constraints

5.12.2.2.2 Cropping

5.12.2.2.3 Chapters

5.12.2.2.4 Etc?

5.12.2.3 Audio Constraints

[TBD]

5.12.2.4 Subtitle Constraints

[TBD]

5.12.2.5 Other Constraints

[TBD]

5.12.3 Content Encryption

[TBD]

• Number of keys

• Key generation constraints

• Identifying keys

5.13 Fulfillment Definition

[CHS: What files can fulfill a Right needs have additional rules associated with it. This is handled through the ALID to APID mapping (that includes Profile), but there are additional constraints around whether all

DSPs have the same Containers. For example, ALID1-SDAPID1, ALID1-SDAPID2. Does this mean that either APID satisfies the Right? If so, DSP1 can get APID1 and DSP2 can get APID2. On the other hand, maybe APID1 and 2 are both required to fulfill the Right. Do we need a more sophisticated means of avoiding this ambiguity?]

5.14 Publishing to the Coordinator

5.14.1 Posting Information

The Content Publisher SHALL post data associated with a Logical Asset to the Coordinator prior to attempts to create Rights Tokens referencing that Logical Asset.

The Content Publisher SHALL post data associated with a Logical Asset to the Coordinator prior to attempts to stream that Logical Asset.

The Content Publisher or Retailer SHALL post Bundle to the Coordinator prior to attempts to create Rights Tokens referencing the Bundle.

Data associated with a Logical Asset includes the following:

• Basic Metadata (including CID)

• Physical Asset Metadata (including APID)

• ALID to CID Mapping

• Logical to Physical Mapping (ALID to APID)

5.14.2 Updating Information

5.14.2.1 Basic Metadata

Basic Metadata MAY be updated at any time. Updates SHALL include the UpdateNum element that is incremented for each revision for that CID.

5.14.2.2 Physical Asset Metadata

Physical Asset Metadata MAY be updated at any time. Updates SHALL include the UpdateNum element that is incremented for each revision for that CID.

5.14.2.3 ALID to CID Mapping

ALID to CID Mapping SHALL NOT be updated. [CHS: This seems messy. Can this be done cleanly?]

5.14.2.4 Logical to Physical Mapping

Logical to Physical Mapping (ALID to APID) MAY be updated at any time.

[CHS: This is the mechanism for making an APID obsolete. We need to say more about the rules here. The old mapping will still need to exist to allow APID to Right mapping and I’m not sure that’s handled correctly now.]

5.14.3 Logical to Physical Mapping

5.14.4 Product Updates

5.14.5 Product Takedowns

5.15 Product Authoring and Creation Publishing to DSPs, LASPs and Retailers

5.15.1 Key Selection and Mapping

[Requirements upon Keyset generation]

5.15.2 Bundle Metadata and Logical Asset Metadata Creation and Updates

DECE Common Container and Physical Asset Metadata GenerationDECE does not define the process of publishing to DSPs, LASPs and Retailers.

5.16 B2B Product Distribution

5.16.1 DECE Mapping Instance and Metadata Instance Distribution

5.16.2 DECE Common Container Distribution

Including key distribution

5.16.3 DECE Common Container DRM Localization

5.16.3.1 APID to native ID mapping registration

5.16.3.2 Key to License Registration

5.16.4 Mezzanine A/V Master Distribution

5.16.5 LASP Content Localization

5.16.6 APID to File Name Mapping

5.16.7 Physical Fulfillment Package and Package Manifest Creation

5.17 Point-of-Sale

5.17.1 Readiness Validation

5.17.1.1 Readiness for Sale

5.17.1.2 Readiness for Fulfillment

5.17.2 Rights Token Creation and Deposit

5.18 Product Fulfillment

5.18.1 DSP Fulfillment

5.18.2 LASP Fulfillment

5.18.3 Native DRM License Acquisition

5.19 Publishing Considerations for On-boarding of DECE Roles

5.19.1 Content Provider On-boarding

5.19.2 Retailer On-boarding

5.19.3 DSP On-boarding

5.19.4 DRM On-boarding

5.19.5 Device On-boarding

5.20 Exception Handling

[Requirements on the publishing process when transaction validation fails within the ecosystem. For example, content sold with non-existent ID, etc.]

[CHS: Some of this happens through the ALID/APID mapping.]

5.20.1 Product Updates

Content providers can maintain the various artifacts published as part of the product definition throughout the lifecycle of the product. Updates can be published for product offerings, Bundle definitions [CHS2: I don’t think so. Once a Rights Token is issued that bundle many never change.], L2P Mappings, Content Metadata describing Bundles and Logical Assets, and Physical Asset Metadata. Updated Physical Assets can also be introduced by including them in updated L2P Mappings. The Ccontent providerPublisher updates the container as necessary and republishes it to the ecosystem [CHS2: An updated container MUST have a new APID or licensing won’t work. So, technically, containers are replaced, not updated.]. O it is determined that all DSPs have the new container the ALID to APID mapping can be updated. [SS Note: this might be a preferred mapping – if don’t have the new one, download the old one.] [CHS2: This is why we need to get into the update scenarios. We currently have no concept of ‘preferred’ or ‘supercedes’ in the mapping.]

5.20.2 Product Takedowns

A product takedown results in the immediate removal of a product offering by the removal of ALID to APID mappings. [CHS2: What about removing the ALID from sale? Note that just removing the mapping breaks the fulfillment, so we need to carefully consider how this happens.]

6 APPENDIX A – Key Publishing Requirements Issues

6.1 Closed Issues with Resolution History

CPR-ISSUE1 – Content Version Uniqueness. Must we support multiple versions of encodings of a particular title and profile within the ecosystem simultaneously? Must we include requirements to avoid introduction of multiple “equivalent” containers if acceptable encodings already exist within the ecosystem?

CPR-ISSUE2 – Key Management. What requirements are necessary to enable multiple DRM “domains of trust” to share a single encryption (and therefore, set of keys), without weakening the overall degree of trust? Who should initiate, manage, and distribute keys?

CPR-ISSUE3 – Key Uniqueness across Profiles, and Versions and Retailers. Do all profiles for a particular title share the same keys, or must key management support distinct [sets of] keys for each profile? [TWG 05/12/09 – encodings will differ, so assumption is that keys may differ and publishing process must support distinct sets of keys for each profile]

Must all versions of a title/profile use the same keys, or must key management support distinct [sets of] keys for each version? [TWG 05/12/09 – STILL OPEN but perhaps encodings will differ, so assumption is that keys may differ and publishing process must support distinct sets of keys for each version. Need to clarify and close]

Is the regional scope of keys global, or per-retailer? Must the publishing and fulfillment process support multiple per-retailer sets of keys for the same profile of the same title? What requirements would this introduce on the publishing process?

CPR-ISSUE4 – Encryption Sourcing. What requirements or non-requirements derive from top-level sourcing flexibility requirements for encryption of DECE content (i.e. content providers choose to encrypt themselves, choose the DSP of first retailer that they deal with to encrypt, deliver unencrypted content to all DSPs, or choose a 3rd party to encrypt). See also CPR-ISSUE6 Accountability for Container Generation.

CPR-ISSUE5 – Publishing Process Exception Handling Scope. Exception handling (both for pre-sale publishing, as well as post-sale transaction validation and fulfillment) is more or less currently out-of-scope, which means that it will be attacked manually and/or through fragmented approaches. Is this really scalable and workable?

CPR-ISSUE6 – Accountability for Container Generation. Is there any requirement on which DECE Role is accountable for DECE container generation (i.e. is that negotiable on a deal-by-deal basis among content provider, retailer, and DSP, or is it specified as part of the retailer/content provider/DSP DECE Agreements?). See also CPR-ISSUE4 Encryption Sourcing.

CPR-ISSUE7 – Metadata Versions. Are there any requirements regarding the ability to identify versions of metadata instances published to the ecosystem, independent from versions of content containers?

CPR-ISSUE8 – TakeDowns. Are there any requirements on the publishing system to quickly and reliably disable sale of content from within the ecosystem? Are there any requirements to physically remove or destroy content within the ecosystem?

CPR-ISSUES9 - Support for DLNA/UPnP. To allow the use of content to be pushed around the home and side loaded to various devices should it become a requirement of the publishing spec to support DLNA/UPnP?

CPR-ISSUES10 - Support for Bundling. Apart from the usual metadata that is used to categorize content genre, rating, show, season, episode etc; to want extent do we want to be able to bundle content (“Best of “ etc)?

6.2 Open Issues

There are no noted open publishing requirements issues as of this revision.

7 APPENDIX B – Logical Publishing Information Model

7.1 SKU Product s and Bundles

[CHS: These need to be updated.]

7.1.1 Logical Model

7.1.2 Examples

DECE Technical Specification: Content Publishing Requirements€¦ · DECE Confidential 7-Apr-15...

Documents

Transcript of DECE Technical Specification: Content Publishing Requirements€¦ · DECE Confidential 7-Apr-15...