Digital Rights Management

NowSMS provides full support for OMA Digital Rights Management (DRM) v1.0, with support for forward lock, combined delivery and separate delivery.

“Forward Lock” is the most basic level of DRM. When “Forward Lock” is enabled, this indicates that the receiving device should not allow any non-text objects in the message to be forwarded off of the device. The device may allow the user to extract pictures, videos or sounds from the message and save them on the phone. However, any such objects remain forward locked, such that they cannot be forwarded to another user or transferred to another device.

More advanced DRM restrictions can be applied to limit the number of times that the user can access an object, or start and end dates can be specified to limit how long the user can access an object. The restrictions can only be applied when using either “Combined Delivery” or “Separate Delivery”.

When using either “Combined Delivery” or “Separate Delivery”, a rights object is associated with the DRM protected object. This rights object defines permissions and constraints for how the DRM protected object may be used by the receiver.

“Combined Delivery” means that both the protected object and the rights object are delivered simultaneously. The protected object and its rights object are packaged as a multipart/related MIME object, which is usually retrieved by the receiving client via HTTP download or as part of the content of an MMS message.

“Separate Delivery” means that the protected object and the rights object are delivered separately. The protected object is retrieved by the receiving client via HTTP download or as part of the content of an MMS message. However, the protected object is locked and cannot be used until a rights object is separately delivered. In this case, the rights object is usually sent via WAP Push over SMS (sometimes premium rate SMS).

When using “Forward Lock” or “Combined Delivery”, the DRM protected object is not actually encrypted. The protocol was designed in this lightweight fashion in order to allow DRM to be implemented on low end devices with limited capabilities.

Only when a DRM protected object is sent using “Separate Delivery” can the protected object actually be delivered to the device in an encrypted format.

DRM with the NowSMS Web Interface

The web interface of NowSMS offers built-in support using “Forward Lock” or “Combined Delivery” when sending MMS or Multimedia WAP Push content. When sending an either of these message types, it is possible to specify Digital Rights Management (DRM) restrictions over the content of the message.

The most basic level of DRM is forward locking. When “Forward Lock” is set to “Yes”, this indicates that the receiving device should not allow any non-text objects in the message to be forwarded off of the device. The device may allow the user to extract pictures, videos or sounds from the message and save them on the phone. However, any such objects remain forward locked, such that they cannot be forwarded to another user or transferred to another device.

More advanced DRM restrictions can be applied to limit the number of times that the user can access an object, or start and end dates can be specified to limit how long the user can access an object.

These advanced DRM restrictions can be applied by setting “Restrict Content w/ DRM” to “Yes”. When this setting is enabled, forward lock is also implied, and the value of the “Forward Lock” setting is ignored.

“DRM Permissions” specify what types of access are allowed against the object. For example, an audio or video object requires “Play” permission before the user can access it. An image requires “Display” permission before the user can access it, and it requires “Print” permission if the user is to be allowed to print the image to a printer , perhaps over Bluetooth. An application requires “Execute” permission before the user can make use of the application. In all cases, the forward locking is assumed, so that the user is not allowed to forward or transfer the object from the device.

If you are sending multiple types of objects in the MMS message, check all permissions that are required for the different types of objects that you are sending.

“DRM Constraints” specify constraints with regard to how long the object should remain accessible to the user. It is possible to specify one or more of these constraints.

“# of Accesses (count)” specifies the the user can only access the object this number of times before access is no longer allowed.

“Start Date (yyyy-mm-dd)” specifies that the user will not be allowed to access the object until on or after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2006-02-24.)

“End Date (yyyy-mm-dd)” specifies that the user will not be allowed to access the object after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2006-02-24.)

“# of Days (interval)” specifies that the user will be allowed to access the object for this number of days after initial receipt of the object. The user can either enter a number of days here, or they can enter any valid value defined for the “<interval>” element in the OMA DRM Rights Expression Language specification. For example, P2Y10M15DT10H30M20S represents a duration of 2 years, 10 months, 15 days, 10 hours, 30 minutes and 20 seconds.

