- From: Joe Steele <steele@adobe.com>
- Date: Wed, 11 Jun 2014 07:33:02 +0000
- To: David Dorwin <ddorwin@google.com>, Niels Thorwirth <nthorwirth@verimatrix.com>
- CC: "Maruyama, Shinya" <Shinya.Maruyama@jp.sony.com>, Adrian Bateman <adrianba@microsoft.com>, "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <1402471978690.79274@adobe.com>
I will disagree _slightly_ here. If the license is completely encrypted using keys only known to the CDM, then although this information is present it is not accessible to the application without exposing those keys. In addition, start time may not easily be inferable if licenses are being issued for some time in the future, for example for a linear live stream when a change in program is coming and you want to avoid a license storm. However _generally_ the application will be able to infer this information based on the manifest, the license server and knowledge about the licenses it issues. Joe ________________________________ From: David Dorwin <ddorwin@google.com> Sent: Monday, June 2, 2014 5:11 PM To: Niels Thorwirth Cc: Joe Steele; Maruyama, Shinya; Adrian Bateman; public-html-media@w3.org Subject: Re: [EME] To what extent should EME support usage rules? I considered exposing other times before filing https://www.w3.org/Bugs/Public/show_bug.cgi?id=25537. I settled on exposing the minimum required information that the application could only obtain from the user agent/CDM. (Start time and various other timers are known when the license is issued and don't change. However, the expiration time can change in some cases. and, in the offline case, it's not possible to ask the server for an updated expiration time when offline.) Note that the decision above does not address whether EME should support a common set of usage rules. I think that would help with interoperability and working through use cases. David On Tue, May 20, 2014 at 3:03 PM, Niels Thorwirth <nthorwirth@verimatrix.com<mailto:nthorwirth@verimatrix.com>> wrote: Joe, I agree that some visibility in the status will be useful. I wonder if a generic status string could help to reduce complexity and the amount to be specified initially. It would still be helpful for debugging and can be filled by CDM implementers as they like (though a growing list of recommendations would be helpful). This will of course limit the automated evaluation and interoperable reaction. Niels From: Joe Steele [mailto:steele@adobe.com<mailto:steele@adobe.com>] Sent: Tuesday, May 20, 2014 9:55 AM To: Maruyama, Shinya; David Dorwin; Adrian Bateman; Niels Thorwirth Cc: public-html-media@w3.org<mailto:public-html-media@w3.org> Subject: Re: [EME] To what extent should EME support usage rules? * PGP Signed by an unknown key Adobe could support a start time for some keys. However not all keys would have a start time until they had been started. The name “usableKeyIds<https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-usablekeyids>” would need to change of course. Maybe “availableKeyIds”? In this case the “status” of a key would start to look more like X.509 certificate status: (http://en.wikipedia.org/wiki/Certification_path_validation_algorithm) * valid * valid but usage limited (aka downscaling) * invalid because validity period has not started * invalid because validity period has expired * invalid because revoked * invalid for DRM-specific reason * unknown (can’t tell without trying to use it) Not sure how many of these are common. However I think applications could use this for testing and debugging so it could be useful especially for interop testing. I am in favor of more information, but this could complicate things quite a bit for CDM implementors. I would like to hear feedback from some of them. David, Adrian, Niels — any comments on this? Joe On May 14, 2014, at 7:40 PM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com<mailto:Shinya.Maruyama@jp.sony.com>> wrote: I agree with your point. >From your viewpoint, I wonder if start time would be useful for application to know a key is not available yet because start time is future time. You opinion? - Shinya From: Joe Steele [mailto:steele@adobe.com] Sent: Thursday, May 15, 2014 6:11 AM To: Maruyama, Shinya Cc: public-html-media@w3.org<mailto:public-html-media@w3.org> Subject: Re: [EME] To what extent should EME support usage rules? There are a couple of additional usage rules that have been mentioned. There has been discussion of usage rules around output protection (e.g. HDCP). This used to be represented via an error code, but that has gone away at this point. There has also been discussion around output downscaling in bug 25092. My opinion is that the application only needs to know about things that might be impacting playback. For example: * When a key is no longer available because it has expired. What type of expiration occurred and the exact times makes less sense to me. * When playback has stopped because output protection has been violated. Again the type of OP failure makes less sense to me. * When playback has degraded for some reason (e.g. OP failure). There are lots of other usage rules (geolocation, domain membership, etc.) but I think most of these can be invisible to the application and handle on the server side. Do you have a specific policy in mind that we do not have? Joe On May 13, 2014, at 12:07 AM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com<mailto:Shinya.Maruyama@jp.sony.com>> wrote: Now expiration time is the only usage rule EME API supports by Bug 25537<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25537>. Is the expiration time sufficient for the envisioned use cases? or Is there still the room to add other parameters? For instance, in case of rental video, start time and period after first use are used in general. In this case, constructing UI only by expiration date might be confusing to users because end time shortens after first use implicitly. As to start time, it might be useful if video is upcoming movie; i.e. start time is future time. Honestly, I’m not sure what is the criteria to decide which usage rules are common concept in EME world. Any opinion? Thanks, Shinya * Unknown Key * 0x2C9088FC
Received on Wednesday, 11 June 2014 07:34:16 UTC