License Request Policies
Constructing policy objects, common policy combinations.
What this module covers
Day 1 introduced policy fields conceptually. This module is about how those fields are configured through the SDK at request time. Most of the specific API surface (struct names, field names, builder helpers) is NDA material; the public-facing concepts and patterns below are what you can study before class.
The five policy levers
Every licence policy you will build is some combination of these five:
Common policy combinations
| Use case | Time | Persistence | Renewal | HDCP | Tracks |
|---|---|---|---|---|---|
| VOD streaming, HD | session-length license | no | rare | 1.4 | SD+HD |
| Live channel | short, rotating | no | yes (frequent) | 1.4+ | all |
| 48h rental | 30d license / 48h playback | yes | no | 1.4 | SD+HD |
| EST (own-it) | long license | yes | yes | 1.4 | SD+HD |
| UHD/HDR premium | session | no | no | 2.2+ | UHD-only |
Decision tree
When the licence-request handler receives a request:
1. authenticate user
2. lookup entitlement(content_id, user)
3. detect device tier (from request properties / CDM identity)
|
├── L1 + HDCP 2.2+? → eligible for UHD policy
├── L1 + HDCP 1.4? → HD policy max
├── L3? → SD policy max
└── unknown? → safest minimum
4. build policy object accordingly
5. call sdk.process_license(request, policy, keys_for_allowed_KIDs)
Why per-KID tracks matter here
The licence server doesn't tell the device "you may only play SD". It simply omits the HD and UHD content keys from the licence. The player negotiates manifest tracks based on which keys arrived. This is more robust than any flag-based approach: a compromised player can't unlock keys it doesn't have.
When asked "how does Widevine prevent an L3 device from playing UHD?", the answer is: per-resolution KIDs. The licence server gives the L3 device only the SD KID's key.