WoT IG F2F - Discovery TF breakout -- 27 Jan 2016

<tidoust> Scribe: Francois

<tidoust> ScribeNick: tidoust

Soumya: Different topics to discuss today. First one is to finalize the tech landscape

<dom> Discovery Categories and Tech Landscape

Soumya: So far, we have 6 categories, each of them listing technologies.
... For each technologies, we identified the base technology, and other properties such as the maximum range where applicable.
... So far, this particular wiki looks complete.
... It would be good to port it to GitHub, as part of the deliverable we're going to submit for this Task Force.
... Do you see other technologies?

Francois: Thinking about the Push API, now implemented in some Web browsers.

Soumya: Category could be "searching in Directories".
... For battery-based devices, the Push API could be of interest.

Arne: The list looks good to me.

Soumya: In that case, I would suggest to freeze the Wiki for one week and transition it to the GitHub doc.
... Second point about the interaction patterns.
... Lists interaction workflows for the different categories.

<dom> WoT Discovery Interaction Patterns

Soumya: This is also complete that we could merge with the previous document.
... The two together would form the technology landscape survey

<dom> Tech Landscape Evaluation

Soumya: Then we come to the Tech Landscape Evaluation
... In Sapporo, we came up with a list of criteria to evaluate each technology.
... Examples are the interaction pattern, or the mention of lifetime / sleepy nodes, whether there is support for local/remote discovery of things.
... We haven't looked at the richness of query yet, but should do yet.
... One thing we understood is that not all criteria are applicable to all technologies
... Take category 1, UriBeacon, there are no ranking of results, also the discovery is triggered by manual interaction.

Mohammed: As we want to compare the technologies, we should keep the 8 criteria and explain why some of them are not applicable.
... It's clearer if we have the same criteria for all technologies.

Soumya: OK, thanks for the feedback.

Andrew: If we find more technologies, can we amend the list?

Soumya: Sure!

Andrew: For example, I'm thinking about Wifi beacn.

