Open mmccool opened 3 years ago
We discussed this in our main call on May 12 and agreed that
@mmccool are there any extra statements you want to add to the liaison text that we have put into the charter for the WoT WG?
The liaison text is fine, and thank you for including it. I will double-check with our WG members, though.
I think we probably have more feedback on other deliverables, in particular, we definitely want to see signatures supported in JSON-LD, and be computable without having to pull the JSON-LD into an RDF database (e.g. computable using only a JSON processor). I know the focus here is on RDF but this requirement arises from the need to validate signatures on smaller devices.
The links above have a number of other requirements but I don't think that one was explicitly stated; too "obvious" ;)
I also found the LD-PROOFs draft to be fairly open-ended with support for many kinds of proofs and encryption suites. I expect that for WoT we will probably want to extract a narrower, finite set to make sure that finite testable implementations are possible.
I think we probably have more feedback on other deliverables, in particular, we definitely want to see signatures supported in JSON-LD, and be computable without having to pull the JSON-LD into an RDF database
TL;DR: this should not be a problem.
Longer: the signatures will be defined on RDF Datasets in general, independently of a particular serialization. Expressing them in JSON-LD, which is, after all, a serialization of RDF Datasets, is therefore clearly in scope. Furthermore, the charter explicitly refers to a proposed JSON-LD @context
that can be used by applications.
Not sure the "be computable without having to pull the JSON-LD into an RDF database" part is correct, however, since it seems the proposed LDS canonical form is a sorted set of RDF n-tuples (which obviously requires RDF processing). In the meantime we are proceeding with a definition of an XML Signature/JWS-based approach, with a canonical JSON form using our own set of rules and JCS; see https://github.com/w3c/wot-thing-description/pull/1151. In the long run, I can see systems using either these signatures (based on JSON) or the LDS (based on RDF).
Dear @mmccool, the proposed charter has been substantially changed since you submitted your expression of support. More specifically, its scoped has been narrowed down, to address some concerns raised in the Semantic Web community. See also Ivan Herman's explanation of those changes on the SebWeb mailing list.
We kindly ask you to review the new version, and either
Thanks in advance
up?
Web of Things (WoT) has also working on a canonical form (and signature mechanism) for WoT Thing Descriptions. The canonical form is reasonably stable at this point; see https://w3c.github.io/wot-thing-description/#canonicalization-serialization-json. However we are still working on a signature mechanism (and debating whether or not it would be better to wait).
We were hoping to be able to base this on a standard JSON-LD canonicalization and signature mechanism, but the timing was not working out. TD 1.1 is in flight and the plan is to complete it before the end of the year, too soon to adopt LDS. However, hopefully we can get at least partially aligned with LDS and intercept it with WoT TD 2.0. Even then the LDS and next-gen WoT specs (assuming the WoT charter is renewed for updates) would have similar timelines, so we can't wait for LDS to be complete first and then adopt it in WoT. Instead we will have to collaborate and align while developing parallel drafts. There are also some special concerns arising from TD peculiarities, for example, dealing with default values in TDs. Regardless, the goal of having a way to canonicalize and sign JSON-LD and TDs is important for integrity and authentication purposes.
See our discussion of this in the following issues (which have also gathered our requirements):