RDF Datasets Canonicalization and Hash WG Charter proposal

[iherman]

New charter proposal, reviewers please take note.

Charter Review

RDF Dataset Canonicalization and Hash Charter
(Previously named "Linked Data Signature")

What kind of charter is this? Check the relevant box / remove irrelevant branches.

• New WG
• New IG

No advance notice yet. See past charter issues, relevant strategy issue, recent mailing list discussion on the CCG (these are just the few recent references; the problem area goes back to several years).

Communities suggested for outreach:

• Credential Community Group mailing list
• RDF-DEV Community Group with the old SW IG mailing list

The CCG has played an essential role in the development of the documents leading to the charter. They will have to be notified asap. The plan is to issue an AC advance notice and also contact the Semantic Web mailing list in about a week.

Known or potential areas of concern

nothing particular

Where would charter proponents like to see issues raised?

• Charter repository issue list: https://github.com/w3c/lds-wg-charter/issues

Anything else we should think about as we review?

nothing particular

---

Cc: @msporny @pchampin

[michael-n-cooper]

No comments from APA. Over to @brewerj to complete accessibility horizontal review.

[himorin]

No comment/request from i18n.

[iherman]

@brewerj @samuelweiler any news on the horizontal reviews?

[samuelweiler]

When I think of canonicalization for signing, a key property of the canonicalized form is that there is a single such form - the function always gives the same result. When I look at the charter explainer, that property isn't clear. Am I just not understanding those words? Should that language be a little clearer?

It's good that defining algorithms is out of scope, but my experience is that the use of an algorithm requires a few words of explanation, much as https://w3c-ccg.github.io/security-vocab/#Ed25519VerificationKey2018 and https://tools.ietf.org/html/rfc8080#section-3 show "here's how we format the key". Typically I want those definitions to be in their own documents, so it's (relatively) easy to add new ones. (I also want them to be more well-defined than I see in https://w3c-ccg.github.io/security-vocab/) Which brings us to:

Registries. I haven't been following the recent Process changes around registries, but it looks like Linked Data Security Vocabulary (LDSV) is, in fact, a registry. Only it's a registry that contains the above explanation (albeit only by example). I think it might be better to create a registry - including specifying update criteria - and then create docs that populate initial values. In the IETF, it's possible to do both at once, creating the registry in the same doc that defines initial values (see the later paragraphs of https://tools.ietf.org/html/rfc5155#section-11: "This document creates a new IANA registry...")
I don't know that w3c's registry stuff will look like. Perhaps we should say, as a work/scope item: the WG will create a registry and populate initial values, without being clear what that document is going to be? @plehegar ?

It seems like the Linked Data Security (LDS) spec should instead be titled Linked Data Signatures (or signing). Please change the name or explain the choice.

I'm going to ask some colleagues who have more experience with canonicalization and signing to look at this charter, also.

Process/template thing: please adopt the "separate sections" text from the current charter template: https://w3c.github.io/charter-drafts/charter-template.html#success-criteria

[iherman]

Process/template thing: please adopt the "separate sections" text from the current charter template: https://w3c.github.io/charter-drafts/charter-template.html#success-criteria

Done.

[brewerj]

@iherman thanks, we're all set for accessibility.
@michael-n-cooper , can you please flip the apa horizontal review repo to match the "completed" label I just set -- thx

[iherman]

@iherman thanks, we're all set for accessibility.
@michael-n-cooper , can you please flip the apa horizontal review repo to match the "completed" label I just set -- thx

thanks @brewerj and @michael-n-cooper

[iherman]

For the records, the issues listed in #262 (comment) are now discussed in the LDS repository. In particular:

• Issue "Is Canonicalization single", Is canonicalization single? rch-wg-charter#45
• Issue "Linked Data Vocabulary as a registry" Linked Data Vocabulary as registry rch-wg-charter#46
• Issue "Linked Data Signature or Linked Data Security" Linked Data Signature or Linked Data Security? rch-wg-charter#47
• PR "Updated the deliverable section of the charter" Updated the deliverable section of the charter rch-wg-charter#56, which is a joined PR proposing an answer to Linked Data Vocabulary as registry rch-wg-charter#46 and Linked Data Signature or Linked Data Security? rch-wg-charter#47

Also, as a separate discussion, triggered by some off-the records discussion led to

• Issue "Change of terminology Canonicalization -> Canonical Labeling Change of terminology "Canonicalization" -> "Canonical Labelling"? rch-wg-charter#52
• PR "Added some text on the terminology" Added some text on the terminology rch-wg-charter#54 which was merged and closed Change of terminology "Canonicalization" -> "Canonical Labelling"? rch-wg-charter#52

[mmccool]

Note that Web of Things (WoT) is 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. 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. Hopefully we can get at least partially aligned with your direction and intercept it with WoT TD 2.0. There are also some special concerns arising from TD peculiarities (such as the use of default values and named definitions). Regardless, I think the goal of having a way to canonicalize and sign JSON-LD is important.

[pchampin]

Follow up on this issue (from this email to the semweb mailing list):

1. Instead of a Linked Data Signature WG we would propose a different Working Group, tentatively called RDF Dataset Canonicalization and Hash (RCH) Working Group, whose charter would be restricted to the RDF Dataset Canonicalization and the RDF Dataset Hash deliverables of [1]. We felt that those two deliverables meet the need of the RDF community and were not particularly controversial in terms of goal and rough technical approach.

2. As a coincidence, the charter[5] of the Verifiable Credentials Working Group[6] runs out at the end of this year and will need rechartering. Furthermore, the current thinking in that Working Group is that the new charter would have to be more than a simple "maintenance" Working Group, i.e., it would work on the next version of Verifiable Credentials Data Model specification. The plan is, therefore, to create another deliverable as part of that new charter, tentatively called "Verifiable Credential Linked Data Integrity", that would follow the lines of work in the (proposed) LDI and LDSV deliverables of [1], but restricted in scope to the needs and nature of Verifiable Credentials. Obviously, those deliverables would rely on the technologies developed in the RCH Working Group.

[1] https://raw.githack.com/w3c/lds-wg-charter/f976d487102ef4c31251e5d2a946ac771e60277d/index.html
[5] https://www.w3.org/2020/12/verifiable-credentials-wg-charter.html