<scribe> ACTION: Soumya to include the Wifi beacon technology in the tech landscape [recorded in http://www.w3.org/2016/01/27-wot-di-minutes.html#action01]

<trackbot> Error finding 'Soumya'. You can review and register nicknames at <http://www.w3.org/WoT/IG/track/users>.

<scribe> ACTION: Francois to provide text on the Push API for inclusion in the tech landscape [recorded in http://www.w3.org/2016/01/27-wot-di-minutes.html#action02]

<trackbot> Created ACTION-23 - Provide text on the push api for inclusion in the tech landscape [on François Daoust - due 2016-02-03].

<dom> ACTION: Soumya to include the Wifi beacon technology in the tech landscap [recorded in http://www.w3.org/2016/01/27-wot-di-minutes.html#action03]

<dom> ACTION: Soumya to include the Wifi beacon technology in the tech landscap [recorded in http://www.w3.org/2016/01/27-wot-di-minutes.html#action04]

<trackbot> Created ACTION-24 - Include the wifi beacon technology in the tech landscap [on Soumya Kanti Datta - due 2016-02-03].

Soumya: Do you all agree about keeping the same set of criteria for all technologies?

[no objection]

Soumya: OK. Looking at category 2 about "Finding things on my network", we need to complete the table, looking for expertise here.
... Any volunteer?
... Also, if you know more technologies for category 4 (right now, only CoAP RELOAD)
... We'll ask again in the joint session with Thing Description Task Force.
... Moving on, another aspect we've looked into with Arne is to look at the different solutions that other IoT consortia have been looking into.

Mohammed: I can take care of the OMA line in this table.

<scribe> ACTION: Mohammed to fill out the OMA line in the Discovery Solution IoT Consortia table [recorded in http://www.w3.org/2016/01/27-wot-di-minutes.html#action05]

<trackbot> Created ACTION-25 - Fill out the oma line in the discovery solution iot consortia table [on Mohammed DADAS - due 2016-02-03].

<dom> Discovery Solutions Iot Consortia

Soumya: For oneM2M, we need to add the missing "Semantic search" category.

Arne: This AIOTI is from the EU Commission. I don't think it specifies any technology.

Dom: More a club than a consortium.

Arne: It could be removed from the list.

Soumya: ThreadGroup is developing technologies on top of IPv6
... HyperCat, in category 3.
... Not sure about the Open Group.

Francois: Should be at lower levels. Relevant standards are O-DF and O-MI. Should be active.

Soumya: They seem to be working on a standard for open IoT lifecycle management. To keep in mind as we're considering it for discovery and provisioning.

<Soumya> http://www.opengroup.org/getinvolved/workgroups/iot

Soumya: OGC SWE should be category 3 and 5.
... Now, I'd like to move to discussing of a general discovery framework.
... Looking at the building blocks of discovery.
... So many devices using different discovery and communication protocols.
... Even if you discover a URI, you need to know which protocols it supports.
... There was the question: should we create an abstraction layer for communication?
... [presenting slide of Proposed discovery framework]

Arne: This layer will be realized as an API in the end, right?

Soumya: I guess so. Question is, do we need this layer? Do we want to expose the abstraction as metadata?

Arne: A generic mechanism in the API would be complicated from an implementation perspective.

Soumya: I agree.

Mohammed: Even if it is not exposed by the API, the metadata needs to be available at the discovery layer.

Francois: Experience in W3C suggests that the API should not expose the information, security and privacy implications.
... However, the metadata is certainly needed for the user agent to establish the communication channel.

Soumya: At what stage of operation should that metadata appear?
... In the reply? As a response to another GET operation? During filtering.

Mohammed: Ideally, it should be done during the first exchange.
... Otherwise, if you don't know the available metadata, you're going to add extra round-trips that may end up being entirely useless.

Arne: Maybe you can also show the proposal from Louay regarding the API.
... He proposed already this very simple API that has also discovery parts in it.
... We had also a brief discussion if there should be some sort of generic discovery mechanism in that API.

<dom> Thing API WebIDL

[Projecting Louay's slides on screen]

[Arne going through the code example]

<dom> [I'm reminded of https://www.w3.org/TR/discovery-api/#requesting-networked-services ]

Arne: The filter is the main mechanism for discovery. Here a type and promixity, but this could be much richer.
... Then the code creates a ThingRequest object and calls start().
... Under the hoods, this is where the generic mechanism would be implemented.
... Then it uses the Thing.
... For us, the question would be "do we need a ThingRequest" or do we need a "BluetoothThingRequest"?

Dom: It's hard to say in general. Depending on the protocol, the request may have to be gated through different user interactions mechanisms.

Arne: That's true. This proposition does not consider security at all.

Mohammed: If we want to define something generic, you'll still need to define the type, proximity. Security parameters could be added.
... Whether devices will want to use the same vocabulary is not something we know today.
... It's sometimes easier when the thing explains the parameters that it is ready to give. No additional security needed. No need to request information.

Arne: Basically a role-based mechanism.

Mohammed: right, the first call to the device will give you the right information.

<andrew> The filter may have a security attribute. For example, the filter has "security-level", it could be "public", "private" and so on.

Francois: I note the "filter" in the example may or may not passed by the user agent as discovery parameters. The user agent may discover devices and filter them afterwards. Or pass the parameters, e.g. when querying a directory.

Soumya: For constrained devices, server filtering makes sense.

Arne: The question for me is whether we can make this generic enough.

Soumya: My experience is that it is complex.
... If you know the use cases that you want to target, it's easier to target specific technologies.

Dom: More generically speaking, if you want to talk to a Bluetooth device, you will want to specify the GUID of the service. Very different from an NFC use case.
... Starting from generic is extremely unlikely to succeed.

<inserted> scribenick: dom

tidoust: this depends on your use case
... if you know the technology you want to build on, a specific API is ok
... if you just want access to any matching device, a generic API would work
... but you can't have the same level of control
... that's the model of the Presentation API

dom: I think the key is to have something specific: either you're generic on the protocol, or you're generic on the type of device
... being generic on both sounds like a combinatorial nightmare

soumya: that matches my experience

tidoust: I don't think that means we should abandon the ThingRequest API
... it provides a way to connect a larger set of things in which browser vendors are interested
... (looking at some scenarios with connected things)

arne: another thing we can look at the type of filters we would want
... id for objects that have already been connected to
... types

soumya: this could be based on the Thing Description vocabulary

arne: the thing description is looking at defining properties
... a filter could be "I want things that have property "brightness"

soumya: the IPSO alliance is building a list of types
... http://www.ipso-alliance.org/

dom: how can such a list be exhaustive though?

soumya: good question; they're building it from the various organizations that standardize protocols

<inserted> scribenick: tidoust

dom: The option of using a property-based filter would seem more scalable than assuming that all objects are classified. If I have a device that combine multiple functions, how would it answer requests on type?
... What the developer will want is to be able to call a given method. You'll want to get things that respond to that.

<inserted> scribenick: dom

dom: filtering could be around duck typing more than formal typing
... (I want an object that "quacks")

tidoust: the generic sensor api defines a pattern that concrete sensors implement
... e.g. the ambient light — each concrete sensor defines its own data format

<inserted> scribenick: tidoust

dom: The idea of being able to reconnect to an object you've already interacted with. Similar mechanism in getUserMedia with the notion of deviceId. It's a very useful mechanism but it may, or may not be applicable to all protocols.
... There is also the question of whether the ID is a concrete one used by the protocol or whether it's an ID made up for the occasion, as done in getUserMedia for security reasons.

Soumya: Don't you need to know the ID beforehand?

Francois: First interaction will give you the ID, both in getUserMedia and in the Presentation API.

Dom: One thing that is ambiguous with the API we're looking at is that it's meant to be used in browsers and server environment. In the browser, you probably do not want to use concrete IDs.

Arne: OK, these are key questions. How generic the discovery request should be? And how to do the filtering?
... In the end, this is much related to the API.

Soumya: True.

Dom: That's an important point. There may be no need to distinguish discovery and API. At this point, it becomes an API question.

Arne: For the filtering, one approach is clearly defined filters (id, type, action, property). Another approach would be generic filtering with key-value pairs.

Francois: Doesn't the second approach include the first one?

Arne: Yes, the second one is much more powerful.

Soumya: Conclusion is we addresed 4 main points. The Landscape document and a very good discussion around the building blocks.
... One thing that I did not put here is ranking of the discovered results.
... How are we going to rank the results when we show them to the client?
... Can we envision something similar to search engine ranking mechanisms?
... Thanks all for the discussion.

<dsr> meeting: joint session of DI and SP task forces

<dsr> scribenick: dsr

Soumya introduces the agenda

Oliver: we want to protect access to particular capabilities, not just discovery

Oliver will recap the approaches we’ve been looking at in the SP task force

Oliver: we attach a security token with protocol requests

We have a client side authentication server (CAS) that provides this security token.

To get this the client needs to provide certain credentials

A complication is dealing with protected and unprotected end-points

The client side authentication server itself communicates with a separate authentication server that manages accesses to resources.

You might grant rights to turn on/off the lights, but not the heating (as an example)

This isn’t being claimed as the final solution, but is a valuable step in the right direction.

A similar approach can be applied to discovery

Soumya introduces the various discovery patterns:

“find things near me” which looks for physically nearby devices

“find things on my network” which is IP based

“find things on a registry” - where things have previously been registered

“find things semantically” based upon semantic relationships

The latter also relates to finding things based upon social relationships (Social IoT)

Oliver: most people need a high level human friendly approach

This has strong implications for authorisation of discovery

Oliver: for finding things near me, this often involves a short range broadcast, e.g. Bluetooth beacons.

There is thus a proximity model.

The classical authentication approach involves a request/response pair which doesn’t work here

Francois, if the broadcast gives an address of a server end-point then the classical approach can be applied.

<tidoust> This reminds me of the "Named Web Socket" proposal: endpoints would share some secret, used to encrypt a message in mDNS that only authorized endpoints could decrypt and use to communicate with the endpoint advertizing itself

Dave: a further idea is for the client to broadcast a request “hello who is near me” and for devices to respond. This can be combined with a security token as a basis for access control.

<tidoust> Named Web Socket proposal (with encryption)

<tidoust> (Note I'm not aware of any recent development of the Named Web Socket proposal)

Dave: for example using infrared, ultrasound or a wireless message of some kind

Soumya moves on to IP based techniques for finding things on my network

He shows a diagram whereby a client sends a multicast query message to a network entry point which relays this to all listening things.

The things send an advertisement message with their end-point address

Oliver: what about clients that were previously unknown?

Dave: the client could provide a credential from a trusted third party

Oliver: we would need to look at the details of whether end-points are protected or not

Francois: what are we trying to protect?

Oliver: we’re discussing how to limit who can discover what

Francois: do existing protocols e.g. SSDP support passing such security tokens?

Oliver: good question, this is something being discussed in the IETF

For HTTP, this is straightforward, for datagram based protocols, this is harder.

We want to avoid overcomplicating things

Soumya: what about searching in a directory/registry?

<tidoust> [Re. datagram based protocols, see the introduction to Secure DNS based Service Discovery (DNS-SSD) proposal part of the Named Web Socket idea mentioned above: https://github.com/namedwebsockets/networkwebsockets/wiki/Introduction-to-Secure-DNS-based-Service-Discovery-(DNS-SSD) ]

Oliver: this is similar to the first approach I described
... for this plugfest we took several shortcuts.

Soumya: accessing thing metadata. This is very similar in principle

Dave wonders if we are only thinking about HTTP, what about let’s say bluetooth, where access is predicated on first having peered with a device.

Francois: for MDNS/SSDP, the advertisements may be sent unsolicited

Dave: yes, these are unsecured discovery solutions
... Oliver drew the CAS and AS as separate from the client and server, but in principle the CAS can be merged with the client and the AS with the server.

Oliver: yes

Dave wonders what we could potentially learn from the new W3C WG based upon the submission from the FIDO alliance.

This pertains to assurances as to the human owner of a client device.

Oliver: quite so

<kaz> scribenick: kaz

TF-AP/TF-DI joint

soumya: shows the agenda wiki

-> https://www.w3.org/WoT/IG/wiki/F2F_meeting_2016,_January,_26th_%E2%80%93_28th,_France,_Nice#TF_AP_Agenda wiki

soumya: APIs for registering and discovery
... boundary between registration and discovery

johannes: WG charter discussion as well

soumya: ok

johannes: discussions on proposed APIs

<Soumya_> Joint session AP-DI

johannes: discovery API discussion this morning as well

soumya: shows the minutes from the DI-TF session

-> https://www.w3.org/2016/01/27-wot-di-minutes.html DI minutes

soumya: building block for discovery
... make sense to generic abstract layer?
... should try a subset?
... then WebIDL notation

-> https://github.com/w3c/wot/blob/master/TF-AP/thing-api/thing-api-webidl.md Thing API repo

johannes: this morning we had discussion on discovery
... the start will give you list of thing descriptions
... universal enough?
... not so sure how to proceed with Filter
... generic key/value pair
... something simpler specific type
... what simple/powerful enough API would be?

soumya: we're on the same page

louay: tech landscape to cover different technologies
... there are multiple use cases
... simple discovery
... discover for temperature sensor, etc.
... and more complex type of discovery
... local discovery requests discover things
... UPnP, BLE, or other protocols
... need to specify the types
... same APIs for physically different sensors
... some sort of hybrid solutions possible?
... put filter for SPARQL and other technologies

soumya: good addition

johannes: this is very generic approach
... could have SPARQL, etc.
... could have simpler approach, though
... the resolution could be we don't specify concrete protocol for discovery
... and continue this generic approach

soumya: next
... APIs for registering and discovery

johannes: some repository-based discovery?
... don't want to dig in the details now

soumya: shows the DI-TF wiki
... then github repo

-> https://github.com/w3c/wot/blob/master/TF-DI/Interactions.md TF-DI repo - interactions.md

soumya: exaple of distributed cities
... pulled up into the cloud
... quite simpler

johannes: not aware of the registry
... using server-side API?
... during the plugfest, we had some central repo
... server generates thing description
... you could register TD

soumya: just send a payload

johannes: we are not very sure about this API
... could be automatically done
... using Thing Description

soumya: any other points?

claes: not seen yet
... but how the exact interaction is done?

soumya: the matter of MIME type

johannes: within the HTTP post?

soumya: yes

kaz: are you planning to add that kind of clarification to the repo document?

soumya: yes

<scribe> ACTION: soumya to add clarification to the tech landscape and the discovery interaction pattern doc based on the f2f discussion [recorded in http://www.w3.org/2016/01/27-wot-di-minutes.html#action06]

<trackbot> Created ACTION-28 - Add clarification to the tech landscape and the discovery interaction pattern doc based on the f2f discussion [on Soumya Kanti Datta - due 2016-02-03].

soumya: shows the IG main wiki
... and then WG work items

-> https://www.w3.org/WoT/IG/wiki/Proposals_for_WoT_WG_work_items proposals for WoT WG work items

soumya: we can try to see interaction for discovery

joerg: how to handle the discovery topics?

soumya: had discussion with Sebastian

joerg: TF report discussion tomorrow morning

soumya: would see their (=TF-TD) opinions as well

johannes: would see as one of the WG topics
... what the scope for the WG should be?
... include in the deliverables?
... WoT scripting APIs
... how to describe discovery things
... some of the discovery APIs may be related to the protocol mapping
... something to describe the mechanism of discovery
... API viewpoint and TD viewpoint

soumya: anyone has any points?

joerg: could be something to be done during the discussion
... need to see if included in the deliverables
... would make sense to make sure

soumya: those are three topics in my mind

claes: interested in seeing if we should have the API

joerg: would see what's important tomorrow

johannes: objectives

soumya: clicks the objective section

https://www.w3.org/WoT/IG/wiki/Proposals_for_WoT_WG_work_items#Linked_Data_Vocabulary_For_Describing_Data_Models

Design and development of a technology independent discovery for Web of Things.

Provide guidelines for binding to APIs and protocols for efficient interaction with things.

Utilize an uniform catalog of descriptions (as defined in things description) for discovery of things and their metadata.

Provide means of ranking the discovery results (when presented to end users or other M2M applications).

johannes: tx all!

[ break and go back to the main room ]

- DRAFT -

WoT IG F2F - Discovery TF breakout

27 Jan 2016

Attendees

Contents

TF-AP/TF-DI joint

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output