[Bug 25218] Allow license management directly via MediaKeySession

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

--- Comment #16 from Joe Steele <steele@adobe.com> ---
(In reply to Mark Watson from comment #15)
> (In reply to Joe Steele from comment #14)
> > (In reply to Mark Watson from comment #12)
> > > (In reply to David Dorwin from comment #11)
> > > > (In reply to Mark Watson from comment #10)
<snip>
> > This is the key exchange I do not want to repeat. This key exchange should
> > be subject to the same-origin constraints all other CDM communication is. To
> > me this implies it must go through the keyrequest/update() mechanism. Or we
> > must introduce an alternate mechanism which looks essentially the same, but
> > is specific to this purpose.
> 
> I certainly agree with not repeating such bootstrap functions unnecessarily.
> And I agree it could use the keyrequest / update mechanism to complete it.
> What is it in the existing specification that means you have to repeat this
> part ?

One of my concerns is that there seems to be some disagreement about what is
considered in the session. The spec
(https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-release)
seems clear that the CDM has flexibility in deciding what is considered part of
the session and what is not. Your comment 10 make sense to me, but comment 11
indicates that David disagrees. If this is not resolved, it could lead to
problems. 

My second concern is that even if we get agreement that the CDM can make the
call on what is considered in the session and thus affected by loadSession and
release(), the session is the wrong level of granularity. 

The session contents are CDM-specific by design. The KID is a generic
well-known entity specified by the media format. It seems clear to me that
loading and releasing keys should rely on the generic well-known entity rather
than the more nebulous CDM-specific one. This would avoid the whole question of
what is in the session.

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

Received on Wednesday, 30 April 2014 21:00:47 UTC