[Bug 25200] Add optional "licenseType" parameter to createSession()

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

--- Comment #4 from Shinya Maruyama <Shinya.Maruyama@jp.sony.com> ---
Re: #1
Actually we had envisioned #1 is potential usecases, for example, to support
UltraViolet full interactivity. Full interactivity enables packaged web
application (i.e. web app in DMP) - whose origin is typically not the same as
the origin where EME is performed to acquire license(s) - to playback the
content with interactivity. Typically license is persisted in DMP but I thought
there was no reason to preclude license being persisted in CDM instead of DMP.
Now I understand license persisted in CDM should not be shared across origin
for the privacy reasons. Probably I should focus on the way to persist license
in app storage (e.g. DMP) for the UV usecase unless there is a solution to
avoid such privacy problem.

Re: #2
I suppose your proposal (bug 25218) is conceptually similar to mine except that
keyId is used to identify key(s)/license(s) whereas initData is used for mine.
I do not have and could not imagine any usecases to remove/load/query key(s) or
license(s) by keyId because initData including pssh which can contain all the
KIDs in conformance with cenc second edition is enough to identify necessary
key(s). Meaning even when multiple keys/licenses are associated with a movie
(e.g. key per track), it's sufficient to treat a bunch of them all together.
If you have concrete usecases where keyId-granular handling is useful, it would
be very helpful to understand the advantage of your proposal and get convinced.
However, even if we have a valid usecase for using keyId, I prefer to keep such
feature as optional; e.g.
 - removeKey(optional DOMString keyID);
 - if keyID is omitted, all the key(s) associated with initData is removed
Because it burdens application to extract keyID from initData(pssh), MPD or
directly media files always even though initData is good enough for the key(s)
identification.

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

Received on Friday, 4 April 2014 07:55:31 UTC