Bug 19809 - Specify which portion of addKey() algorithm to run when updating license for a key
Specify which portion of addKey() algorithm to run when updating license for ...
Status: RESOLVED FIXED
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions
unspecified
All All
: P3 normal
: ---
Assigned To: David Dorwin
HTML WG Bugzilla archive list
:
Depends on: 20688 21854
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-01 00:31 UTC by David Dorwin
Modified: 2013-11-05 23:53 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Dorwin 2012-11-01 00:31:13 UTC
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-addkey describes the behavior "For each individual key in |key|". This would seem to mean any time |key| includes a key, these operations should be performed, even if the CDM already had a specific key.

Questions:
#1 If a new license (i.e. renewal, update, policy change) is received with the same |key|, should those operations be performed?
#2 If so, should we say "For each individual key _represented_ in |key|" since these subsequent licenses may not actually specify the key itself again?

The most debatable issue might be whether to fire keyadded in this case. It probably makes sense to always "attempt to resume playback" because it's possible that the new license will allow previously stalled playback to resume.
Comment 1 David Dorwin 2013-04-23 20:49:03 UTC
I don't think we can make any changes here until we resolve bug 20688.
Comment 2 David Dorwin 2013-04-27 00:54:11 UTC
Bug 21854 replaces bug 20688.
Comment 3 Adrian Bateman [MSFT] 2013-10-01 15:38:29 UTC
Discussed on telcon 2013-10-01. David will evaluate to see if any new action is need once bug 21854 is resolved.
Comment 4 David Dorwin 2013-10-01 15:39:11 UTC
keyadded will be removed per bug 21854. I'll reevaluate after keyadded is removed to see where we can simplify. Resuming playback seems to be the remaining item we want to include.
Comment 5 David Dorwin 2013-10-29 00:40:16 UTC
(In reply to David Dorwin from comment #0)
> #2 If so, should we say "For each individual key _represented_ in |key|"
> since these subsequent licenses may not actually specify the key itself
> again?
Other information related to keys may be stored, though not explicitly listed in the steps. The storage algorithm specifically relates to keys, so I think it's fine as is.


More importantly, the key storage algorithm describes deleting and replacing keys but does not specify the context - that is, whether it is within the session or the MediaKeys. This text was originally written in the context of HTMLMediaElement, so it is referring to MediaKeys. However, deletion is probably not the right action when sessions overlap.

I'm leaning towards deleting the key storage algorithm and noting that it is CDM specific. I think overlapping keys should not be deleted such that when one session is closed, an overlapped key in another session is available.


(In reply to David Dorwin from comment #0)
> It
> probably makes sense to always "attempt to resume playback" because it's
> possible that the new license will allow previously stalled playback to
> resume.
There may be cases where no new key is stored (as in the current algorithm) but playback becomes possible. Given this and the possible removal of the key storage algorithm, we may want to remove "did store key" and always try to resume playback when waiting for a key.


Finally, |key| is a misleading and inappropriate name for update()'s parameter. We should rename it. I can file a separate bug, but this is a good context to be thinking about that as well.
Comment 6 David Dorwin 2013-11-05 23:53:20 UTC
(In reply to David Dorwin from comment #5)
...
> I'm leaning towards deleting the key storage algorithm and noting that it is
> CDM specific. I think overlapping keys should not be deleted such that when
> one session is closed, an overlapped key in another session is available.
Changeset https://dvcs.w3.org/hg/html-media/rev/6b1b0aa1415c removes the key storage algorithm and adds non-normative text about CDM behavior related to keys and sessions.

...
> There may be cases where no new key is stored (as in the current algorithm)
> but playback becomes possible. Given this and the possible removal of the
> key storage algorithm, we may want to remove "did store key" and always try
> to resume playback when waiting for a key.
Changeset https://dvcs.w3.org/hg/html-media/rev/6b1b0aa1415c removes "did store key" and changes the algorithm to always attempt to resume playback when waiting for a key unless an error occurred.

> Finally, |key| is a misleading and inappropriate name for update()'s
> parameter. We should rename it. I can file a separate bug, but this is a
> good context to be thinking about that as well.

Changeset https://dvcs.w3.org/hg/html-media/rev/cf1786f8f616 renames |key| to |response|. We can iterate on the name, but this at least removes the confusion.