This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26600 - Text is confused between persistent session vs persistent licenses
Summary: Text is confused between persistent session vs persistent licenses
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Mark Watson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-18 17:43 UTC by Mark Watson
Modified: 2014-09-15 20:07 UTC (History)
4 users (show)

See Also:


Attachments

Description Mark Watson 2014-08-18 17:43:57 UTC
The sessionType parameter to createSession indicates whether the requested session is persistent or not. This should be independent of whether the license is persistent or not, which is a decision for the license server.

Presently, attempting to install a persistent license in a non-persistent session generates an error - this seems unnecessary, since the license can still be used for playback in the current browsing session.

Text in the createSession procedures is confusing. I suggest the following:

1) createSession

CURRENT TEXT (createSession):

"3. Let request be a request (e.g. a license request) generated based on the init data, which is interpreteted per initDataType, and sessionType.

If sessionType is "temporary", the request is for a temporary non-persisted license. If sessionType is "persistent", the request is for a persistable session, possibly with a persistable license.

If sessionType is not "persistent", the CDM must not store a record of or data related to the session at any point.

Note: The license server may reject the requested type, but it should not issue a different type."

NEW TEXT (createSession):

"3. Let request be a request (e.g. a license request) generated based on the init data, which is interpreteted per initDataType, and sessionType.

If sessionType is "temporary", the request is for a temporary non-persisted session. If sessionType is "persistent", the request is for a persistable session.

If sessionType is not "persistent", the CDM must not store a record of or data related to the session at any point.

Note: The license server may return a license that is either persistent or non-persistent, independent of the session type. However, a persistent license obtained in a non-persistent session will be removed when the session is removed."

2) loadSession

CURRENT TEXT (loadSession):

"Process message, following the stipulation for the first matching condition from the following list:

If sessionType is "temporary" and message does not specify that session data, including any license, key(s), or similar session data it contains, should be stored
- Continue processing message, not storing any session data.
If sessionType is "persistent"
- Continue processing message, storing the license, key(s), or similar session data contained in message as permitted or instructed by the license.
Otherwise
- Reject promise with a new DOMException whose name is "InvalidAccessError"."

NEW TEXT (loadSession):

"Process message, following the stipulation for the first matching condition from the following list:

If sessionType is "temporary"
- Continue processing message, not storing any session data.
If sessionType is "persistent"
- Continue processing message, storing the license, key(s), or similar session data contained in message as permitted or instructed by the license.
Otherwise
- Reject promise with a new DOMException whose name is "InvalidAccessError"."

3) Exceptions

Remove the case "A persistent license was provided for a "temporary" session.".
Comment 1 David Dorwin 2014-08-19 01:40:16 UTC
(In reply to Mark Watson from comment #0)
> The sessionType parameter to createSession indicates whether the requested
> session is persistent or not. This should be independent of whether the
> license is persistent or not, which is a decision for the license server.
> 
> Presently, attempting to install a persistent license in a non-persistent
> session generates an error - this seems unnecessary, since the license can
> still be used for playback in the current browsing session.

The goal of the current text was to prevent a CDM from persisting data in the non-persistent session case. While some CDM implementations might be able to use the license for playback without persisting, it seemed unlikely, more bug-prone (lots of checks wherever the CDM might persist data), and unnecessary (the server can just issue the correct license type).

Specifically, there are existing DRM implementations that rely solely on the server/license to specify persistence. I think it is simpler to catch these issues up front and discourage issuing the wrong type of license than to expect the following to be accurately implemented by content providers, license servers, and clients:

> Note: The license server may return a license that is either persistent or
> non-persistent, independent of the session type. However, a persistent
> license obtained in a non-persistent session will be removed when the
> session is removed."

The proposed change in the second paragraph related to the request prevents the server from issuing the correct license.

Note: "the request is for a persistable session, possibly with a persistable license" was an attempt to improve on the previous text, which tied persistent sessions to persistent licenses. As previously discussed, we may need to be more explicit.

> 2) loadSession

