Suggested resolution for DMBM #8 TRU TBDs

 

• Cross-listing of DMBM #8 PAV TRU TBDs and GA01 RQs
• Fuller treatment of problematic RQ-TRU assignments from CraigPhil RQs
• Conclusions - proposed changes to DMBM #8

 

The need to resolve PAV RQs for TRUs 18, 27, 29, 58, 62 and 68 is referred to at DMBM #8 template http://www.chiariglione.org/contrib/040518merrill01.htm. Conflicts arise with Heidelberg GA01 RQs at http://www.dmpf.org/project/ga01/requirements.htm because the cross-listed TRUs were arrived at somewhat loosely based on general mental association. The GA01 cross-listings to RQs are inadequate if we are to pursue Craig's approach (recently endorsed by Leonardo) of wanting to restrict RQs by category for eventual strict specification, so support for a given TRU category will eventually resolve down to engineering a DMP spec.

Based on reasoning elaborated below (with TRU sources to be clearly indicated on a revision of the DMBM #8 template) this would add the following RQs to the GA02 PAV RQ list at http://www.dmpf.org/project/ga02/PAV_reqs.htm:

• placing of links to a piece of DMP content by a DMP user
  
• The ability to provide for and contain within digital media, verifiable metadata containing a rating as well as the system on which the rating was made.
  
• removal of a piece of DMP content that has been declared prohibited by a DMP user with the appropriate authority from public access
  
• The ability to determine applicable mandated restrictions in a given region.
  
• making a piece of content available to a community of DMP users at a time that is different from another community
  
• The ability to base the granting of access on time restrictions or the ability to determine the length of “rental” upon which to base payment.
  
• free choice of delivery systems independently of the media item and the license
• trust relationships to be determined as existing between DMP DRM compliant devices, applications, services, and DMP DRM compliant bitstreams/files
  
• the secure transfer of governed DMP DRM compliant bitstreams/files in cleartext over unsecure channels
  
• a DMP bitstream/file to exist in a DRM governed state unless stored in or accessed from a DMP DRM compliant device or virtual environment
  
• the transfer and use of DMP DRM compliant bitstreams/files between one given DMP DRM compliant DRM implementation and another DMP DRM compliant DRM implementation
  
• the implementation of the loan, transfer by intent (including but not limited to by inheritance or last will and testament), or deletion of DMP DRM compliant bitstreams/files
  
• efficient access control
  
• the ability to create a personal or commercial descriptive set of metadata (whether with the DMP bitstream/file or scattered) and assign its annotative structure to work in conjunction with the ID information and structure of the source DMP file/bitstream being annotated, commented on, analyzed, or otherwise described.

This is offered purely in the spirit of continuing urgent to-be-determined work, the scope of which was defined in the April 29 IED-s breakout at GA02.

 

Cross-listing of DMBM #8 PAV TRU TBDs and GA01 RQs

The cross-listing of PAV TRUs to (problematic) GA01 RQs is as follows:

• TRU #18 to apply a rating to a piece of content
  • GA01 RQ #21 placing of links to a piece of DMP content by a DMP user
    Comment: This is clearly inadequate. Also linking with quoting needs to be resolved.
• TRU #27 to make prohibited content inaccessible
  • GA01 RQ #26 removal of a piece of DMP content that has been declared prohibited by a DMP user with the appropriate authority from public access
    Comment: This is acceptable and more or less mandatory for a consumer device
  • GA01 RQ #44 & RQ #45
    Comment: As explained below, these two RQs should only be assigned TRU #62. So they don't belong here and the TRU cross-reference should be deleted in future.
    GA01 RQ #51 efficient access control
    Comment: I suggest we delete this here while keeping its existing link to TRU 62.
• TRU #29 for digital media rental
  • GA01 RQ #28 making a piece of content available to a community of DMP users at a time that is different from another community
    Comment: This is inadequate although it is pointed in the right direction. Consideration of standard DRM configuration options - esp RELish #burns, expiration date, etc. - should be considered here
  • GA01 RQ #44 & RQ #45
    Comment: As above, 44-45 should only be TRU #62, so not 29.
• TRU #58 to choose the delivery system
  • GA01 RQ #46 the transfer and use of DMP DRM compliant bitstreams/files between one given DMP DRM compliant DRM implementation and another DMP DRM compliant DRM implementation
    Comment: 46 is problematic mainly because it is both very broad and very narrow. I recommend we delete this.
    
  • GA01 RQ #83 To easily access the media with no further manual operation after the license is obtained for the first time
    Comment: This is too narrow, although it could be supported. So combined with the scope-problem of GA01 RQ #46 we are left with a varied approach in the direction of TRU #58 but that however falls short of supporting what is a very important TRU. I recommend we delete this. New RQ(s) needed.
• TRU #62 of applying technological access restrictions
  • GA01 RQ #43 trust relationships to be determined as existing between DMP DRM compliant devices, applications, services, and DMP DRM compliant bitstreams/files
    GA01 RQ #44 the secure transfer of governed DMP DRM compliant bitstreams/files in cleartext over unsecure channels
    GA01 RQ #45 a DMP bitstream/file to exist in a DRM governed state unless stored in or accessed from a DMP DRM compliant device or virtual environment
    GA01 RQ #46 the transfer and use of DMP DRM compliant bitstreams/files between one given DMP DRM compliant DRM implementation and another DMP DRM compliant DRM implementation
    GA01 RQ #49 the implementation of the loan, transfer by intent (including but not limited to by inheritance or last will and testament), or deletion of DMP DRM compliant bitstreams/files
    Comment: All of these, in my recommendation, should only be listed under TRU #62 technological access restrictions.
    GA01 RQ #51 efficient access control
    Comment: I see no problem with this keeping its existing link to TRU 62.
• TRU #68 to assign content description
  • NO GA01 RQ so we must make an RQ for it because this is required.
    Comment: This is closely related to DEU #40 issues - Applying descriptions, ratings, processing and/or governance to a DM at the granularity required by the application.

 

Fuller treatment of problematic RQ-TRU assignments from CraigPhil RQs

So, now for the fuller treatment of TRUs 43-46 and 49. These come from the CraigPhil document http://www.dmpf.org/open/dmp0025.doc and match as follows:

• GA01 RQ #43 trust relationships to be determined as existing between DMP DRM compliant devices, applications, services, and DMP DRM compliant bitstreams/files
  • [begin CraigPhil]
    6. "DMP devices"
    The following requirements apply mainly to the TRU to make playback device.
    6.1. "trust relationship"
    In any system where content of any value at all is processed, the processing must be done in systems trusted to the level that the owner of the content feels is sufficient to protect the owner’s property.
    Requirement: DMP DRM shall support trust relationships to be determined as existing between DMP DRM compliant devices, applications, services, and DMP DRM compliant bitstreams/files.
    Example: An already purchased good may be downloaded from a website because a trust relationship permits the data access and transfer.
    [end CraigPhil]
    Comment: I believe that this RQ is purely for support of TRU #62 to technological access restrictions. I certainly intended it that way when I wrote it. It is really a low-level implementation requirement. And my more up-to-date thoughts about "trust" all have to do with either algorithms or else that BSI link Martin provided: http://www.bsi.de/trustcomp/stellung/StellungnahmeTCG1_2a_e.pdf - Unfortunately the presently listed TRUs for this RQ are ludicrous and as follows: 5, 36, 37, 39-51, 56, 60, 62-66, 73, 75. Inspection of the list of GA01 RQs reveals that once the list gets to 43, it more or less explodes with references to TRUs. But this is all casual thinking on Craig's part, reflecting February 2004's free-association period rather than April 2004's restrictive approach. So perhaps I am excessive to want this RQ to only link to TRU #62 to technological access restrictions, but pruning is a must here.
• GA01 RQ #44 the secure transfer of governed DMP DRM compliant bitstreams/files in cleartext over unsecure channels
  • [begin CraigPhil]
    6.2. "protected cleartext"
    To cover "all the bases", DMP should assume and support the worst conditions existing. Although many communication protocols include some security measures, the usual case is for a new communication method to be created and then years later, a method to secure it is finally realized. Also, requiring the encryption of all content is many times not necessary and most times inefficient. Providing support for using existing secure methods as well as a secure base for future possibilities will extend the useful lifetime of the DMP specifications.
    Requirement: DMP DRM shall support the secure transfer of governed DMP DRM compliant bitstreams/files in cleartext over unsecure channels.
    Example: Governed content is stored on a secure home server in the clear and then transmitted over wireless using DTCP to the family entertainment system. It is stored and transmitted as cleartext but the unsecure channel that it is transmitted across is made secure.
    [end CraigPhil]
    Comment: 44's ludicrously big list of related TRUs is: 5, 6, 8, 9, 10, 15, 23, 24, 27, 28-30, 32, 34-45, 47-66, 71, 73, 75. Pruning required. This also was intended purely for TRU #62 as a low-level implementation reflecting the governance or "secure environment" technology of "today" so to speak.
• GA01 RQ #45 a DMP bitstream/file to exist in a DRM governed state unless stored in or accessed from a DMP DRM compliant device or virtual environment
  • [begin CraigPhil]
    6.3. "scope of governance"
    This requirement is similar to 6.2 in that it is a general requirement for any management system.
    Requirement: DMP DRM shall support a DMP bitstream/file to exist in a DRM governed state unless stored in or accessed from a DMP DRM compliant device or virtual environment.
    Example: A DMP DRM-governed video file has been burned onto a DVD-R. It can be accessed and used in a home network.
    [end CraigPhil]
    Comment: 5, 6, 8, 9, 10, 15, 23, 24, 27, 28-30, 32, 34-45, 47-66, 71, 73, 75 - This is the same as 44, and so GA01 RQ 44-45 are identically cross-linked with 47 TRUs. This is clearly excessive. And as above, this is the "secure environment" side of the general data "governance" issue so only TRU #62 is required in my opinion.
• GA01 RQ #46 the transfer and use of DMP DRM compliant bitstreams/files between one given DMP DRM compliant DRM implementation and another DMP DRM compliant DRM implementation
  • [begin CraigPhil]
    6.5. "inter-device transfer"
    This requirement primarily applies to the TRU to choose playback device. If DMP compliant content is delivered via non-physical media methods, without inter-device transfer capabilities, the end-user will not be able to choose the playback device but instead, would only be able to choose the receiving device.
    Requirement: DMP DRM shall support the transfer and use of DMP DRM compliant bitstreams/files between one given DMP DRM compliant DRM implementation and another DMP DRM compliant DRM implementation.
    Example: Two musicians in the Gobi desert have audio-equipped tablet devices and are taking turns composing tracks for a song file. Whether through cords or wirelessly, they are able to exchange updated versions of the song file.
    [end CraigPhil]
    Comment: The listed TRUs for this are: 2, 3, 5, 6, 10, 25, 26, 34, 36, 55, 57, 58, 62, 65, 71, 75 - What a relief after RQs 44 and 45 to only encounter a mere 16 TRUs. But this has more to do with fundamental infrastructure for interoperability between devices...no way does that need a lot of TRUs. I recommend assigning this to TRU #62 as well, because the ability to do this requires a high level of security.
• GA01 RQ #49 the implementation of the loan, transfer by intent (including but not limited to by inheritance or last will and testament), or deletion of DMP DRM compliant bitstreams/files
  • [begin CraigPhil]
    7. "configurable TRUs, Digitally enabled operations (DEO)"
    The following requirements deal specifically with end-user TRUs.
    [Requirement: DMP DRM shall provide specifications for DMP DRM compliant implementations supporting the following digitally enabled operations (DEOs) as determined by rights expressions and conditions associated with a given DMP DRM compliant bitstream/file and is configurable to support requirements imposed by the laws of regional jurisdictions or by the terms and conditions of legally acceptable binding agreements.]
    7.3. "transferability TRU"
    TRU of "First sale"/Personal loan
    Requirement DMP DRM shall technically support the implementation of the loan, transfer by intent (including but not limited to by inheritance or last will and testament), or deletion of DMP DRM compliant bitstreams/files.
    Example: Private "estate sale" of used digital goods in order to raise money for the outstanding debts of the deceased.
    [end CraigPhil]
    Comment: 49 is linked with TRUs 25, 33-37, 42, 48-50, 62, 73 but this is absurd since the submission has it in the DEU category. Note that this relates to the concept of "digital goods". I recommend assigning this to TRU #62 as well, because the ability to do this requires a high level of security.

 

Conclusions - proposed changes to DMBM #8

I propose the following regarding how I might amend DMBM #8 so that TBD TRUs and RQs are well aligned:

• TRU #18 - Keep GA01 RQ #21 but since this needs something more, I propose we add the following proposed RQ language from TRU #18's template http://www.chiariglione.org/contrib/040115schultz02.htm as a new requirement:
  
  proposed new RQ: The ability to provide for and contain within digital media, verifiable metadata containing a rating as well as the system on which the rating was made.
  
  
• TRU #27 - Keep GA01 RQ #26 (delete linkage with 44 & 45), but it also is worth adding the following proposed RQ language from TRU #27's template http://www.chiariglione.org/contrib/040115schultz03.htm as a new requirement:
  
  proposed new RQ: The ability to determine applicable mandated restrictions in a given region.
  
  
• TRU #29 - Keep GA01 RQ #28 (delete linkage with 44 & 45), but since this needs something more, I propose we add the following proposed RQ language from TRU #29's template http://www.chiariglione.org/contrib/040115schultz06.htm as a new requirement:
  
  proposed new RQ: The ability to base the granting of access on time restrictions or the ability to determine the length of “rental” upon which to base payment.
  
  
• TRU #58 - Although GA01 #83 could still be linked to this, on balance of consideration I would say it doesn't belong. We need new RQ language for this very important requirement, and unfortunately the template (http://www.chiariglione.org/contrib/040303springer01.htm) doesn't offer specific prose. My approach was to consult the "choice of technology" entries in the sorting job I did on the GA01 RQs at http://www.chiariglione.org/contrib/040330merrill01.htm#choice. I am confident others could look at those and derive something better than my suggestion that - for now - we modify GA01 RQ #61 to apply to delivery systems, as follows:
  
  proposed new RQ: free choice of delivery systems independently of the media item and the license
  
  
• TRU #62 - Links to GA01 RQs 43, 44, 45, 46, 49 and 51, as before. So this is now fine. We marked #62 TBD in the IED-s breakout because of the need to correct the explosively numerous linkings of RQs 43-46 & 49.
  
  
• TRU #68 - Since this needs something and the template (http://www.chiariglione.org/contrib/040216springer01.htm) doesn't offer specific prose, this is what I came up with for a working RQ:
  
  proposed new RQ: the ability to create a personal or commercial descriptive set of metadata (whether with the DMP bitstream/file or scattered) and assign its annotative structure to work in conjunction with the ID information and structure of the source DMP file/bitstream being annotated, commented on, analyzed, or otherwise described.

Before proceeding to lump these results together, let me note that the RQs for DEU 23 Expressing contracts and rights should be reexamined to reflect whatever led to the name of this DEU being changed from its previous "determining entitlements" title...which affects the way the requirements for DEU 23 were worded. This is also an opportunity to mention that DEU templates from GA02 need to be updated (including by me) to incorporate the RQs from the IED-s breakout (contained in the DMBM #8 template).

So here are the proposed RQs, derived from the above reasoning, all lumped together as if they were continuing the PAV RQ list at http://www.dmpf.org/project/ga02/PAV_reqs.htm:

38. placing of links to a piece of DMP content by a DMP user
39. The ability to provide for and contain within digital media, verifiable metadata containing a rating as well as the system on which the rating was made.
40. removal of a piece of DMP content that has been declared prohibited by a DMP user with the appropriate authority from public access
41. The ability to determine applicable mandated restrictions in a given region.
42. making a piece of content available to a community of DMP users at a time that is different from another community
43. The ability to base the granting of access on time restrictions or the ability to determine the length of “rental” upon which to base payment.
44. free choice of delivery systems independently of the media item and the license
45. trust relationships to be determined as existing between DMP DRM compliant devices, applications, services, and DMP DRM compliant bitstreams/files
46. the secure transfer of governed DMP DRM compliant bitstreams/files in cleartext over unsecure channels
47. a DMP bitstream/file to exist in a DRM governed state unless stored in or accessed from a DMP DRM compliant device or virtual environment
48. the transfer and use of DMP DRM compliant bitstreams/files between one given DMP DRM compliant DRM implementation and another DMP DRM compliant DRM implementation
49. the implementation of the loan, transfer by intent (including but not limited to by inheritance or last will and testament), or deletion of DMP DRM compliant bitstreams/files
50. efficient access control
51. the ability to create a personal or commercial descriptive set of metadata (whether with the DMP bitstream/file or scattered) and assign its annotative structure to work in conjunction with the ID information and structure of the source DMP file/bitstream being annotated, commented on, analyzed, or otherwise described.

As stated above, this is offered purely in the spirit of continuing urgent to-be-determined work, the scope of which was defined in the April 29 IED-s breakout at GA02.