What is DRM Metadata (.drmmeta)?

[ Background ]

During the encryption/packaging of Adobe Access DRM content, DRM metadata is created and associated with the content.  This metadata is needed by the client to acquire a license, and the server to generate a license. 

For progressive-download content (FLV/F4V/etc...), this metadata is embedded into the content header itself, and can also be created as a side-loaded file (such as .drmmeta or .metadata) which can be fed into the Adobe Access APIs to perform pre-license-acquisition activites, such as Authentication, joining a Device Domain, or pre-acquiring a license ahead of time.  For streamed content (HDS/HLS/etc...), this metadata is typically embedded into the content manifest, or referenced in the content manifest.

Adobe does not publish the Adobe Access DRM metadata spec, as this is likely to change over time, among other reasons.  However, this article will attempt to loosely cover the essentials of the DRM metadata.

Adobe Access DRM Metadata is an encrypted opaque blob (to client devices) that can only be fully parsed & decrypted by an Adobe Access license server.

In the metadata is all the information the client needs to perform a license acquisition, such as:

• The URL to the Adobe Access license server that can generate a license for this content
• Transport encryption key, which is used to encrypt all data sent to the Adobe Access license server
• Adobe Access DRM policies which were associated with the content during Adobe Access packaging time
• The date/time of when the content was packaged (which is used to determine license/caching durations that are based from the packaging time)

During a license acquisition, the metadata in its entirety is sent to the Adobe Access license server.  The metadata, in addition to what has been configured on the license server, has all of the information needed to generate a license response, such as:

• The transport decryption key, which is used to decrypt the message sent by the client device
• The license server decryption key, which is used to decrypt the Content Encryption Key from the metadata
• The Adobe Access DRM policies which were associated to the content during Adobe Access encryption/packaging
• The client device's encryption key, which the server can use to secure the license

[ Side note for Adobe Access PHDS/PHLS  (Protected-HDS/HLS Streaming) ]

In the PHDS/PHLS scenario where there is no license server, the content license itself is embedded into the DRM metadata.  During packaging time, it is often the case where the license is valid for a certain amount of time after the content has been packaged (e.g. License End Date == 24hrs after packaging).  The "packaging time" is embedded into the DRM metadata.

In the case that Adobe Media Server (or FMS) is streaming 24/7 (e.g. "Linear") content, it is vital that the DRM Metadata is periodically "refreshed" so that the license end date progresses over time.  Otherwise, if a stale DRM metadata is used, it is possible that a client device will have a license with a lapsed "License End Date", even if the client device just recently began watching the stream.  AMS has a "drmUpdateInterval" property to ensure that a new metadata is regularly refreshed; ensuring that the metadata is propogated across the CDN caches is beyond the scope of Adobe Access.

cheers,

/Eric.