DRM when interfacing with NowSMS Programmatically

NowSMS also provides support for sending DRM protected objects when interfacing to NowSMS programmatically.

When submitting an MMS message or Multimedia WAP Push message, it is possible to set parameters to indicate that the message content should be protected with DRM. This support is only available when messages are submitted via the Now SMS & MMS Proprietary URL Submission method.

Of course, NowSMS also supports DRM protected content that is submitted via the standardised MMS protocols (i.e., MM7, MM4, MM1). However, when these standard protocols are used, it is required that the content already be wrapped with DRM protection before it is submitted to NowSMS. When the Now SMS & MMS Proprietary URL Submission method is used, NowSMS can apply the DRM protection automatically.

The following section will detail extensions to the Now SMS & MMS Proprietary URL Submission method which allow for NowSMS to apply a DRM wrapper to the message content.

This will be followed by a section that describes the DRMCOMP command line utility which is a command line utility for applying DRM protection to an object. The DRMCOMP utility can be used to create protected objects that can be sent using DRM “Separate Delivery”, in addition to support for the “Combined Delivery and “Forward Lock” formats.

DRM Forward Lock and Combined Delivery

When submitting an MMS message or Multimedia WAP Push message to NowSMS using the Now SMS & MMS Proprietary URL Submission method (page 178), it is possible to specify additional parameters that are used to specify DRM protection.

These parameters can be specified either as part of the URL request (e.g., &parameter=value), or using the HTTP POST multipart/form-data encoding.

MMSForwardLock MMS Message, Multimedia WAP Push Forward locking is the most basic level of DRM (Digital Rights Management). When “Forward Lock” is set to “Yes”, this indicates that the receiving device should not allow any non-text objects in the message to be forwarded off of the device. The device may allow the user to extract pictures, videos or sounds from the message and save them on the phone. However, any such objects remain forward locked, such that they cannot be forwarded to another user or transferred to another device.
DRMRestrict MMS Message, Multimedia WAP Push Beyond forward locking, More advanced DRM (Digital Rights Management) restrictions can be applied to limit the number of times that the user can access an object, or start and end dates can be specified to limit how long the user can access an object.

These advanced DRM restrictions can be applied by setting “DRMRestrict” to “Yes”. When this setting is enabled, forward lock is also implied, and the value of the “MMSForwardLock” setting is ignored.

DRMRestrictTextXML MMS Message, Multimedia WAP Push “Yes” specifies that the rights object should be encoded in text XML format. “No” specfies that the rights object should be encoded in binary XML format. The default is “No”.
“DRM Permissions” specify what types of access are allowed against the objects in a message that is protected with DRM.

For example, an audio or video object requires “Play” permission before the user can access it. An image requires “Display” permission before the user can access it, and it requires “Print” permission if the user is to be allowed to print the image to a printer , perhaps over Bluetooth. An application requires “Execute” permission before the user can make use of the application. In all cases, the forward locking is assumed, so that the user is not allowed to forward or transfer the object from the device.

If you are sending multiple types of objects in the MMS message, check all permissions that are required for the different types of objects that are being sent.

DRMPermissionPlay MMS Message, Multimedia WAP Push Set to “Yes” to enable DRM “Play” Permission.
DRMPermissionDisplay MMS Message, Multimedia WAP Push Set to “Yes” to enable DRM “Display” Permission.
DRMPermissionExecute MMS Message, Multimedia WAP Push Set to “Yes” to enable DRM “Execute” Permission.
DRMPermissionPrint MMS Message, Multimedia WAP Push Set to “Yes” to enable DRM “Print” Permission.
“DRM Constraints” specify constraints with regard to how long a DRM protected object object should remain accessible to the user.

It is possible to specify one or more of these constraints that follow.

