TV Control API CG call

08 Dec 2015


See also: IRC log


Kazuyuki_Ashimura, Bin_Hu, Chris_Needham, Tatsuya_Igarashi, Francois_Daoust, Paul_Higgs, Sung_Hei_Kim


<scribe> scribe: tidoust

Review of action items

Bin: I think that we have completed all the open action items, so the list is empty.

<kaz> agenda wiki

Review of the draft WG charter

Bin: Thanks Francois for drafting the initial charter. It's great to see momentum since TPAC, where ATSC indicated interest to reference this specification.

<kaz> draft WG charter

Bin: Based on these discussions, several people at W3C kicked off transition activities.
... Several people have contributed to these discussions already. I think the charter is in good shape.
... The goal is to wrap-up and see if others have additional comments.

<kaz> scribenick: kaz

tidoust: agree the draft charter looks good
... but there are two questions
... would like to raise again
... the group agrees with what would happen?
... also the API would be for usual Web runtime?
... would work for TV tuner as well
... the charter currently doesn't clearly states
... it's for usual Web model
... so want to check that point

bin: the deliverable of this proposed group should be usual Web runtime
... similar to the ones on automotive

<tidoust> scribenick: tidoust

kaz: I think that's an important point. Probably we should ask TV vendors for this question. Igarashi-san, for instance, do you have a specific opinion? Usual Web runtime may be difficult to define in any case.

igarashi: I personally think that regular Web browsers will not support this API in a long time. Broadcasters will not allow to use this API for everyone, I think. I don't have a clear opinion but I'm wondering about the current security model of the automotive API.

Kaz: That's a good question.
... The WG works collaboratively with the BG. The current spec does not handle security considerations in particular.
... The first version is only read-only, i.e. getting not setting.
... That is a difference between these two APIs.

Igarashi: I think the situations are similar. Can any Web application use the automotive API?

Kaz: Right. We might want to clarify things in the charter, then.

Igarashi: Currently, if we apply the security context to the TV Control API, we need to think about very complex issues, including related to addressing broadcasters concerns.

Kaz: other concerns for TV manufacturers, I suppose.

Igarashi: right.

Kaz: Section 3.1 could include links to Automotive WG, Web of Things IG.

Paul: Is the automotive group where different applications from different sources are running on the same platform?
... There might be less and more sensitive apps.
... I wonder if the group is working on the classification of apps. Then I could see how that could apply to us.
... Otherwise, we need to look elsewhere, and find a way to authenticate an app.
... so that it gets the rights to use this API.

<kaz> strawman model

Kaz: The Automotive WG/BG is working on several aspects related to this, e.g. in a Wiki page. The group has started to work on security models.
... We need some kind of proxy that handles the connections inside and also outside of the car.
... That could be some kind of hardware or some kind of software.
... This is probably relevant to the TV Control API WG as well.

Bin: Thanks for the great input. First, in 3.1, we need to add Automotive group to understand their security model to prevent apps to gather sensitive information from the vehicle.
... Regarding the security model, let me read the current text to see if we need to adjust it

[[ The API layer will meet the usual requirements of the Web runtime, including privacy and security requirements. The Working Group may introduce a second level of conformance to expose features that may prove more specific to tuner-centric devices (TV and radio sets typically), such as the ability to scan channels. ]]

Bin: The second sentence indicates that we may add a second level.
... It's really subject to interpretation. Do you think that future work may include work on defining a second level?

Kaz: I think that the text here is good enough.

[[ The specification(s) produced by this Working Group will include security and privacy considerations. The APIs developed by this group may use a different security model than the traditional browser security model. ]]


<inserted> scribenick: kaz

fd: would note the Automotive WG Charter says:The APIs developed by this group may use a different security model than the traditional browser security model.
... when I heard Igarashi-san, TV-centric model would be a bit difference
... so would add similar text as the Automotive Charter to the TV Control API Charter

igarashi: +1
... would use the similar text

kaz: that's good

<tidoust> scribenick: tidoust

