The two models of DRM
April 25, 2012 Leave a comment
We often find that DRM is hard to understand for our customers who present content to end-users – it is something that is required by content owners but which provides minimal extra value to the content presenter. This means that there is an incentive to spend as little time and money as possible on DRM – ideally, it is seen as a switch you simply turn into the “on” position.
While that is a perfectly reasonable approach, it is also possible to make use of an appropriately flexible DRM platform to drive some of the entitlement-related business logic and thus save development effort. Whether a customer is interested in doing this determines which of two very different DRM models must be used in the solution.
Our SilverHD DRM platform was originally engineered to provide the maximum benefit to our customers, so we made the initial assumption that deep integration was desirable. In practice, this has only been true with around half of our customers. The current version of SilverHD DRM can cater equally well to both types of needs – separating them into a plug-and-play model and an integrated model.
This article describes the differences between the two DRM usage models and what sort of impact they have on solution development and integration. Our DRM platform uses the PlayReady technology but these models can also be roughly applied to other equivalent DRM technologies.
This is the simplest possible model, both conceptually and from an implementation viewpoint. Under this model, the only goal of the DRM technology is to prevent content decryption – this model ensures that even if you can view a movie, you cannot decrypt the video file to get at the raw video inside.
Such a model is trivially easy to implement – when properly executed, it requires absolutely no configuration of the client application and minimal one-time configuration on the server side. This makes it very attractive, since the implementation will be quite effortless.
The way this model works is that the licensing server will always grant a playback license whenever one is requested by any compatible player.
You can probably already see the downside: this model does not control who is authorized to view the content. This is the cost of almost free integration – everyone who has access to the video file is able to view it in a DRM-compatible media player because the server does not perform any authorization checks.
Does this type of “DRM” even protect anything? Yes and no. On one hand, the content can still not be decrypted, so it is not possible to “rip” it into the clear format that is used for distributing pirated content through the widespread channels – both tradition and mistrust of DRM will prevent such encrypted content from being spread by organized video copying groups. On the other hand, it enables anyone to view the content assuming they have both the video file and a player that supports DRM playback, seemingly defeating the idea behind content protection.
Perhaps surprisingly, this DRM model appears to be perfectly acceptable to content owners – we have not heard of any content presenter who has encountered problems in this area. At the present day, we fully support use of this model in our DRM platform and even recommend it if the customer does not need any of the extra features offered by the integrated model.
When contrasted with the plug-and-play model, the main difference in this scenario is that authorization checks are performed on every license request. The licensing server must explicitly be configured to approve of a request for a playback license or it will be rejected.
This means that it is possible for the content presenter’s backend systems to control who gets access to which pieces of content, and also to define very specific authorization rules. For example, a realistic example of one such rule from our DRM platform is “Allow user X to play video Y up to 5 times in April 2012, but only if less than 5 devices are associated with his user account and only if he is online when starting playback and only if IP-geolocation places him in Germany”. This is only a very basic example – much more flexible capabilities are already supported by our DRM playform.
If you think that this type of entitlement logic is often implemented in the backend code itself (e.g. in the video portal website), you are thinking along the right tracks! This is exactly where the benefit of the integrated DRM solution becomes apparent – instead of having to implement all the functionality to fulfill such entitlement logic, a product integrating with our DRM services can simply offload this responsibility and restrict itself to creating the appropriate licensing rules when the customer performes purchases.
The integrated model also ensures that unauthorized viewing of content is not possible. Even if a user gains access to the video file and is able to open it in a DRM-capable player, the licensing server will reject a request for a playback license because the content presenter’s backend systems have not created any rule that authorizers such a playback attempt. This ensures that only the intended user is able to view the content.
The integration secnario for this DRM model is naturally more involved than for the plug-and-play model. Primarily, it requires two pieces of functionality to be implemented:
- The player must identify itself to the licensing server by passing a secure token.
- The content presenter’s backend systems must configure appropriate licensing rules through web services exposed by the licensing server.
These steps are not overly difficult and we provide straightforward example code to all our customers – a major part of this being the source code for the Video Paradise example application -, but it can still be somewhat overwhelming if the customer expects DRM to just be a switch they can turn on. When legacy code is involved, such integration is complicated even further.
Which model to use
While the implementation of the integrated model is far from difficult, we have found that it is conceptually hard to understand for many customers, since they are used to implementing all of the entitlement logic in their “video portal” or even in the client application – offloading such functionality to a service seems like a foreign concept to many.
When we are dealing with a new solution, we generally recommend the integrated model to our customers, given the additional benefit to be gained from this. However, if the customer is retrofitting DRM into an existing solution, it may be easier to use the plug-and-play model. In the end, it comes down to an analysis of the specific requirements present in each solution.