TF-DI Meeting 13-Aug-2015

Agenda Discovery presentation from William Miller Review of discussions at F2F Sunnyvale Interaction patterns of tech landscape Evaluation criteria list for technical landscape document Kick-start of discussion on security and discovery AOB TF-DI & IG-SP joint session on 20-Aug

Summary of Discussion W3C WoT IG Sunnyvale F2F

Results at F2F in Sunnyvale Conclusions Organisation of tech landscape Initial set and how to proceed with requirement discussion Contributions Interaction patterns describing discovery categories Joint Session Discussion of S&P requirements for “discovery by search in a directory” atomic use case Next Steps Complete evaluation criteria list for technical landscape document Conduct evaluation of discovery technologies p 4

Sketch of Landscape Finding things around me Discovery based on geographic local accessibility Finding things on my network Discovery based on accessibility in a local network Searching in Directories Discovery in well known directories Searching across Peers Discovery in distributed, P2P style architectures Accessing thing metadata Discovery of metadata of particular thing(s) of interest For details see p 5 Conclusions: Adopt structure for tech landscape document Start with already comprehensive list of technologies Categorization reflect lower layer concepts Consider higher layer concepts (e.g. discover things which I own) starting from use cases

Discussion on Requirements Discovery should be independent of the communication technologies used by the physical things. Interaction model Smart agent in the middle The communication technology used by the thing should be visible in the metadata to later ease the binding to that technology. Interact with TF-AP and TF-TD on this aspect See also “bootstrap” discussion The things should be capable to automatically register themselves to the central registry for the discovery process. Interact with TF-TD for configuration metadata of things Consider both smart and legacy things Conclusions: Requirements need clear scoping wrt building blocks Requirements shall track use cases which motivate them Due to scoping these need often further discussions with other TFs

Discussion on Requirements Depending on the context and use case, the things could register to a central registry to be discovered. CoRE Resource Directory is an example of the central registry. This type of discovery is well suited for "searching in a directory". Joint discussion TF-DI and TF-TD Keeping for further discussion A "lifetime" is required through which a thing is discoverable to other WoT applications and services. Think of use case where the communication of lifetime is applicable Discoverability (when a thing is “waking up”, it should send a signal to others) Think about the semantics of terms Use case not clear The discovery mechanisms should enable both local and remote discovery depending on the context and use case. How about “socially local” (different abstraction layers on the context of discovery). What can I reach in my environment? Notion of discovery in lower and higher layers of abstraction [further discussion] Lower layer – discovery on metadata The discovery metadata are required to carry the following information – Bootstrapping TF-TD, IG-SP A log of discovery results should be maintained for the admin purpose. Caching, Platform choice, Security Drop it

Interaction Patterns of Discovery Categories For evaluation of technologies in each discovery category draft interaction pattern Also helpful for interface to TF AP Example: Searching in Directories: Work started, will be complemented by evaluating current technologies p 8

Evaluation Criteria for Discovery Tech Landscape Evaluation (catalogue) aspects Interaction Pattern – does it share the current draft of interaction pattern in that discovery category Support of higher layer discover concept – does it provide means for higher layer discovery using thing descriptions Bootstrapping – what means are provided to start/interact with things after discovery Lifetime / sleepy nodes – does it provide means specifically supporting sleeping times of constrained devices S&P – what S&P requirements are identified and addressed

Security and Privacy in Discovery

Security issues Access control Discovery request should be limited to things determined by access control policies. Privacy Search history should be private Trust Determine trust on a thing, metadata etc. Authorization Only authorized things should be allowed to register at a directory (for directory based searches)