I believe you mean update().

...
> NEW TEXT...
> Otherwise
> - Reject promise with a new DOMException whose name is "InvalidAccessError"."

Note: If we were to change the text, this case is not necessary since a session cannot be created with a different sessionType.
Comment 2 Mark Watson 2014-08-26 15:42:44 UTC
Ok, so let's keep the restriction that persistent licenses cannot be loaded into non-persistable sessions. The proposal is now:

1) createSession

CURRENT TEXT (createSession):

"3. Let request be a request (e.g. a license request) generated based on the init data, which is interpreteted per initDataType, and sessionType.

If sessionType is "temporary", the request is for a temporary non-persisted license. If sessionType is "persistent", the request is for a persistable session, possibly with a persistable license.

If sessionType is not "persistent", the CDM must not store a record of or data related to the session at any point.

Note: The license server may reject the requested type, but it should not issue a different type."

NEW TEXT (createSession):

"3. Let request be a request (e.g. a license request) generated based on the init data, which is interpreteted per initDataType, and sessionType.

If sessionType is "temporary", the request is for a temporary non-persisted session. If sessionType is "persistent", the request is for a persistable session.

If sessionType is not "persistent", the CDM must not store a record of or data related to the session at any point.

Note: The license server determines the type of license that is returned, either persistent or non-persistent. A persistent license cannot be added to a non-persistable session."


2, 3) No changes to update() or Exceptions
Comment 3 Joe Steele 2014-08-26 17:29:49 UTC
(In reply to Mark Watson from comment #2)
> Ok, so let's keep the restriction that persistent licenses cannot be loaded
> into non-persistable sessions. The proposal is now:
> 
> 1) createSession
> 
> CURRENT TEXT (createSession):
> 
> "3. Let request be a request (e.g. a license request) generated based on the
> init data, which is interpreteted per initDataType, and sessionType.
> 
> If sessionType is "temporary", the request is for a temporary non-persisted
> license. If sessionType is "persistent", the request is for a persistable
> session, possibly with a persistable license.
> 
> If sessionType is not "persistent", the CDM must not store a record of or
> data related to the session at any point.
> 
> Note: The license server may reject the requested type, but it should not
> issue a different type."
> 
> NEW TEXT (createSession):
> 
> "3. Let request be a request (e.g. a license request) generated based on the
> init data, which is interpreted per initDataType, and sessionType.
> 
> If sessionType is "temporary", the request is for a temporary non-persisted
> session. If sessionType is "persistent", the request is for a persistable
> session.
> 
> If sessionType is not "persistent", the CDM must not store a record of or
> data related to the session at any point.

Rather than say "data related to the session", state specifically what type of data related to the session. I believe your intent here is to control licenses containing content keys and license release vouchers. Let's limit the language that way.

> 
> Note: The license server determines the type of license that is returned,
> either persistent or non-persistent. A persistent license cannot be added to
> a non-persistable session."
> 
> 
> 2, 3) No changes to update() or Exceptions
Comment 4 David Dorwin 2014-08-27 22:50:59 UTC
(In reply to Mark Watson from comment #2)
> Ok, so let's keep the restriction that persistent licenses cannot be loaded
> into non-persistable sessions. The proposal is now:
> 
> 1) createSession

To simplify the discussion, the specific changes proposed in comment #2 are:
1) Paragraph 2: s/non-persisted license/non-persisted session/
2) Paragraph 2: Drop ", possibly with a persistable license."
3) Paragraph 4: Replace with "Note: The license server determines the type of license that is returned, either persistent or non-persistent. A persistent license cannot be added to a non-persistable session."

It seems #1 should also mention the license for clarity. As below, maybe this should be a non-normative sentence reinforcing what #3 says.

#2 is just acknowledging this possibility. Maybe that should be a separate non-normative sentence?

#3 seems fine.
Comment 5 David Dorwin 2014-09-15 20:07:17 UTC
https://dvcs.w3.org/hg/html-media/rev/1f6528d9bf9d implements the changes described in comment #4.