DRMConstraintCount MMS Message, Multimedia WAP Push “# of Accesses (count)” specifies the the user can only access the DRM protected object this number of times before access is no longer allowed.
DRMConstraintStart MMS Message, Multimedia WAP Push “Start Date (yyyy-mm-dd)” specifies that the user will not be allowed to access the DRM protected object until on or after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2006-02-24.)
DRMConstraintEnd MMS Message, Multimedia WAP Push “End Date (yyyy-mm-dd)” specifies that the user will not be allowed to access the DRM protected object after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2006-02-24.)
DRMConstraintInterval MMS Message, Multimedia WAP Push “# of Days (interval)” specifies that the user will be allowed to access the DRM protected object for this number of days after initial receipt of the object. The user can either enter a number of days here, or they can enter any valid value defined for the “<interval>” element in the OMA DRM Rights Expression Language specification. For example, P2Y10M15DT10H30M20S represents a duration of 2 years, 10 months, 15 days, 10 hours, 30 minutes and 20 seconds.

DRMCOMP Utility & DRM Separate Delivery

The DRMCOMP command line utility can be used to add a wrapper of DRM protection to a content object. DRM wrappers are added to individual pieces of content, such as an image or video, and not to an entire MMS message.

The DRMCOMP command line utility can be used to add DRM wrappers for forward lock, combined delivery or separate delivery.

DRMCOMP – Forward Lock

Usage: (Forward lock)

DRMCOMP objectFilename -forwardlock [-contentType=type/subtype]

[-out=outputFilename]

objectFilename – This is the name of the file that is to have the DRM wrapper applied.

-forwardlock – This parameter indicates that a forward lock DRM wrapper should be added to the message.

-contentType=type/subtype – This optional parameter defines the MIME content type associated with the object (e.g., image/jpeg, audio/mp3). If this parameter is not specified, DRMCOMP will attempt to identify the content type automatically based upon the file extension. To determine the file extension to MIME type mapping, DRMCOMP will consult the NowSMS MMSCTYPE.INI file, if present, and will then search the MIME file extension to content type database in the Windows registry.

-out=outputFilename – This optional parameter specifies the output file name to contain the content with the DRM wrapper. If no filename is specified, DRMCOMP will default to the input objectFilename parameter, changing the file extension to “.dm”.

Forward-lock DRM objects have a MIME type of “application/vnd.oma.drm.message”. Note, however, that if you store a forward lock file on a conventional web server, some mobile phones may not properly understand the content. The reason for this is because the “application/vnd.oma.drm.message” format uses MIME multipart encoding. The Content-Type header returned from the web server should indicate, Content-Type: application/vnd.oma.drm.message; boundary=drm-boundary. It is not possible to configure most web servers to return a boundary parameter. While the OMA specifications suggest that a device should be able to understand a DRM object even if the boundary parameter is not present in the Content-Type header, this could present potential problems.

For convenience, DRMCOMP uses a fixed boundary parameter of “–generic-drm-boundary”. Therefore, the Content-Type header for any forward-lock DRM objects created by DRMCOMP should be:

Content-Type: application/vnd.oma.drm.message; boundary=”–generic-drm-boundary”

DRMCOMP – Combined Delivery

Usage: (Combined delivery)

DRMCOMP objectFilename -combineddelivery [-permission=play]

[-permission=display]

[-permission=execute]

[-permission=print]

