<jcverdie_> material can be found here: 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 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.