[tvapi] minutes - 8 December 2015

available at:
 http://www.w3.org/2015/12/08-tvapi-minutes.html

also as text below.

Thanks for taking notes, Francois!

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                         TV Control API CG call

08 Dec 2015

   [2]Agenda

      [2] https://www.w3.org/community/tvapi/wiki/Main_Page/Agenda_Telco_Dec_08_2015

   See also: [3]IRC log

      [3] http://www.w3.org/2015/12/08-tvapi-irc

Attendees

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

   Regrets
   Chair
          Bin

   Scribe
          tidoust

Contents

     * [4]Topics
         1. [5]Review of action items
         2. [6]Review of the draft WG charter
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <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> [9]agenda wiki

      [9] https://www.w3.org/community/tvapi/wiki/Main_Page/Agenda_Telco_Dec_08_2015

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> [10]draft WG charter

     [10] http://w3c.github.io/charter-drafts/tvcontrol-2015.html

   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> [11]strawman model

     [11] http://www.w3.org/2015/10/auto-f2f/DSC_0078.JPG

   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. ]]

   [12]http://www.w3.org/2014/automotive/charter.html

     [12] 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> [13]automotive charter

     [13] http://www.w3.org/2014/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. ]]

   [14]http://www.w3.org/2014/automotive/charter.html

     [14] 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]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


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

     [15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [16] http://dev.w3.org/cvsweb/2002/scribe/