Re: Request for feedback on EME Use Cases

On Thu, Jul 24, 2014 at 12:27 PM, David Dorwin <ddorwin@google.com> wrote:

> 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).
>

​Yes, it would make sense. Imagine a "lending library" model where you can
"borrow" a fixed number of content items at a time. The server might want
proof that you have destroyed the license when a "borrowed" item is
"returned".

...Mark



>
> 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. :-(
>>>>>
>>>>
>>>>
>>
>