See also: IRC log
<scribe> scribe: tidoust
Bin: I think that we have completed all the open action items, so the list is empty.
<kaz> agenda wiki
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. ]]
http://www.w3.org/2014/automotive/charter.html
<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. ]]
http://www.w3.org/2014/automotive/charter.html
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]