[encrypted-media] "persistent-usage-record" sessions should not be handled in remove()

ddorwin has just created a new issue for 
https://github.com/w3c/encrypted-media:

== "persistent-usage-record" sessions should not be handled in 
remove() ==
For most ("happy case") `"persistent-usage-record"` sessions, it will 
be irrelevant whether usage data was persisted. (Conceptually, from 
the application's point of view, the record is only stored if it was 
not handled and cleared during the application’s lifetime.) Thus, 
applications may find it confusing to call `remove()` when they have 
not explicitly persisted something. Additionally, unlike 
`"persistent-license"` sessions, `remove()` never actually _removes_ 
anything for  `"persistent-usage-record"` sessions. (`update()` 
removes the relevant record for both types of sessions.)

Pulling `"persistent-usage-record"` out of the `remove()` algorithm 
will focus it on removing (destroying) persisted license(s) and 
keys(s). (Currently, this is applicable only to `"persistent-license"`
 sessions. In-memory keys are destroyed when a session is closed, so 
there is no reason to cover those in this method.) This would make 
resolving #155 much more straightforward.


<br/>Let’s take a look at what `remove()` currently does for 
`"persistent-usage-record"` sessions. Currently, it destroys the keys,
 persists the _record of key usage_, and generates a message.

As the discussion in Issue #171 and related PRs has helped highlight, 
there are multiple paths to closing sessions and the resulting actions
 of destroying ephemeral keys and storing the _record of key usage_ 
for `"persistent-usage-record"` sessions. This seems to make handling 
this session type in `remove()` redundant except for the queuing of a 
message. (The in-memory keys are destroyed and the _record of key 
usage_ is persisted in both cases.)

The session closing paths do not currently perform two operations:

1. Generating a release message when the session is closed.
1. Generating a message for a loaded session containing a persisted 
record of key usage.
 * This is for the "unhappy case" where the first message was not sent
 and/or ACK’d.
 * Note that in this case the keys are unnecessarily destroyed (there 
aren’t any) and the _record of key usage_ is re-stored.

Is there a reason (1) shouldn’t be performed by `close()` (or any 
other reason the session is closed)?

I see three ways that (2) could be handled. In order of preference:

* `close()` always generates a message for the _record of key usage_, 
which would have been loaded into the session by `load()`.
 - This seems the most consistent from an application point of view.
 - The loaded sessions is the same as an active session except there 
are no keys.
* `load()` generates the message, which is something the algorithm 
already allows.
 - We can add normative steps for this session type there
* `remove()` only generates messages in case (2).
 - This seems inconsistent and makes it hard to define the purpose of 
`remove()` (see #155).

Note: The loading of `"persistent-usage-record"` sessions and correct 
behavior of the `remove()` algorithm currently greatly depends on the 
definition of [Known 
Key](https://w3c.github.io/encrypted-media/#known-key) and 
understanding that a record of key usage was persisted. Even so, I’m 
not sure there is any language indicating the new session’s _record of
 key usage_ is actually populated with the stored data.


Please view or discuss this issue at 
https://github.com/w3c/encrypted-media/issues/180 using your GitHub 
account

Received on Thursday, 5 May 2016 23:58:55 UTC