# DRM block diagram

This diagram and description must explain the content flow and security measures (physical or electronic) taken at each step in your process from how content is received from Paramount through the point at which playback occurs on the user’s terminal device.

## Content receiving

Received content from paramount here - assumed to be on some kind of secure file transfer system (SFTP?)

At this point, we access their system via a server based in the Bigscreen offices. (Physical separation).

From the server, we upload the files to Ooyala, our content partner.


## Content encoding

On Ooyala's servers, content is encoded into a streaming format (DASH)

https://help-ooyala.brightcove.com/video-platform/concepts/player_v3dev_playreadyprocess.html


## Content encryption

Protected with PlayReady, or Widevine, also on Ooyala, on playback.

Separation: electronic.


## Key management

Ooyala handles key management for us - we can log in to revoke keys.


## License creation

Ooyala handles license creation.


## Publication of content to the content delivery network

Ooyala handles the content delivery network.


## User registration and verification

User accounts created via Bigscreen account system - require a valid email adddress from the user to order content.

Send an email code to them to confirm their email..


## Content ordering process

A user with a valid bigscreen account begins a content order request.

All such requests require a user to have a valid access token.  Access tokens are short lived (15 minute expiry), generated with private key on our authorization server.

First check if the account can purchase the content (e.g. Geoblocked content can not be purchased)

Credit card details sent directly to stripe, which sends back purchase authorization to our server once funds cleared.

At this point, the user's account has an entitlement to the content.




## Content and license delivery

User elects to redeem their content entitlement by sending request to Bigscreen servers.

Bigscreen Servers authorises the request by checking if their entitlement is still active (entitlements may have different restrictions - e.g. number of uses, expiry, etc.).

If their entitlement is still active, Bigscreen servers start a playback request. Initially, the Bigscreen servers communicate directly with the content delivery platform to set up a "DRM session" for the specific account.

Specifically for Ooyala, once we've checked the user's entitlement on our servers, we request an "Ooyala player token". 

For PlayReady and Widevine, the content delivery platform creates a unique manifest url for specific piece of content they request, as well as a license acquisition URL - these get returned back to the Bigscreen's servers, which relays this info back to the user's device running the Bigscreen app.  In PlayReady's case, the license acquisition URL is part of the manifest.

The Bigscreen app then sends both the manifest and the license acquisition URL to the underlying DRM subsystem on the device.  The DRM subsystem then performs the license acquisition request directly with the content delivery servers.  For the duration of the session, the underlying DRM system handles all aspects of license acquisition requests.

If the user cancels their DRM session, they must start the process all over again.

Once the content request has been approved, playback begins.


## Playback

The underlying DRM system (WideVine, or PlayReady), sends callbacks to the Bigscreen application when a frame is ready to render.  The decrypted frame must be passed from the DRM subsystem to the GPU in such a way that the Bigscreen app can make use of the frame.

Bigscreen uses a protected graphics context to render the frame out to the screen.  The protected context means other processes can not access the GPU memory representing the frame.  To give an example, there is a screenshotting mechanism built into the Oculus Quest, that allows people to take screenshots of their activities that they can then send to friends.  If they try to do this with protected texture memory, the decrypted video frame will fail to render for them.


## Device output copy protection

Android: Protected GPU context.  HDCP.  USB protection

PC: Uses standard PlayReady protections.  Use protected textures that are only rendered to the VR headset.  HDCP protection via PlayReady license.


## Deletion of content from the system and the user’s device (when appropriate) upon expiration of the availability window.

Not applicable in either the case of Widevine or PlayReady - the decrypted content is not saved to the user's device.
S