[Bug 27093] Support for proprietary/system-specific formats in initData should be discouraged/deprecated

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093

--- Comment #11 from Joe Steele <steele@adobe.com> ---
I believe these are the use cases that David and I discussed.

Case #1 -- the content key is in the PSSH and is encrypted for a license key
that the client can acquire. The PSSH may or may not also contain some
identifier to let the key server know which key needs to be issued. I believe
this does require app-visible consequences.

Case #2 -- the content key is in the PSSH and is encrypted for a key that is
baked into the client (i.e. the client does not need to go to a license server
to retrieve it). This could be done as an optimization to avoid the key
acquisition cost for content whose policy allows this. The only required
app-visible consequence of this is that a key request will not happen in this
case. The key will simply be available.

Case #3 -- the content key is in the PSSH and is encrypted with a key known to
the license server. This allows the license server to be independent of the key
management system used during packaging. The only potential app-visible
consequence of this is that if the key server the application is using does not
have the appropriate key, the embedded content key cannot be used.

I can see two ways forward that would not negatively impact interop.

1. We could add support for these models as optional additional components of
the Common PSSH. Some clients could consume the optional components and those
that could not would still have the required base data i.e. the key id. 

2. We could continue to support streams with multiple PSSH boxes, one in the
Common PSSH format and others in proprietary formats. Publishers which choose
to use multiple PSSH boxes can leverage any optimization provided by the
proprietary formats, and those who do not will still have the Common PSSH to
fall back on. 

In either case I think we should make the text changes I proposed in comment 2
and comment 3.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 12 January 2015 21:25:02 UTC