DRM Combined Delivery and "Superdistribution"?

DRM Combined Delivery and "Superdistribution"? SearchSearch
Author Message
Nelson
New member
Username: Nelson

Post Number: 3
Registered: 01-2006
Posted on Monday, March 13, 2006 - 04:05 pm:   

Hi Bryce,

Thanks for your reply on Friday to my question about interfacing 2-way SMS with an XML-based information provider.

Now I have a different question for you.

I understand that the OMA DRM "Combined Delivery" technique must be used to enable "Superdistribution". But I don't understand how to do this with NowSMS 2006 and DRMCOMP. Is it possible?

I'm sure you already know this, but Superdistribution is a DRM method that allows the original recipient to redistribute the encrypted DRM content to other recipients. These new recipients have to come back to the original content provider in order to obtain rights to the object.

Thanks,

Nelson
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5640
Registered: 10-2002
Posted on Wednesday, March 15, 2006 - 04:39 am:   

Hi Nelson,

I've been afraid that someone was going to ask about this. It's not that there are any real technical barriers ... but rather that it is a rather involved topic, so it is going to take me longer to write-up an explanation of how it works.

The DRMCOMP utility is described in more detail at the following link:

http://www.nowsms.com/support/bulletins/tb-nowsms-015.htm

But, you are correct that we don't provide any discussion of DRM "super distribution" in that write-up.

You'll notice that one of the command line parameters for DRMCOMP specifies an optional "header file". And in the write-up that I reference above, we mention that this can be used to define a "rights issuer URL", which is a URL that can be embedded into the content, which the user can connect to in order to renew access to the content, would be included in a such a rights header file as "Rights-Issuer: http://server:port/path/etc".

Not only is this "rights issuer URL" used for renewing access to a piece of content, it is also the key to enabling superdistribution.

Basically, if a device has a piece of "separate delivery" content for which it does not have any access rights, the device will prompt the user if they wish to connect to this URL to acquire rights to the content.

How would we create this type of content?

It's probably best to use an example.

The attached ZIP file contains an image named orval.gif.

I'm going to add a separate delivery DRM wrapper to it and include a rights issuer URL, so that it can be setup for super distribution.

To define the rights issuer URL, I'm going to create a file named orval.hdr (also in the ZIP), with the following content:

Rights-issuer: http://support.nowsms.com/discus/examples/rights-request-orval.asp

Then, I'm going to use DRMCOMP to apply the separate delivery wrapper:

DRMCOMP orval.gif -separatedelivery -headerfile=orval.hdr -permission=display -limitcount=10

The DRM permissions and constraints (limits) are not particularly important here, I'm just using them as an example.

When we create a separate delivery object, DRMCOMP outputs two files. In this case, orval.dcf and orval.dr are created. (I've also included these files in the ZIP.)

orval.dcf is the object. If you want to put this object on a web server, you need to associate the ".dcf" file extension with the MIME type "application/vnd.oma.drm.content". (You could also send it to the phone in an MMS or Multimedia WAP Push ... I probably would use Multimedia WAP Push instead of MMS because the object is protected and won't be visible within the MMS.)

orval.dr is a rights object that can be used to enable the object so that it can actually be used. When an object is delivered with separate delivery, by default it cannot be used or viewed without being activated by a rights object.

You can send the rights object via the "Send XML Settings" interface in NowSMS.

When you include a "Rights Issuer" URL, the device can connect to this URL to request that a rights object. The rights object itself has to be delivered via WAP Push, it can't be delivered through the URL request directly over the WAP channel. So this "rights issuer" URL would need to be able to validate the user request and trigger the rights object to be delivered via WAP Push.

For example, when I download the orval.dcf file from the attached ZIP to a SonyEricsson W800, and I try to view it, the phone displays a message that asks: "You need to activate this file before you can use it. Activate Now?" If I select Yes, the phone automatically loads the browser and connects to the "Rights-Issuer" URL that we embedded in the header.

I created a simple ASP script at the rights issuer URL that I embedded into this example. It prompts for a phone number and password. If you supply "test" as the password, the script posts the rights object to a NowSMS server so that it can be delivered to the specified phone number. (We've put limits on how many times this script can be called each day, so if you try it, you might encounter an error.) I've included a generic copy of this ASP script (rights-request-orval.asp) in the attached ZIP to allow you to further experiment based upon this example.

So how does "super distribution" fit into all of this?

When you have "forward lock" or "combined delivery" content, the device should prevent you from forwarding the content to another user, or in any way transferring the content off of the device. However, "separate delivery" content can be forwarded or transferred off of the device. The forwarded content is not initially usable, because it is protected. However, when the recipient attempts to access the content, the device should prompt the recipient to connect to the "rights issuer" in order to activate the content. That's the concept behind super distribution.

Now, the only problem with all of this ...

In the process of testing this, I did discover that the DRMCOMP utility was not creating "combined delivery" files correctly. There was an encoding error that occurred on most (but not all files). So I just refreshed the NowSMS 2006 download prior to posting this message to include a copy of DRMCOMP.EXE that fixes this problem.

-bn


application/x-zip-compresseddrmcomp.zip
drmcomp.zip (67.2 k)