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 25537 - Expose expiration information to the application
Summary: Expose expiration information to the application
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2014-05-02 19:59 UTC by David Dorwin
Modified: 2014-05-09 22:19 UTC (History)
3 users (show)

See Also:


Description David Dorwin 2014-05-02 19:59:32 UTC
License expiration is a fairly common concept. Applications could use this information to manage renewals or provide UI to the user. The CDM knows the exact time, which can be based on complex logic. While applications could store this information or retrieve it from the server in most cases, this is not always the case (i.e. offline) and it would be better to expose the exact value the CDM is using.

Exposing this information might even address the expired case for MediaKeyError in bug 21798.

This could be as simple as adding the following to MediaKeySession:
  readonly attribute Date expires;

For sessions where an expiration time does not apply, the value can be *undefined*. See for additional details on the Date type.

Since the CDM is the source of this information, it would need to update the MediaKeySession object if/when it changes. The initial value should be set before createSession()/loadSession() resolve their promise.
Comment 1 Joe Steele 2014-05-05 23:07:48 UTC
I think this is blocked on the discussion about whether session == license.

However I agree that this could be useful. I assume this would be based on the local clock?
Comment 2 David Dorwin 2014-05-06 18:50:04 UTC
(In reply to Joe Steele from comment #1)
> I think this is blocked on the discussion about whether session == license.

I don't think this is blocked. If there were multiple licenses or other expirable items in the session, the CDM could provide an appropriate value based on the combination ("complex logic" in the original proposal). For example, return the soonest expiration time of all licenses

> However I agree that this could be useful. I assume this would be based on
> the local clock?

The time would be UTC, but the current UTC time would need to be based on a local clock.
Comment 3 Joe Steele 2014-05-06 21:08:39 UTC
For the createSession() case, the value will start at *undefined* most of the time and will only resolve to a value after one or more key exchanges. 

Will the application be expected to poll this value for a change from undefined to a valid date? Or should we add an event to signal this transition, similar to keychanged?
Comment 4 David Dorwin 2014-05-06 21:21:32 UTC
I thought about adding an event, but the use cases seem limited and I didn't want to add more complexity until we're sure we need it.

It's not something that is expected to change frequently. For the update() scenario, the promise should be resolved after any related updates are applied. (For the moments) when applications care about other scenarios, it seems polling should work and precise updates are not necessary (as they might be for a change in usable keys)
Comment 5 Joe Steele 2014-05-06 21:44:29 UTC
That's acceptable. I am thinking an application can always poll this on the *keychanged* event in any case, since that is when you will typically find out about expiration. 

I am ok with moving ahead on this feature. I am assuming any multi-license or non-content license gotchas can be resolved with implementation experience in this case. We may end up with some ambiguity in what this date means, but the negative impact if any should be small.
Comment 6 David Dorwin 2014-05-09 22:19:55 UTC
Implemented in