Bin: So it would be beneficial to add a similar sentence as in the Automotive WG charter.

<inserted> scribenick: kaz

Bin: btw, would ACs ask what the "different security model" would be?

fd: would expect push-backs from ACs

bin: maybe we should use a bit different words
... the group may enhance the traditional security model based on the current Web security model
... for different types of TV devices

fd: my problem might be that "enhance" may sound more secure than the usual model

bin: if there is no better words, maybe we can simply reuse the one from automotive

<Paul_Higgs> "augment" the current security protocols

igarashi: channel information is not controlled by the user
... other security model may require secure origin like EME
... but it might be problematic
... because "secure origin" could control the device on their own

<tidoust> scribenick: tidoust

Chris: I just agree with the comments from Igarashi-san. I would like to get a better understanding of where we see the divide between the two types of devices. It's not entirely clear in my own mind where we might draw the line.
... If we're on a broadcaster Web site, can the app switch to other channels of the same broadcast?
... It's not entirely clear what the division may be.

<Bin_Hu> Words: The group may use a different security model than the traditional browser security model for the second level of conformance.

Kaz: I just wanted to say that I have been working as staff contact and will work with Francois to handle AC review concerns, so don't think we should worry too much about wording.

<inserted> scribenick: kaz

fd: hope it's useful to have this discussion
... my initial question was: the group would work for web runtime and some specific (device) runtime?
... the question related to the timeline
... the more we put into the charter, we need more time
... the goal is to generate a W3C standard within one year
... that is an aggressive target
... so I wanted to raise the question on the scope of the group
... I'm fine with keeping the two levels of security models

<inserted> scribenick: tidoust

Igarashi: I'd like to understand the case for having the Web runtime model apply to this API
... In my mind, the channel information and program information are very specific data that require some kind of copyright.
... That's very different from application-specific data.
... How would the API address business owner concerns?
... EME does not handle copyright issues of the owner of data.
... In this case, the goal is to expose data to the application, which is very sensible.

Bin: Understood. The reason I want to keep this in the charter is that, first I want to keep things more open for future. Secondly, I'd like to be pro-active about AC review comments we may get that point out SysApps WG did not work out in the end.
... I don't have a strong opinion though. This means the whole paragraph in the draft charter may need to be revisited as a result.
... We may want to introduce some new text to replace this text.

Kaz: The traditional Web security model may be updated based on requirements of the Automotive world. I don't think we should worry too much.

Chris: My comment is that I would like us to keep the Web runtime in the scope of the charter.
... The TV Control API gives us a very nice integration point with video sources and the <video> element.
... It's one of the main interesting points of the specification to me.
... I agree that there are features such as channels scan that we would not want to expose to Web apps, but I think it should be in our scope to work out which are the sensitive APIs and how do we pull in place the appropriate security controls around the access to these APIs.
... There's a lot of unanswered questions but I think the group should have the opportunity to work on this.

<kaz> automotive charter

[[ The specification(s) produced by this Working Group will include security and privacy considerations. The APIs developed by this group may use a different security model than the traditional browser security model. ]]


Igarashi: I think the wording of the Automotive charter is good.
... Also, Chris, wouldn't broadcasters have issues with metadata being exposed to any Web application?

Chris: That's something I need to look at.

Bin: Time check! Sorry, we've reached the top of the hour and I need to hop to another call. Why don't we discuss this on the mailing-list and conclude in next call?
... We should be able to achieve consensus through emails.

Igarashi: Right. I'd like to comment one thing about the milestone. I understand that the current milestone is very aggressive. If we're not, we will lose momentum in the industry!

Francois: Right, I said aggressive, but not impossible ;) That's also the reason why it seems important to refine the scope to avoid unexpected issues.

Bin: Francois, please update section 3.1 based on discussions and work on text for runtime.

Francois: Sure!

Kaz: By the way, the WebEx does not seem to work well, so I'll work on this.

Bin: Right, first call in 2016 should be January, 12th. I'll circulate the info.

[Call adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2015/12/08 17:18:07 $