- From: Francois Daoust <fd@w3.org>
- Date: Tue, 04 Nov 2014 18:18:55 +0100
- To: "public-webscreens@w3.org" <public-webscreens@w3.org>
Hi participants of the Second Screen Presentation Community Group,
There has been a breakout session on extending the Presentation API to
address Web of Things use cases during TPAC. While not in scope for the
Working Group (I'm not including the WG mailing-list on purpose), this
could be of interest to the Community Group, so I thought I'd share some
information about it.
Draft minutes of the session are available [min] and copied as text
below for your information. See the description of the breakout session
[desc] for links to the slides that were presented.
I expect the discussions to continue in the Web of Things Community
Group [wot], in the Web of Things Interest Group if and when it gets
created, and here if people are interested.
Francois.
[min] http://www.w3.org/2014/10/29-startsession-minutes.html
[desc]
https://www.w3.org/wiki/TPAC2014/SessionIdeas#startSession.28.22WoT_devices.22.29
[wot] http://www.w3.org/community/wot/
-----
- DRAFT -
startSession (WoT) Breakout
29 Oct 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/10/29-startsession-irc
Attendees
Present
a1zu, ak, alan-i, AnnBassetti, bryan, ddavis,
fabien-gandon, forty4, gick, Hitoshi, hyojin, igarashi,
ima, jcverdie, jhund, Joerg, JonathanJ1, kaz, kirby, kn,
Louay, mdadas, _M_, naomi, Noriya, nsakai2, ohmata,
olivier, pfps, raphael, ryuichi, sakoum, Shige, terri,
tidoust, Tomoki, tomoyuki, yinagaki, yohsumi,
Youngsun_Ryu
Regrets
Chair
Ken Komatsu
Scribe
kaz, ddavis
Contents
* [3]Topics
1. [4]background and agenda
2. [5]StartSession
* [6]Summary of Action Items
__________________________________________________________
<jcverdie_> material can be found here:
[7]https://www.w3.org/wiki/TPAC2014/SessionIdeas#startSession.2
8.22WoT_devices.22.29
[7]
https://www.w3.org/wiki/TPAC2014/SessionIdeas#startSession.28.22WoT_devices.22.29
background and agenda
<kaz> done
StartSession
<inserted> scribenick: kaz
<inserted> scribenick: kaz
igarashi: three open questions
... device interaction
zkaim, who is here?
zakiim, who is here?
scribe: the sense of WoT is too broad
... would think about narrower area
... (startSession("WoT Devices")
... Web servers on any devices and UAs on any devices
... device interaction is today's topic
... local network connection
... we call it "startSession"
... UA2UA connection
... (Challenges for Device Interaction)
... list of W3C groups tackling device connection
... MMI WG, Web&TV IG (HNTF)
<ddavis> scribenick: ddavis
igarashi: The Device APIs WG started to create the network
service discovery API.
... The Device APIs WG also looked into Web Intents for
devices.
... And at TPAC 2013 the second screen presentation CG started
and this month became a working group.
... This working group has big momentum and browser vendors
have already said they'll support it which is very good.
... This slide shows what the second screen presentation API
is.
... The example scenario is for tablet and TV.
... There are two cases to consider - one is that one UA is
running on the devices and the rendering result is copied via
Miracast, AirPlay, etc.
... In the other case, two UAs exist and they communicate with
each other.
... In the presentation API, the underlying protocol is out of
scope.
... The communication is started with startSession() and then
messages are sent using the Messaging API.
... This slide shows a comparison of how the presentation API
differs to the NSD (Network Service Discovery) API.
... These are my observations. The Presentation API scope is
very limited compared to NSD.
... NSD can use protocols such as SSDP, mDNS, DIAL and HTTP.
... For the presentation API, there is no discovery information
sent to the web application.
... The UA shows the device list by itself.
... This is because of privacy issues. The NSD API does provide
a list of discovered services to the web app.
... This raises privacy concerns.
... The Presentation API uses messaging and Cross-Origin Access
is at the UA's discretion.
... For NSD API, messaging is used with CORS.
... Regarding protocols, discovery and messaging are out of
scope for the presentation API but not for NSD API which use
existing protocols.
<tidoust> Note that support for SSDP, mDNS, DIAL in Network
Service Discovery API is also up to the User Agent, i.e. a User
Agent is not required to support any of them, see
[8]http://www.w3.org/TR/discovery-api/#service-discovery
[8] http://www.w3.org/TR/discovery-api/#service-discovery
igarashi: I have three open questions.
... The Presentation API is a good approach to standardize and
balance between functionality and privacy.
... 1) Why should the common messaging API not be used to
interact with non-screen devices, i.e. WoT devices?
2) How to ensure interoperability if WoT devices are provided
by different vendors?
scribe: 3) What is the security model for cross-origin access
for WoT devices?
... Let's look at messaging. startSession is used and for WoT
devices a URI or URL could be used.
... E.g. startSession("urn:schema-example-com:wot")
... Discovery is UA implementation dependent.
igarashi: Messaging is very generic and the same protocol can
be used for WoT devices.
... The second open question is about interoperability with WoT
devices.
... The protocol is out of scope which is a good decision.
... In the case of WebSockets and WebRTC, they're defined by
W3C.
... However the protocol is defined by IETF. Maybe this idea
can be used for presentation API.
... PHY/MAC layers vary in WoT devices.
... Regarding the security model, my question is whether the
content security policy for the web can also work for the WoT.
... I wonder whether technology such as CORS can be used along
with the presentation API.
... Another security question which will be explained more by
Toshiba is whether WoT devices can or cannot support TLS/SSL
practically.
... Also, can we standardize a security model beyond the
presentation API?
... I wonder if there is a reasonable presentation for
non-technical consumers.
... That's the end of my presentation.
honma: I'd like to show a demo of non-screen devices using the
presentation API.
... I'm from NTT Communications.
... There is a presentation API library which I'd like to
demonstrate.
... I'm using Sony's ActionCam. It has no screen but it
provides a REST API.
... The user can take a picture and record video with this API.
... When using non-screen devices, we need to specify the type
of devices. We suggest using urn: for this.
... Calling the startSession method the session object will be
returned.
... Using an event handler and postMessage method, the web app
can communicate with the ActionCam using the remote API
provided by the camera.
... This is a web app using the presentation API.
[Shows demo]
honma: Clicking the in-page button means I can select the
device.
... This application is using the presentation API for
communication.
... This is the application of this demonstration.
... The presentation API shim works with the device driver
module, which tries to find the camera with SSDP.
... After that, the web app can communicate with the device, in
this case using the Sony API.
... Finally, I propose requirements of the system such as...
... Filtering rules for which the UA can discover 1) by web app
with dedicated API, and 2) browser discovers all kinds of
devices and notifies the web app.
... The second requirement is regarding communicating with
various devices.
... 1) With the modules provided by the 3rd party vendor, and
2) With the modules provided by the browser vendor.
komatsu: Next is Sakamoto-san with a talk about the security
model.
sakamoto: I'm from Toshiba Japan.
... Recently we've been accessing many devices simultaneously
in a home network, for example tablets, TVs and smartphones.
... Hybridcast is a new service launched in September last year
in Japan.
... The user can enjoy multi-screen services.
... The companion applications use HTML5 from service
providers.
... This slide shows the connection method.
... The signal first comes from the TV set and sends the URL
from the TV set to the phone.
... The companion browser gets the web app from the provider's
server.
... In more detail, firstly the URL is sent from the TV to the
phone.
... Then the browser accesses the URL and gets the HTML5 app
for the companion device from the server and executes it.
... We can use the maker's JavaScript engine.
... This slide shows the entire system.
... We can send information from the TV to the phone. with a
WebSocket server in the TV set.
... The TV set can not publish SSL certificates for the WS
server.
... The phone browser is not allowed self-certification from
the TV set so maybe the browser displays a warning message.
... Recently one or two browsers have changed their security
policy for the WebSocket protocol, so we can not use SSL in the
local network.
... This means we can send information to the phone.
... So we'd like to change the security policy in the local
network.
... In conclusion, Japanese broadcasters are trying to use
WebSockets to exchange information between TVs and phones.
... But we cannot do this using published certificates from a
TV to a phone.
... So we should discuss the security policy if we plan to use
WebSockets for home networks.
komatsu: Our session is based on Mr Igarashi's three open
questions.
komatsu: From now we have an open discussion. Does anyone have
any questions?
tidoust: I'm Francois, staff contact for the second screen WG.
... I'd like to emphasize the need to consider use cases.
... In the camera demo, I wonder if the use of the presentation
API is the best thing for this problem.
... I'd expect getUserMedia to be used.
... In my view it's better to use getUserMedia because the web
app just wants a camera feed, it doesn't want a URL.
... I expect the presentation API to be extended to other use
cases but it may not be the right thing sometimes.
... Also, the Device API WG is looking at specs for sensors
which could be relevant for WoT instead of the presentation
API.
... The scenario seems to be important.
komatsu: For today's camera demo, to use getUserMedia is
interesting.
... But Mr Igarashi's proposal is not just about cameras.
igarashi: In my opinion, it depends. That demo is just one
example.
... Also Sony's camera supports various functions which require
some messaging passing mechanism.
... The second issue is should we specify a Device API for all
devices, for Sony and for all other manufacturers. Should we
have APIs for all devices? That would be thousands.
... It's probably not reasonable to define APIs for each
device. A more generic approach is required.
... In the web, W3C doesn't define a protocol.
tidoust: Should the messaging service run on the device?
igarashi: Maybe a proxy case can be considered. That's an
implementation issue.
jean-claude: I prefer their demo to one I could do which is
between two pages. Theirs has more impact.
... The device proxy - does it do discovery?
komatsu: Yes, it supports SSDP .
jean-claude: One web page is a service, the other is something
that discovers the service, is that right?
igarashi: That's right, but the second screen doesn't have a
display so no way to show the messages.
... The second screen API has two aspects - discovery by the UA
and messaging between devices.
bryan: One thing to consider is discovery which Rich Tibbett
has been looking at for years.
... There are going to be thousands of devices and lots of
protocols. I don't think it's going to be possible to
incorporate all this in browser modules.
... Maybe you could have a local services acting as a bridge to
enable discovery and you can then delegate the security to that
bridge.
... We have to consider the role of the device as a host for
web services outside the browser.
... The second thing is the long-term viability of the user
experience is going to depend upon how quickly these things can
be built.
... The W3C's timeline is not going to support the diversity
that's going to hit us like a flood.
... We have to defer to the specific devices and services for
security and privacy.
... The security/privacy problem for the web has to be solved
on a larger web scale.
... But that's a separate thing.
... Let's use bridges to solve this in the platform.
igarashi: I understand what you're saying Bryan.
... I tried to narrow the scope of the discussion.
... Maybe devices don't connect directly to a UA. They could go
through the existing model of the web (SSL).
... But in a local network there are some use cases already.
This is the scope of our discussion.
... There are also intermediate devices in this case. We use
private network address in this case.
bryan: I agree a gateway in the home should be able to use SSL.
... It's not the browser that's complaining.
... We have to consider what's practical. Wherever that gateway
is it can solve the problem in the short term.
... You have a native application using localhost, on the
backend you have an app.
igarashi: even communicating with a local server we have a
security issue.
... The browsers don't allow pages to communicate with SSL
pages.
... The gateway is one solution to the deployment issue but the
security issue still exists.
louay: There are two parts to the presentation API - controller
and messenger.
... The presentation API is independent from the technology -
it provides communication between two web pages.
komatsu: Our demo is just related to hardware devices.
igarashi: the messaging api is app-specific.
louay: Maybe in the background a different protocol is used but
from the developer point of view the same messaging method is
used.
... Thecommunication between devices is application-specific.
komatsu: Currently the implementation is the presentation
provides high-level messaging.
... There are other video devices that have specific device
driver modules and generic messaging can be done with the
application.
louay: I'm speaking about how to address these devices.
... A specific type of URI is pointing to a specific type of
device. I wonder how we can do this in a more abstract way. At
the moment the presentation API is using URLs to point to web
pages.
komatsu: We need a more abstract identifier.
... Maybe represented by URL, I'm not sure. We need to discuss
such an identifier.
jean-claude: If you have a printer, you don't want to have
possible URIs for all possible printers, you want to just say
"printer".
igarashi: Applications should use web service-specific APIs.
jean-claude: As Louay said, you have the presentation API on
the discovery side but you need a way for the web page to say
"I'm a web service". What's your thought on that? If you want
to have UA to UA communication you need something.
igarashi: That's out of scope and up to the browser vendor
currently. The current presentation API just defines the API
and the protocol and security policy is up to the
implementation.
... Shall we ask everyone about these questions?
... Do you think presentation API should be defined for
non-screen devices?
[roughly 30% yes, one person a possible no, 70% don't know]
igarashi: Do you think W3C should define underlying messaging
and discovery protocol for WoT devices?
[0% raised hands]
bryan: Would you accept a definition that was based on existing
W3C tech such as WebRTC/WebSockets?
igarashi: I think that modification is OK. Maybe we should
separate discovery as well.
... For the communication protocol, we should support existing
protocols?
[roughly 15% yes, 0% no]
igarashi: Do you think we need to think about the security
policy more?
[roughly 30% yes, 0% no]
ann: How many people think these were good presentations?
[100% yes]
komatsu: Thank you for your time.
Summary of Action Items
[End of minutes]
Received on Tuesday, 4 November 2014 17:19:29 UTC