Non-Direct License Acquisition - APP/MDRMM

This page describes the request that a client application or STB makes to the MDRMM and the response that it receives for licence acquisition in non-direct mode.

API CALL

The client app/STB makes a/client/getEntitlements request to the MDRMM.

Variant cases

Hardware PRM vs software PRM

Hardware PRM requests (that is, requests from STBs) have different mandatory fields within the deviceSpecification part of the request.

For software PRM:

• Only opaqueData is mandatory.

For hardware DRM:

• opaqueData is not mandatory.

• In drmSpecification, name should be SWPRM.

• You must use either casn or nuid.

• If you use nuid, you must also use cts.

• In deviceSpecification, the deviceUniqueIdentifier is usually the CASN (but it could be different if agreed between the (third-party) portal and the cliet app).

• In drmSpecification, name should be HWPRM.

Multiple portals

If you are using multiple portals, you must include a com.nagra.portalkey in applicationData in the request so that the MDRMM knows which portal to forward the request to. applicationData should look like this:

"applicationData" : {"com.nagra.portalkey": "<portal_key>"}

Response

A successful response will include at least the following:

• "status ": 0

• "prmStatus" : "OK"

• "authStatus" : "GRANTED"

• An entitlements array containing at least one object with values for dcm, dmm, and signaling.

• If a device object is included, it will always contain at least:

  • secretId
  • A status object, containing:
    • compromisedOS
    • earlyDevice
    • `lateDevice'

Variant cases

STB vs open device

For an open device, the response always includes a device object. For an STB, it does not.