TVAF - RMP

1. TVAF - RMP Kobe Meeting November 2003 Final Plenary

2. Reviewed contributions • AN560: Share It! European project, peer-to-peer network • AN564: Security levels for RMPI Micro Broadcast from MMG • AN566: Security robust ranges for removable media from NHK • AN568 did not show up on reflector

3. Presentations • Makoto Yoshioka (MMG) on secure UDF, complementing AN566 • Metadata working group on e-flyer

4. RMPI-Micro for Broadcast • Reviewed WD822/TV211 and removed most question marks, new draft WD862 includes tentatively approved rights and conditions matrix • Developed our thinking on the notions of profiles and domains • RMPI domain and profile considerations in WD871

5. Rights and conditions • PLAY • Minimum security level of rendering device, shelf life / duration, expiration, geographic restriction • EXPORT • Minimum security level of exporting device, Analogue HD/SD, digital HD/SD • INTER-DOMAIN TRANSFER • Geographic restrictions

6. Profiles • Profiles are intended to provide means to enable the characterization of devices with respect to their functions with security implications for rights enforcement. • Profiles: RMP functions -> RMP components -> security level

7. 2 levels of profile structure • The functional level, at which distinct processes necessary to enable usage cases are defined, and are mapped to rights granted within the rights and conditions matrix (PLAY, EXPORT, INTERDOMAIN TRANSFER); • The component level, at which discreet components required to support the functional processes are defined (MPEG-2 decode, secure time, etc.)

8. Security levels • Security levels will be established with respect to individual RMP components. • Only utilized components invoked by a given RMPI will be required to have a minimum RMPI-defined security level. • RMPI-MB indicates overall minimum security level of the invoked components.

9. Profiles need: • a formalized data structure • a renewability & extensibility approach, • approved component table structure, or a method for referring to external tables • TVAF defined default component sets • certification compliance regime requirements, including: identifying certifying body and indicating which component security levels are certified

10. Domain • Definition: “A set of TVAF RMP-compliant devices that are securely bound to each other for the purpose of exchanging protected content”.

11. Domain establishment • Domains all start with at least one compliant device with a defined compliant functional profile • Subsequent devices are added to a domain under the control of one or more devices that are members of the domain.

12. Enforcement of rights in domain • Enforcement of rights within a domain can be constrained according to device traits • Permitted device count is handled by either: • Domain membership limits established by a compliance body(?) • Signaled in RMPI(?) Or the number of devices permitted to simultaneously view the content…(…beyond micro?)

13. Other domain considerations • Device registration within domain should not depend on device profile, device profiles are relevant at the point of content consumption or activation of rights, not as a prerequisite to domain membership. • Securely bound does not imply permanent live connection, but must encompass use cases that include removable media.

14. Still a lot to do… • Contributions required: • Definition of components • Definition of security levels • Mapping of components to functions • Domain establishment and membership requirements • Re-issue bundle of RMP draft specification components to be used as reference documents