Re: Request for feedback on EME Use Cases

Thanks. Yes, that text is problematic and should be fixed. Step 4.4.2 in
the update() algorithm has a similar problem.

The intent of the createSession() text was for the application (in the
offline case) to be able to request a persisted license. The license server
would have ultimate control of the policies in the returned license. The
important part is that the resulting session is persisted and can be loaded
and remove()'d.

There are a couple possible approaches: 1) The server returns a license
that does not persist keys OR 2) Add a separate 'keyreleaseproof'
sessionType. The latter is more explicit and makes fixing the two
problematic steps simpler, but it is more invasive to the algorithms (we'd
need "sessionType is 'persistent' or 'keyreleaseproof'" in multiple
algorithms) and prevents the use of key release with persisted licenses
(I'm not sure if that would even make sense, though).

David

On Thu, Jul 24, 2014 at 12:10 PM, Mark Watson <watsonm@netflix.com> wrote:

> In createSession(), step 7.3.3, we have: If sessionType is "temporary",
> the request is for a temporary non-persisted license. If sessionType is
> "persistent", the request is for a persistable license."
>
> ​and possible in other places. So this is where there is an explicit
> linkage made between persistent *sessions* and persistent *licenses*.​
>
> ...Mark
>
>
> On Thu, Jul 24, 2014 at 12:03 PM, David Dorwin <ddorwin@google.com> wrote:
>
>> I believe the text as of July 22nd was correct.
>>
>> "persistent" is a **session** type and does not specify the license
>> type. This was intentional. Is there text that is inconsistent with this?
>> "persistent" is used as part of the normative algorithms to define allowed
>> behavior. For example, session loading and removal is supported. (The
>> license specifies whether to persist the keys.)
>>
>> I have updated the wiki at
>> https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Limited_Concurrent_Streams_via_Key_Release
>> to describe the behavior. I'll continue this discussion in the loadSession
>> thread.
>>
>> David
>>
>>
>> On Tuesday, July 22, 2014, Mark Watson <watsonm@netflix.com> wrote:
>>
>>> Hi Joe,
>>>
>>> I don't think the description for secure proof of key release is
>>> correct, This should definitely not require a "persistent" license (the
>>> secure proof of key release and license persistence are orthogonal). Now I
>>> look at this, there is confusion in the specification between "persistent
>>> session" and "persistent license". Secure proof of key release needs the
>>> session to be recoverable later, in case the key release could not be
>>> delivered, but does not require the license to be persistent.
>>>
>>> ...Mark
>>>
>>>
>>> On Mon, Jul 14, 2014 at 1:59 PM, Joe Steele <steele@adobe.com> wrote:
>>>
>>>> I have completed my changes to the EME Use Cases wiki (
>>>> https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases).
>>>> I don’t think I can add much more to the general use cases without more
>>>> constructive feedback from the group.
>>>> Thanks to those of you who have looked and given feedback. For the rest
>>>> — please take a look.
>>>>
>>>> I think we specifically need feedback on:
>>>>
>>>> * Are there general use cases that we should be supporting that are not
>>>> there?
>>>> * Are any of these use cases unsupportable by your DRM?
>>>> * Is the level of detail sufficient?
>>>> * Any additional key delivery mechanisms?
>>>> * Are any of the current key delivery mechanisms objectionable?
>>>>
>>>> Joe Steele
>>>>
>>>> p.s. I apologize for not sending this sooner — it was sitting in my
>>>> Outbox during my vacation. :-(
>>>>
>>>
>>>
>