See also: IRC log
<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
soumya: shows the 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
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 ]
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/?1/Andrew/g Succeeded: s/cloud/club/ Succeeded: i/tidoust: this/scribenick: dom Succeeded: i/dom: The idea of being able/scribenick: tidoust Succeeded: i/dom: The option of using/scribenick: tidoust Succeeded: i/dom: filtering could be around/scribenick: dom Succeeded: s/“find things near me”, “find things on my network” which// Succeeded: s/address/address of a server end-point/ Succeeded: s/of a/or a/ Succeeded: s/multcast/multicast/ Succeeded: s/protocols/protocol mapping/ Succeeded: s/what's/would see what's/ Succeeded: s/important?/important tomorrow/ Found Scribe: Francois WARNING: No scribe lines found matching ScribeNick pattern: <Francois> ... Found ScribeNick: tidoust Found ScribeNick: dom Found ScribeNick: tidoust Found ScribeNick: dom Found ScribeNick: tidoust Found ScribeNick: dsr Found ScribeNick: kaz ScribeNicks: tidoust, dom, dsr, kaz Present: Mohammed Soumya Francois_Daoust Dave_Raggett Dave Oliver Francoise mdadas Andrew Rui Got date from IRC log name: 27 Jan 2016 Guessing minutes URL: http://www.w3.org/2016/01/27-wot-di-minutes.html People with action items: francois mohammed soumya[End of scribe.perl diagnostic output]