Meeting minutes
introduction to WoT
<kaz> Slides: @@@
<ege showing slides>
ege: I want to introduce the discovery specificiation because is in the interest of JSON-LD group
… you can discover Thing Description using DID
Questions from Ege
Signing and Canonicalization
ege: we worked on Canonicalization and Signing but it didn't make to the final spec
<Ege shows an example of the previous work>
Signing and Canonicalization
mahda: with signing we can prove that a TD has not been changed
… plus we can share a part of a TD instead of the whole file
mahda: if we can sign a TD what about linked resources?
… we identified a couple of mechanisms
… hash link
… ipfs
… also which signature scheme is appropriate for TDs?
manu: thank you for having us here
… we have good answers
Selective Disclosure
manu: is there a selective Disclosure in JSON-LD ? yes, we have but it is fairly new.
<manu> https://
manu: check the link above
… another mechanism is to issue multiple versions
<Zakim> manu, you wanted to speak to some of these questions
ege: with TD we always said that there is one version live, multiple versions is complex
… what is the right approach?
manu: selective disclosure is inherently more complex.
… if you are dealing with regular size computing machines is not an issue
… but of course with IoT devices is different
<manu> Selective Disclosure for Data Integrity: https://
manu: the is a slide deck (linked above)
ege: in the TDD you can answer with part of the TD
… it is relevant in this use case too
manu: yeah
… there is some work in IETF, SDJWT
luca: the part there is interesting is the trust model
… also another part is what parts of a TD you can share (confidentiality)
… on way to handle this is to present the TD in different ways depending who is accessing it
… everything dynamic should be a property
… and there you can have once again different auth technologies
… for greenfield we can choose state of the art techs
Integrity of Linked Data
manu: we dealt with this in the Verifiable Credentials WG
… two approaches:
… digest
… the downside is that if the remote resource allows different mediatypes you need a way to discrbie digest for multiple content-type
… all of this fairly new
… second approach is related resources
… in property related resources you add that link information and the digest
… are you interesting in something that it is in the TD and links to something external right?
<kaz> Example 28: Link to developer documentation from WoT Thing Description 1.1
<ege shows an example>
manu: with something like TD links you would probably add the digest property
<Zakim> dape, you wanted to default TD values: present vs not present, e.g., contentType
dape: About canonicalization process, in the TD we have the default values. How to deal with this mechanism for signing?
manu: there are two ways: it depends on **when** you apply the default values
… if you do it before signing
… it requires a pre-processing
… the other approach is just not signing them at all
dape: what is the best way then?
manu: you have to think the about the attack model to understand which one is the best
seb: we also the security requirements that applies to affordances, we can also apply it to links
phchampin: on signing there are three levels in RDF. Concret syntaxes, the graph model, and the semantics.
… it seems that what we are looking for is a semantic signing, which is challenging
… gut feeling is to go with option 2
… and +1 for analyzing the threat model.
signature schemes
manu: sharing links:
<manu> https://
manu: vc data integrity, support multiple caninocalization schemes
<manu> https://
<manu> https://
manu: there are two cryptographic schemes
… linked above
… both would work
… if you are interesting for signature working in YAML too
<cris_> s/intersting/interested/
manu: we can go with eddsa
manu: bbs provides unlinkability, but is experimental
seb: do you have a feeling on when are going to go public?
manu: in two days
Actors in VC
mahda: what is this verified data registry in the context of the Web of Things?
manu: are you going to issue VCs? or just TDs?
mahda: maybe also VCs
manu: data integrity is not really connected with VC
… you can put a TD inside a VC
… trust lists can be used to identify who is allowed to issue TDs in a specific system
… the system deployment is having a list of trusted URLs
<quick round of self introduction>
Degraded Consumption
<kaz> Slide @@2
luca: What is consumption in WoT?
… the act of digesting this description in order to do something is called consumption.
<luca presents the slides>
luca: we have structural parts -> important parts that you need in order to interact with a Thing
… and auxillary information
… in our spec we allow json only consumers
… those parsers cannot deal with context information as JSON-LD processors
… how much of JSON-LD I can compress to deal with json only docs
… how to get around this?
… fixed context
… keep the vocabulary terms as they are
pchampin: JSON-LD validation, what do you mean?
luca: in JSON-LD you can validate the vocabulary terms in relationship to the context files
pchapin: types in the context are not used for validation
… they are used for translation
manu: there is a way to process JSON-LD in a degraded fashion, there is a section in VC about it
… JSON-LD is built to be used only when needed
… in the VC data model, we have processors that do not do the JSON-LD processing
… we are using well-know context urls
… also we ask to freeze the context and cryptographically sign it
<kaz> Verifiable Credentials Data Model v2.0
manu: there is a slimmer profile of json-ld to do just json only processor
seb: background on the whys we allow JSON only parsing
… in IoT world we have constraints
… JSON is known to work in that context
… we had push backs for developers
… syntax lite parsing and validating might be possible
luca: we need to explain all of this in the specification
… otherwise implementers would get this wrong.
… for example if there is a json-ld profile that helps we need to link it
manu: conflict between JSON and JSON-LD is common
… not using prefixes, should help
… also JSON guys not link ":"
cris: is going to be hard due to linking bindings
seb: we can use form level context
<Ege shows examples>
<kaz> Example 50
manu: we also remove : and call terms in camel case. Like cov:methodName -> covMethodName
cris: why we should also fix the order of the contexts?
manu: is important to avoid redifinition and security attacks.
… do not let redefine terms of the standard.
pchampin: JSON schema and JSON-LD offer different purposes
… we are going to discuss these points in the breakout session
<Ege> related breakout session w3c/
luca: our implementation experience as long as the prefix are fixed that is good.
… the changing of the prefix is problematic
ege: ty for preparing the discussion
Other serialization formats
<kaz> Slides: @@3
ege: TD is a information model
… currently we just support JSON and JSON-LD
… having more format is good
… YAML-LD allows comments
… CBoR-LD have some benefits
… there is existing work on this
… YAML-LD is part of the JSON-LD
… what is the current state of these special formats?
gkellogg: json-ld wg is working consistently on the YAML-LD
… we are planning to create a CG by the end of the year
… json is a subside of YAML
… cbor should benefit of the same intermediate form
manu: CBOR-LD has been deployed to prod system
… however, the spec is in not in its best shape
… we are focusing on other points
… you can go from any signed JSON-LD and go to CBOR-LD or YAML-LD pretty easily
… the spec is open for contributions
<Zakim> manu, you wanted to speak to CBOR-LD timeline (and were it's deployed), how to canonicalize?
Ege: do you see difference in adoption between JSON-LD and YAML-LD
manu: small percentage
gkellog: People like YAML, the model is similar to JSON
Linting
ege: lately there have been an emergence of tool to validate Open API
… or other descriptions
… how can we do for the TD?
… are there any mechanism within json-ld? did you ever discuss about linting JSON-LD documents?
gkellogg: from the spec perspective the best way is to look at SHACL
… it is powerful
… there are tools that compare a graph to the idial end result.
manu: +1 to greg
<Zakim> manu, you wanted to mention safe mode, linting, etc. and to also mention JSON Schema
manu: couple of things: json-ld processor have safe mode
… safe mode stops if finds something that is undefined.
<gkellogg> It will also generate an error if an attempt to redefine a protected term is detected.
manu: aside from that the other well-know tool for linting is json schema
… but the object needs to be a definitive shape.
… btw jsonld playground there are warnings
… we want to add other things
… like a warning for the default vocabulary
… linting is tending to be application specific
… but let us know if you find something that is generic
ege: from the standardization pov
… we should find a way to define those rules
… in a common way
manu: in VC we use a property to define a schema for that
… field