[Bug 17673] Define Initialization Data for implementations that choose to support the ISO Base Media File Format

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

--- Comment #59 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #58)
> (In reply to Jerry Smith from comment #57)
> > Changes made in https://dvcs.w3.org/hg/html-media/rev/5e4403d01787.
> 
> Comments on the changes:
> 
> 1) "Common Encryption files may contain one or more protection system
> specific header ('pssh') boxes, each for a different SystemID."
>   - This makes it sound like a PSSH box can only appear once per SystemID.
>   - I believe you mean that they are unique within a series at each location
> where a PSSH is necessary.
>   - For interoperability and consistency, we may want to note that a PSSH
> box for all SystemIDs should be present wherever their are any PSSH boxes.
> 
> 2) The second paragraph of section 3 seems to specifically address embedded
> keys. Is that right? Is this the *only* use of PSSH boxes in a 'moof'?
> Embedded keys are not currently covered by the main EME spec text.

This is correct, but neither are they excluded by the current text. Given that
there is a desire to support existing DRMs, this should be supported as it is
required for some DRMs. See my examples below.

> 2a) "Each ‘moof’/’pssh’ must protect the contained keys with a SystemID
> specific method." How can a 'moof' protect the keys?

The DRM referenced via the SystemID is responsible for protecting the keys. The
content keys may be protected in various ways. For example - in the Access case
the content keys may be encrypted using a domain key, a "root" license keys, a
license server key or a common player key. The mechanism used is chosen at
publishing time based on scalability and robustness requirements.  

> 2b) The last sentence explains why one might use sample groups. I believe
> this is the only such text in the spec and should be removed. (This would be
> valuable in a "Using EME with Common Encryption" primer, but I don't think
> it belongs in the spec/registry.
> 
> 3) The third paragraph seems orthogonal to EME and like a DASH-specific
> usage of a generic EME capability (see also below). I think it should be
> removed. (Is it really CENC that specifies this or is it DASH?)
> 
> 4) "The application may parse out 'pssh' boxes which do not correspond to
> the selected key system, and may not use the InitData from the file at all
> and instead use initData from another source (e.g. the XML element described
> above).
>   - The first part is fine, but I'm not sure we need to specify it."
>   - The second part is (or should be) covered by the spec and applies to all
> init data types. I don't think we need to specify this here.
>   - As above, I think we should remove the XML reference.
> 
> 5) Is there a formal reference for CENC 2nd edition? Is it just "ISO/IEC DIS
> 23001-7 2nd Edition" for now?

I would be interested in this as well. And if not -- do we need a different way
to refer to proposed amendments to the spec? Or should we assume all of those
are out of scope?
> 
> 6) nit: s/boxes(s)/box(es)/

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

Received on Tuesday, 10 June 2014 09:47:49 UTC