[Bug 26887] Allowing license servers and CDMs to control data persistence and secure release

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

--- Comment #12 from Mark Watson <watsonm@netflix.com> ---
(In reply to Mark Watson from comment #9)

> 
> It is easy to think of examples where multiple license are present for the
> same keys with different properties (e.g. limited viewing 'preview' licenses
> and normal ones), but I agree it is not obvious why you might want to store
> more than one kind across browser sessions.
> 

Actually, I take back that last bit. I may have both a 'preview' license with
various limitations and a 'real' license and they might both be persistable. I
might intend to have the app remove the preview one when it gets the real one,
but the browser might shut down before I have a chance and both may be present
in persistent store.

In a future session, if I want to retrieve one of these, the app should be in
control of which one. Using the 'real' license may have consequences (it may be
single-use, may start expiration timers etc.), so that must be an explicit
request from the app, not a choice of the CDM.

I think we can say that Key Ids (or equivalently initData) alone are not
sufficient for selecting which of several persisted data sets the application
wants to access.

I can see two options:
- we have an id that identifies the state created in a given session, and
allows it to be retrieved later (this is what sessionid is now, though we could
rename it to identify the persistent state, rather than the session, if you
like)
- some additional indication is needed together with the key ids or initData to
identify which bit of state being retrieved. This could be a 'type' field, but
that still assumes you will never multiple things of the same type which is not
the case for secure key release. To support various DRM's approaches and
capabilities this type would either need to be key-system specific or a
DOMString with the opportunity for people to register values with definitions.

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

Received on Thursday, 2 October 2014 14:52:01 UTC