How to create & handle policies?

Question

Question from a customer (anonymized):
It is my understanding that the reference implementation comes with 4 sample policies:  Ad-pol, dto-pol, sub-pol, and vod-pol.  Without a policy file, both the f4fpackager and the Adobe Access SDK fail to generate DRM data.  As such, we are trying to determine what policy file should be used for the initial implementation and the impact if we choose to change the policy file later (i.e. would we need to repackage all assets again to include the updated policy file?).
In my mind, the first step is to understand what parameters can be declared in each policy file.  The second step is to determine what parameters are in scope for us (requirements).  And then finally, we need to implement the desired policy with the desired parameters (looks like we do this via the Policy Update List Manager?).  Would you agree with this approach?  Any recommendations overall – how other companies proceed?  Is the only documentation on this topic found in the Protecting Content -> Using the Adobe Access Reference Implementations document?

Answer 1

The entire content prep and license server configuration life cycle is documented in the "Protecting Content" document.  All of the information I describe below can be found (in even more detail) there.  http://www.adobe.com/support/adobeaccess/pdfs/server/AdobeAccess_4_ProtectingContent.pdf
The policies you’re speaking of our some sample/demo policies that our Reference Implementation License Server uses for our Business Rules sample.  It’s a mode you can set in the license server, where it’ll serve out licenses abiding by the restrictions in one of those Ad-Supported, Download-to-Own, Subscription, or Video-On-Demand sample policies you’re looking at.  Page 22 of the Ref Impl usage guide will demonstrate how to package content that'll demonstrate this Business Logic:  http://www.adobe.com/support/adobeaccess/pdfs/server/AdobeAccess_4_RefImpl.pdf
A policy, once created, can be used in any situation, so you’re free to use those sample policies (if they suit you), or build your own policies using our Java Adobe Policy Manager, or by directly using our Adobe Access SDK.  I’ll go into details on how to use either approach below.
[ What is a policy? ]
A name:value set of license restrictions.  A description of all the license restrictions that can be defined in a policy can be found in the "Usage Rules" section here: http://www.adobe.com/support/adobeaccess/pdfs/server/AdobeAccess_4_ProtectingContent.pdf
[ How is a policy used during packaging (encrypting)? ]
The packager takes the policy as an opaque blob of data to insert into the DRM Metadata during packaging.  When the client requests a licnese, it'll send the entire DRM Metadata blob to the License Server (without parsing it).  The DRM Metadata contains the following information:
- License Server URL
- Policy
- Content Encryption Key (encrypted using the License Server's Public Key)
[ How is a policy used during Adobe Access License Server issuance? ]
A policy is a suggested "blueprint" that the Adobe Access license server may choose to use in order to determine what constraints/restrictions to include into the license it vends to the client.  The key words here are "suggested" and "blueprint".  "Suggested" infers that the server can choose to only listen to some (or all) of the restrictions named in the policy.  The license server can even choose to override any/all of the policy fields.  To the extreme case, the license server may choose to completely ignore the policy sent up in the metadata and use it's own policy (by creating one from scratch, or using the built-in PolicyUpdateList functionality).
Once all of the policy properties are decided, it is used by the License Server to generate a license to send down to the client.