W3C Web of Things (WoT) WG supports the W3C LDS WG

[mmccool]

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):

• Add integrity protection (proof section) to TDs wot-security#166
• Canonical Representation / Signing requirements wot-profile#55
• Add optional proof section to TDs  wot-thing-description#940 (has most detailed requirements)

[mmccool]

We discussed this in our main call on May 12 and agreed that

• We wish to strongly support the formation and goals of this group
• We probably need to proceed in the short term with our own canonicalization and signature approach for TDs
• We need input and advice from the LDS to align the TD canonicalization/signature as closely as possible with the (expected) form of the LDS based on current drafts (eg LD-PROOFS)
• We need a plan to align future revisions of the TD spec with the final form of the LDS specification, while minimizing disruption to early adopters of TD1.1, and generally need to closely collaborate

[iherman]

@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?

[mmccool]

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" ;)

[mmccool]

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.

[iherman]

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.

[mmccool]

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 w3c/wot-thing-description#1151. In the long run, I can see systems using either these signatures (based on JSON) or the LDS (based on RDF).

[pchampin]

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

• renew your expression of interest (by a simple reply to this thread), or
• to close this issue if you do not wish to renew it.

Thanks in advance

[pchampin]

up?