Re: Request to add parameters to createSession (bug 17660)

On Oct 30, 2012, at 9:39 AM, Mark Watson wrote:

Joe, Martin,

Could you each clarify whether you are arguing for (a) appData that is keysystem-specific and requires keysystem-specific code in the application to create it, or (b) appData that is application-specific and keysystem-independent, that the CDM just passes transparently in the keysystem messages ?

[steele] I am arguing for keysystem-specific appData that is created by the application. I don't think this is an issue since the initData being passed in alongside the appData is clearly not keysystem-independent. It may also be application-specific data (e.g. the some identifying information about the app) but I am not sure how that applies here.


I can't really comment further unless I know which is proposed.

On Oct 30, 2012, at 4:48 PM, Martin Soukup wrote:

I agree with both the points that securing data in the CDM transaction is significantly more cost-effective in network infrastructure (as well as, typically, being faster and thus providing better user experience) and that some systems require this kind of interaction. It would be highly restrictive and incompatible with many existing implementations to disallow passing of appData to the CDM for inclusion in a messaging request.

This is maybe a picky point, but we're discussing a new proposal to add something, not a proposal to disallow something. To my knowledge there is only one existing implementation of this specification.

[steele] I believe Martin is referring to existing content protection implementations, not existing CDM implementations. The current spec does not provide for application specific data to be passed to the CDM. This will make creating CDMs that are interoperable with some existing content protection implementations more difficult.


I assume that a secondary goal of this specification is to limit the infrastructure / network changes required to support compliant clients?

If our goal is to make the app logic independent from the CDM don’t we need to either enforce consistent behaviour across CDMs

Yes, as far as we can.

or provide a mechanism to ensure the CDM of choice is available in all places?

The CDMs that are available on a given client are just those that the client vendor chooses to provide. Nothing we can do in the spec to influence that. The application should be able to detect what is available and make a choice, including the choice not to show content if a suitable CDM is not available.

…Mark


Martin

From: Joe Steele [mailto:steele@adobe.com]
Sent: Tuesday, October 30, 2012 11:21 AM
To: Steven Robertson
Cc: Mark Watson; <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: Re: Request to add parameters to createSession (bug 17660)


Joe Steele
steele@adobe.com<mailto:steele@adobe.com>

On Oct 23, 2012, at 10:25 AM, Steven Robertson wrote:


On Fri, Oct 19, 2012 at 4:08 PM, Joe Steele <steele@adobe.com<mailto:steele@adobe.com>> wrote:

On Oct 19, 2012, at 12:45 PM, Mark Watson wrote:
If, however, you are proposing that the appData is *opaque to the CDM*, then
things might be different. i.e. the appData would be an opaque BLOB that the
CDM is supposed to include within the license request message (protected by
whatever mechanisms the CDM uses to protect its messages). Is that what you
meant ? I'd have to think further about that.

[steele] I am not sure I see the distinction here. I can already append
opaque data to the initData passed in createSession from the client app.
However I would have to include additional logic in the client app to encode
the opaque data in a way that key-system wants. With my proposal - any CDM
(including ClearKey) can use the information directly or encode it
appropriately for the key server without having the encoding logic in the
app itself.

[strobe] I think the issue is that *every* CDM would have to do so in
order for this to be usable, and that mandating such a change would
shut out most key systems available today (and thus basically kill the
spec). The worst-case scenario is that some combinations of key system
/ CDM / license format support embedding in a secure way, some support
embedding in a non-secure way, and some do not support embedding at
all, in which case the app must become uncomfortably aware of the
license request format. If this is an optional feature, it could be
argued that nobody would have to use it in cases where there were
differences in the security levels of various key systems, but I posit
that even as an optional feature some authors would come to rely on
this behavior, which would then limit interoperability if new key
systems became available in the future which did not support secure
transmission of appData.

My proposal does not require every CDM to actually use the information passed, nor every application to pass the information. It only says that applications can pass this information and CDMs can use it if available. I am more than happy to stipulate that if an application does not pass information in this fashion, the CDM is not allowed to fail because of it.

I am further saying that interoperability is already limited by the fact that some key systems transmit appData in this fashion and it is not allowed by this spec. We don't have to speculate about whether this will become a problem - it is a problem right now for my key system.

Joe



Steve