License Acquisition

To play protected content, a valid license for the content must be available. If there is no valid license for the content, the license must be acquired. During license acquisition, a client acquires its license from a License Server or from a Proxy Server. The license acquisition client is a media player on a mobile device, such as a phone or tablet, or on a personal computer. Clients for license acquisition connect directly to a License Server and request licenses for content they have acquired.

In the context of license acquisition, the License Server and the Packaging Server are considered to be DRM Servers. Portable devices and personal computers capable of license acquisition are considered to be clients.

Server and Client interactions for license acquisition

This section examines the component interactions for license acquisition.

On the server side, PlayReady Server SDK provides functionality for:

• License generation/issuance
  

The client on the consumer's portable device or personal computer provides functionality for:

• License acquisition
  
• Usage rules enforcement
  
• Content decryption
  

Domain, Metering, Secure Stop, and Secure Delete support is also included with PlayReady Server SDK.

Proactive, Reactive license acquisition

There are two modes for license acquisition:

• Proactive license acquisition — The client application explicitly initiates a license request before playback begins. This is typically a scenario where the system is programmed such that the application has browsed content, and would take the time to "proactively" acquire the license before any playback session is started. After the license is received, playback can start at any time. The application could start playback immediately, or there are cases where the license would be acquired days before the content is actually played, typically in an offline playback scenario.
• Reactive license acquisition — The client application doesn't explicitly acquire a license before content is played back. After playback is initiated, the PlayReady media player looks for an existing PlayReady license that can decrypt this content. If it does not find any usable license, it automatically uses the associated license acquirer object to acquire the license before resuming the playback.

The following figure gives an architectural overview of content protection and license acquisition.

License acquisition follows these steps, as illustrated in the figure:

1. The content provider uses a license key seed and key identifier to generate a key.

2. The content provider places the key identifier and the URL of the License Server in the content header and then protects the file by encrypting it with the key.

3. The content provider delivers the protected file to the user.

4. The user's media player queries the DRM component of the user's device to determine whether the protected file can be played.

5. The DRM component searches the License Store on the user's device for a valid license to play the file.

6. If the DRM component fails to find the necessary license, it requests a license from the License Server. The license challenge used to request the license contains the content header and information about the user's device.

7. The License Server uses the shared license key seed and the key identifier to generate the same content key that was generated by the content provider in step 1. The License Server then encrypts the key.

8. The License Server creates a license, adds the encrypted content key to the license, and signs the license by using the private signing key.

9. The License Server delivers the signed license to the user's device.

10. The DRM component on the user's device verifies the signature and expiration date of the certificate, and places the license in the License Store.

11. The DRM component decrypts packets of the requested content and sends them to the player.

At this point, the player will have the content in a usable form. Any policy enabled by the license can be used. For example, if the license enables "play," the license acquisition client can play the content.

The following figure shows the basic steps to proactively acquire a license.

The following figure shows the basic steps to reactively acquire a license.

After a client retrieves a protected file, that client needs to acquire a license before it can perform actions that use that content. Licenses store the information necessary to access the associated content and store the rules by which that content can be accessed. Users must acquire their own licenses to play protected content, even if the protected content was copied from someone who already had a license for it. Licenses contain the encryption key to decrypt the corresponding content or, in the case of chained licenses, contain an intermediary key. Licenses also contain rights and other properties that specify the use of the content. For example, the license determines the number of times a protected file can be played, and whether the license ever expires. These properties are configured in the license separately from the protected file.

Each license contains the following information:

• The content encryption key.
• The rights of the license.
• The right restrictions and right modifiers, also known as the conditions of the license.

Before a client can decrypt the content associated with a license, it must retrieve the policy from the license. The content protection information within the license is encrypted using a client's public key or a client's domain's public key encryption information. The license is considered "bound" to the client or domain that has the private key for decrypting the content protection information.

Clients acquire licenses either directly from License Servers or through a Proxy Server.

Transport for license acquisition

PlayReady license acquisitions all require a transaction between the client and the Server:

1. A challenge generated by the client and sent to the Server.
2. A response generated by the Server and sent to the client.

Transactions typically occur on the Internet, through HTTP or HTTPS, or on a closed network. The protocol used is based on Simple Object Access Protocol (SOAP) and can be customized. Transactions can also be implemented asynchronously, for example with a client posting the challenge at one location, and a Server processing this challenge, generating a response, and posting that response in some other location.