Meeting minutes
Scribe
Sebastian for the 1st part
Daniel for the 2nd part
Overview - McCool
<kaz> agenda for today
McCool gives an intro about Discovery
<McCool> https://
McCool: the idea is to find devices in the field
… discovery goals have different capabilites such as local / global discovery
… searching large repositories
… p2p discovery
… another goal is to have privacy-preserving architecture
… this includes lifecycle and user policy
… we want also to be aligned with existing standards
… currently we have a two-phase architecture
… phase 1 is about introduction and phase 2 is about exploration
… phase 1: first contact protocol which provides addresses of exploration service
… phase 2: may use authentication. There can be queryable database or direct retrieval of TD from Thing
… we address privacy considerations
… and security
… like man-in-the-middle attack
… we like to have a resolution about next WD update in 2 weeks
Kaz: will be April 7th
Introductions - Toumura
Toumura: gives an overview about the 2 phase architecture
… there are 5 mechanisms for discovery like a CoRE Resource Directory, DNS, Direct, well-Known URI, Decentralized Identifier
Toumura: compared to last vF2F we not introduced significant changes
… update the type ussage in CoRE Link
… and few editorial changes
<Zakim> dape, you wanted to 1st phase talks about TD of thing or TD of directory. Isn't there a 3rd category (missing)? List of TDs of things?
Daniel: Back to slide 2, I'm wondering if there should be another category like list of TDs?
McCool: we'd like to be as simple as possible
… typically you get one URL
McCool: we should discuss about the well-known approach about this
Ben: What is the difference between direct and the other methods?
McCool: all provide a URL
Sebastian: How about RFID or QR-Code scan?
McCool: will also provide an URL
Toumura: we need implementations of the different approaches
… so far no implementation of the DID approach
McCool: What kind of implementation WebThing has?
Ben: we have implemented mDNS
<kaz> kaz: would confirm implementations by RIOT OS
Exploration Mechanism - Farshid
<FarshidT> Please refer to my last F2F presention for draft API design decisions: https://
<mjk> mDNS multicast DNS, and DNS-SD is Service Discovery using DNS (or mDNS)
Farshid: shows Figure 4 in discovery spec
… there two TD classes that are called directory description and link description
… link description uses the link approach with rel=describedBy
Lagally: Is the support TM?
McCool: not yet. A timing issue.
… maybe in the 2nd version
<citrullin> pb: We already implemented that in RIOT. The rt CoRE topic. Even though we haven't tested that yet @@@ (to be moved later)
McCool: for the Directory Description the consumer has to follow the links
<kaz> wot-discovery - 6. Exploration Mechanisms
Farshid: if there are fedorated DD then should be one DD
Ben: is it possible to have a public directory?
… how about local devices?
McCool: needs security consideration and needs clearify this in this spec. I will create a issue about this
Farshid: self description is new in the spec
<kaz> 6.1 Self-description
Farshid: is an exploration mechanism in which a Thing hosts its own TD
… TDs can be also provided in partial manner (e.g., for constrained devices)
<kaz> wot-discovery - Issue 132 - Peer-to-Peer Queries Endpoint in Producers
Farshid: there is also a way to query TD elements
sebastian: In profile discussion it would be good that a consumer can discovery TD with specific TD size
McCool: would be good to cover this. I will provide an issue
Philip: The range is only for HTTP. We want to cover other protocols in the future
<kaz> Range HTTP request header
<citrullin> FT: I cover this topic later in my presentation.
Farshid: shows the information model of the directory
<kaz> 6.2 Directory
Farshid: based on a TD https://
… shows the different operation like createTD, updateTD, deleteTD, etc
<McCool> (I created an issue about allowing HTTP in some cases: https://
<kaz> Farshid goes through Example 3
<kaz> 6.2.2.1.5 Listing from the preview of PR 130
Farshid: the last part of the dirctory section is Listing
https://
Farshid: shows an example with content-range
… there is also some news about validation
https://
<kaz> RFC7807 Problem Details for HTTP APIs
<kaz> wot-discovery issues related to Pagination
Ben: I like the approach of pagenation.
… there some discussion what are properties and what are actions
… shall we standardize the interaction names?
… like "createTDs" ...
McCool: recommend we should standardize the TD / TM.
<Zakim> dape, you wanted to 10-12 range seems wrong, should be probably 10-11 (for 12 items)
Ben: disadvantage with current approach is that may multiple interactions needed
McCool: this is right, that the current TD approach is quite long. Maybe we should point to a TM. Simpler TD for constrained devices would be good
Farshid: there are many optional definitions. You do not need to implement all
Lagally: you define status codes, are thos normative?
Farshid: Yes they are normative
Lagally: are we prepare to handle all of them?
Farshid: there are minimum required
Lagally: important for the profile discussion
<kaz> [note the example 3 within this the WoT Discovery spec is informative, the normative codes are defined by RFC7807]
Farshid: we have 40x and 50x codes so far
<kaz> sk: more protocol specific topics
<kaz> ... you have syntactic XPath there as well
McCool: we should have error codes in seperate section
<kaz> ... serialization format for TD is basically JSON-LD
sebastian: wondering about XPath, also working for JSON?
Farshid: its mainly syntactic search with XPath. JSONPath not standardized yet, XPath is just fallback
cris: question about pagenation. this approach should take into account different protocols. Also it might have impacts to the current design of the scripting api.
Farshid: there some discussion in a PR (https://
<kaz> kaz: having a separate section for error definition is fine, but we should be careful about how to deal with the error definition there because we'd like to import the definitions from RFC7807.
Philipp: I do not see big deal with CoAP. Im worried that your API may kind of complicated to other protocls then HTTP and CoAP.
McCool: currently concentration on HTTP
Zoltan: there is also discovery in scripting API which is not alligned with WoT discovery yet
… scripting is only phase 2 and filtering
<dape> scribenick. Dape
Andrea: [SLIDES] Syntactic discovery in directories
… could be semantic not only (syntactic)
… TD discovery answer: array of TDs
… JSONPath, mandatory
… not standard, but widely used
… e.g., ../jsonpath?query={query}
… XPATH, version 3.1
… supports JSON
… W3C standard
… e.g., ../xpath?query={query}
… XPath more complete than JSONPath
… Pros and Cons
… Pro
… - short and expressive
… - passed as URL
… Cons
… - TD fragments
… - complex queries
… - JSONPath not standard
McCool: JSONPath on path being an IETF standard
Andrea: ... - JSONPath may lead to security
… Conclusion: MUST JSONPAth, SHOULD XPath
Andrea: Semantic Discovery in Directories
… same idea, answer is JSON
… result is same
… SPARQL is optional
… SPARQL is W3C standard
… returns JSON-lD
… support for: SELECT; ASK; CONSTRUCT, and DESCRIBE
… *no* support for: UPDATE
… SPARQL query can be codified as URL
… for GET we need codified, for POST we send it in body (without codified)
… answer is JSON
… ASK used to query whether somethnig exists -> results in boolean
… DESCRIBE & CONSTRUCT returns JSON-LD
… DESCRIBE & CONSTRUCT have a problem... are JSON-LD frame documents
… SPARQL allows us to use query federation
… e.g., specify to forward it
… we need to know endpoints ahead of time
… JSON-LD frames -> translating -> JSON-LD/RDF
… back to JSON-LD frame is not possible. (needs framing rules)
… Pros and Cons for SPARQL
… Pros
… - expressive
… - query language with functions etc (W3C standard)
… - federated queries
… Cons
… - simple queries are more verbose tan JSONPath/XPath
… - consumes more resources
… Conclusion
… SPARQL is optional
… semantic discovery is very flexible
McCool: class-names are visible? And do not match names in spec... cleaning-up?
Andrea: Yes, if they do not match we should align
Sebastian: Compile SPARQL to URL? is there a limitation in size?
Andrea: I am not sure.
… SPARQL standard defines it
Farshid: No limit... but there is response code
Andrea: 100% aligned with SPARQL
Cristiano: Limitation on client-side also?
… e.g. browser can not handle any length
Cristiano: Which is the difference between what we have and SPARQL
Andrea: 1. there is no difference
… 2. the aspect is about framing
… RDF can be returned
… the problem is not SPARQL, we are adding something on top of the standard
Sebastian: Normalized TD. We need to define what we mean by that
… could be Turtle
… information is the same
… form is different
… TD task force topic
Andrea: I created issue w.r.t. that in TD repo
… normalized for me is RDF
… simpler form is (framed) JSON-LD
… problem: framed JSON-LD is not RDF
… we lack framing rules
McCool: API changes required with such a change?
… need framing document
Andrea: mime-type could be used
Cristiano: Could we standardize the process?
Andrea: worked on this translation
… did not find generic algorithmn
<acimmino> https://
Philipp: Url topic, can we stick do POST only?
… length/limits
Andrea: disocvery not mandatory to be used with browser?
McCool: Sometimes we need URL encoding
… suggest to keep it but put note about length
Andrea: user can choose
Lagally: Canonical representation
… we need to seperate the discussion
… look at it in profile spec
… just heads-up
McCool: normalized =!= canonical
… need to clarify what "validation" means.. e.g. SHACL
Andrea: SHACL should not be applied in queries
McCool: need error response (besides JSON validation)
Andrea: SHACL/SHAPE ... different with SAREF
… more ontologies.. more changes
<McCool> https://
McCool: --> 9 minute break -> 15 past
<kaz> rsagent, draft minutes
<kaz> r
Discovery issues
Framing and Pagination
McCool: We talked about framing and pagination already
… will update slides with links later
Signing and Canonicalization
McCool: Signing and Canonicalization
… signing to preserve TD integrity
… important for directory
… re-structere TD might break signing
… canonicalized JSON exists
… but it does not deal with default values in TDs
… need to clarify that
… we need canoncialization before signing
… conpect of "enriched TD", e.g., insertion time
… option to omit such data
Lagally: Canonicalization is very important
… preserve original TD
McCool: retain original String is fallback
… receiver needs to check/match signature
… chaining is fine if one trusts directory
… we should prototype Canonicalization
… and validate it
Lagally: is it that complicated?
… provide some rules like defaults
McCool: hard part: roundtripping through databases
Lagally: RDF representation with additional restrictions
McCool: signature on information ideally
Philipp: proxy topic: proxy between oneDM and TD. Assumption that consumer can validate both
Lagally: validate or trust
Philipp: oneDM bridge.. not able to consume TD?
Lagally: Why not?
Philipp: idea to *not* to understand the other protocol
McCool: form different but interactions the same. Sign parts of the TDs?
McCool: bottom line: Canonicalization is useful. Signing needs Canonicalization
… even JSON-LD has no stable solution
… JSON-LD proved got dropped
Farshid: trust directory? TLS usable
Ben: TD created by device serving via HTTPS
McCool: signing allows caching/forwarding
… do not need to trust all parties involved
Farshid: first draft could be limited to TLS
McCool: at the moment we do not have signing
… TLS over local HTTP does not work
… rely on wifi security .. is weak
… should we push for signing or defer to later spec?
Farshid: Definitely useful... but we could live with current version
McCool: Canonicalization should be in TD spec.. not in profile
Validation
McCool: Topic "Validation"
… directory needs to validate TD
… what does that mean
… JSON schema could be used, but JSON schema is not a standard
… proposal: use syntactic validation
… proposal2: semantic validation based on SHACL
… IF JSONschema becomes standard we can replace it
Lagally: baseline is syntactic validation, right?
McCool: Correct, syntactic validation required always
Ben: What does syntactic validation mean?
… what about extension?
McCool: JSON schema allows additionalProperties
… no strong validation
Ege: It only validates terms defined by TD spec
… e.g. validates "forms" but not "form"
McCool: I still hope JSON schema becomes standard
Lagally: Question: JSON schema not standard. Can't we reference the current state?
McCool: JSON path we refer to draft also
… problematic when coming to REC
Sebastian: I think we should not rely on JSON schema becoming a standard
… community accepts this kind of living standard
… JSON schema uses different versions like 0.7
… we can say we stick to *this* version
Lagally: Agree
McCool: same problem with JSONPath
<FarshidT_> There is also specification for validation with JSON Schema: https://
Ege: talked with JSON schema editor. No plan to become standard
Kaz: we should talk to PLH also
Security Bootstrapping
McCool: Topic "Security bootstrapping"
McCool: how to specify authentication for doing exploration
… self-description problem
… issue 135
… 3 options
… 1. default mechanism
… 2. protocol-specific negotation, eg. HTTP headers
… 3. two-phase approach
… TD does not provide this kind of security schema
… e.g. use top level security
Ben: use case webthing gateway, like reboot
McCool: how to authenticate is another key
… we can maybe discuss it offline
… private information to be used as fingerprint is a concern
Farshid: that's not mandatory
Ben: that's fine
McCool: directories may use nosec for the TD as it has no private information; maybe?
… any idea on the two-phase approach?
Ben: same idea as yours
(proposed in the issue 135)
<cris> +1
Farshid: you said that was protocol agnostic
McCool: let's also think about CoAP, etc.
… also bootstrapping for multiple TDs
… think error response is cleaner
tomorrow
McCool: Use Cases tomorrow on March 18
… summary list for the agenda would be helpful
Sebastian: will generate one
McCool: that's it for today
… thanks a lot for your talks, all!
… further issues to be captures on GitHub
[adjourned]