Integration
License acquisition flow
License acquisition flow begins on end-user device. When player encounters encrypted content, it generates challenge and sends request for DRM license. Request doesn't go directly to the license server, but to the license proxy, which typically is part of OTT portal. The task of license proxy is to validate user and check business rules of content playback. If proxy grands access for content playback, it finds DRM key of given content (i.e. finds it in the database) and passes generated player request containing challenge, to the license server.
Basing on the challenge from player and DRM content key from proxy, license server generates license and returns it to the proxy. Proxy then passes unmodified message with generated license back to the player. License acquisition flow is illustrated on the diagram below. Player, license proxy and server are represented by the Device, Portal and License Server objects respectively. It is assumed that business rules are checked based on user identifier (userId) and content identifier (productId).

DRM Proxy
From the DRM point of view, the most important module is DRM Proxy which role is as follows:
- storing keys (cipher information) - CENC, HLS key, HLS IV, etc.,
- validating business rules during license acquisition,
- storing license parameters associated with video (aka Security Level, hdcp settings or other),
- proxy to the proper License Server (setting required parameters for particular video in license request before it is sent to the License Server),
- having authentication & authorization layer if needed.
TIP
The generated Content Key should be stored in DRM Proxy (or Portal, i.e. its secure database), and the Proxy should be capable of mapping a particular video with its key, for example by video ID.
During the start of playback, the video player tries to acquire a license - this is done by calling the endpoint of DRM Proxy. The URL to DRM Proxy in most cases is set during player initialization.
The Proxy performs some logic (described above) and then transfers the license challenge (which the video player has sent in the previous step) with additional parameters (the set of available parameters including the most important Content Key are described in API docs of particular License Servers in the following chapters) to the License Server.
Proxy implementation tips
Please take into account during Proxy implementation:
- authorization & authentication. The approach depends on architecture of proxy. In case of microservice architecture probably you have to use tokens in query string,
- digital content identification - you have to decide how to identify the particular video. The common solution is to add ID in query string of URL to license server (which is set during player initialization),
- one endpoint vs. dedicated enpoints per DRM System. The common solution is to prepare dedicated endpoint for each DRM System. First solution is possible as well, but then you have to add a query string parameter which will distinguish DRM Systems,
- mapping keys & key identification.