[-limitCount=###]

[-limitStartDate=yyyymmdd]

[-limitEndDate=yyyymmdd]

[-limitDays=###]

[-contentType=type/subtype]

[-contentID=cid]

[-textXML]

[-out=outputFilename]

objectFilename – This is the name of the file that is to have the DRM wrapper applied.

-combinedDelivery – This parameter indicates that a combined delivery DRM wrapper should be added to the message.

“DRM Permissions” specify what types of access are allowed against the objects in a message that is protected with DRM. The “permission=” parameters specify these permissions.

For example, an audio or video object requires “Play” permission before the user can access it. An image requires “Display” permission before the user can access it, and it requires “Print” permission if the user is to be allowed to print the image to a printer , perhaps over Bluetooth. An application requires “Execute” permission before the user can make use of the application. In all cases, the forward locking is assumed, so that the user is not allowed to forward or transfer the object from the device.

-permission=play – Enables “Play” permission for the protected object.

-permission=display – Enables “Display” permission for the protected object.

-permission=execute – Enables “Execute” permission for the protected object.

-permission=print – Enables “Print” permission for the protected object.

“DRM Constraints” specify constraints with regard to how long a DRM protected object object should remain accessible to the user.

It is possible to specify one or more of these “limit” constraints that follow.

-limitCount=### – Specifies the the user can only access the DRM protected object this number of times before access is no longer allowed

-limitStartDate=yyyymmdd – Specifies that the user will not be allowed to access the DRM protected object until on or after the specified date.

-limitEndDate=yyyymmdd – Specifies that the user will not be allowed to access the DRM protected object after the specified date

-limitDays=### – Specifies that the user will be allowed to access the DRM protected object for this number of days after initial receipt of the object. The user can either enter a number of days here, or they can enter any valid value defined for the “<interval>” element in the OMA DRM Rights Expression Language specification. For example, P2Y10M15DT10H30M20S represents a duration of 2 years, 10 months, 15 days, 10 hours, 30 minutes and 20 seconds.

-contentType=type/subtype – This optional parameter defines the MIME content type associated with the object (e.g., image/jpeg, audio/mp3). If this parameter is not specified, DRMCOMP will attempt to identify the content type automatically based upon the file extension. To determine the file extension to MIME type mapping, DRMCOMP will consult the NowSMS MMSCTYPE.INI file, if present, and will then search the MIME file extension to content type database in the Windows registry.

-contentID=cid – This optional parameter defines a “Content-ID:” header to be included to identify the object. If this parameter is not present, DRMCOMP will generate one automatically. Should the object expire due to DRM constraints, it is possible to send a separate delivery rights object to re-enable this object, but the separate delivery rights object needs to specify the “Content-ID” of the object. If you have a requirement to be able to send a separate delivery rights object to re-enable the object, then you should manually define the “Content-ID” field.

-textXML – This optional parameter specifies that the rights object should be encoded in text XML format instead of the default binary WBXML format.

-out=outputFilename – This optional parameter specifies the output file name to contain the content with the DRM wrapper. If no filename is specified, DRMCOMP will default to the input objectFilename parameter, changing the file extension to “.dm”.

Combined delivery DRM objects have a MIME type of “application/vnd.oma.drm.message”. Note, however, that if you store a combined delivery file on a conventional web server, some mobile phones may not properly understand the content. The reason for this is because the “application/vnd.oma.drm.message” format uses MIME multipart encoding. The Content-Type header returned from the web server should indicate, Content-Type: application/vnd.oma.drm.message; boundary=drm-boundary. It is not possible to configure most web servers to return a boundary parameter. While the OMA specifications suggest that a device should be able to understand a DRM object even if the boundary parameter is not present in the Content-Type header, this could present potential problems.

For convenience, DRMCOMP uses a fixed boundary parameter of “–generic-drm-boundary”. Therefore, the Content-Type header for any combined delivery DRM objects created by DRMCOMP should be:

Content-Type: application/vnd.oma.drm.message; boundary=”–generic-drm-boundary”

DRMCOMP – Separate Delivery

Usage: (Separate delivery)

DRMCOMP objectFilename -separatedelivery [-headerFile=headerFilename]

[-permission=play]

[-permission=display]

[-permission=execute]

[-permission=print]

[-limitCount=###]

[-limitStartDate=yyyymmdd]

[-limitEndDate=yyyymmdd]

[-limitDays=###]

[-contentType=type/subtype]

[-contentID=cid]

[-key=16Text-Or-32Hex-Characters]

[-out=outputFilename]

[-outRights=outputRightsFilename]

objectFilename – This is the name of the file that is to have the DRM wrapper applied.

-separateDelivery – This parameter indicates that a separate delivery DRM wrapper should be added to the message.

-headerFile=headerFilename – This optional parameter identifies a text header file that contains additional headers to be inserted into the header of the DRM object. (See Section 5.2.4 of the DRM Content Format Version 1.0 specification.) For example, 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”.

“DRM Permissions” specify what types of access are allowed against the objects in a message that is protected with DRM. The “permission=” parameters specify these permissions.

For example, an audio or video object requires “Play” permission before the user can access it. An image requires “Display” permission before the user can access it, and it requires “Print” permission if the user is to be allowed to print the image to a printer , perhaps over Bluetooth. An application requires “Execute” permission before the user can make use of the application. In all cases, the forward locking is assumed, so that the user is not allowed to forward or transfer the object from the device.

-permission=play – Enables “Play” permission for the protected object.

-permission=display – Enables “Display” permission for the protected object.

-permission=execute – Enables “Execute” permission for the protected object.

-permission=print – Enables “Print” permission for the protected object.

“DRM Constraints” specify constraints with regard to how long a DRM protected object object should remain accessible to the user.

It is possible to specify one or more of these “limit” constraints that follow.

-limitCount=### – Specifies the the user can only access the DRM protected object this number of times before access is no longer allowed

-limitStartDate=yyyymmdd – Specifies that the user will not be allowed to access the DRM protected object until on or after the specified date.

-limitEndDate=yyyymmdd – Specifies that the user will not be allowed to access the DRM protected object after the specified date

-limitDays=### – Specifies that the user will be allowed to access the DRM protected object for this number of days after initial receipt of the object. The user can either enter a number of days here, or they can enter any valid value defined for the “<interval>” element in the OMA DRM Rights Expression Language specification. For example, P2Y10M15DT10H30M20S represents a duration of 2 years, 10 months, 15 days, 10 hours, 30 minutes and 20 seconds.

-contentType=type/subtype – This optional parameter defines the MIME content type associated with the object (e.g., image/jpeg, audio/mp3). If this parameter is not specified, DRMCOMP will attempt to identify the content type automatically based upon the file extension. To determine the file extension to MIME type mapping, DRMCOMP will consult the NowSMS MMSCTYPE.INI file, if present, and will then search the MIME file extension to content type database in the Windows registry.

-contentID=cid – This optional parameter defines a “Content-ID:” header to be included to identify the object. If this parameter is not present, DRMCOMP will generate one automatically. Should the object expire due to DRM constraints, it is possible to send a separate delivery rights object to re-enable this object, but the separate delivery rights object needs to specify the “Content-ID” of the object. NowSMS will include its dynamically generated “Content-ID” in the separate delivery rights object that it creates, but you must save this dynamically generated value if you wish to be able to send a later separate delivery rights object to re-enable an expired object.

-key=16Text-or32Hex-Characters – This optional parameter defines an encryption key to be used to encrypt the protected object. If this parameter is not present, DRMCOMP will generate one randomly. Note that the separate delivery rights object must include this encryption key. NowSMS will include its dynamically generated encryption key in the separate delivery rights object that it creates, but you must save this dynamically generated value if you wish to be able to send a later separate delivery rights object to re-enable an expired object.

-out=outputFilename – This optional parameter specifies the output file name to contain the content with the DRM wrapper. If no filename is specified, DRMCOMP will default to the input objectFilename parameter, changing the file extension to “.dcf”.

-outRights=outputRightsFilename – This optional parameter specifies the output file name to contain the XML rights object for the protected content. If no filename is specified, DRMCOMP will default to the input objectFilename parameter, changing the file extension to “.dr”.

Separate delivery DRM objects have a MIME type of “application/vnd.oma.drm.content”.

The XML rights object may be sent via NowSMS using the Send XML Settings option in the web menu interface (see page 118). The XML rights object can also be sent programmatically using HTTP POST. For more information, please see Sending XML Settings Documents and Objects, beginning on page 227.