-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RDF Datasets Canonicalization and Hash WG Charter proposal #262
Comments
No comments from APA. Over to @brewerj to complete accessibility horizontal review. |
No comment/request from i18n. |
@brewerj @samuelweiler any news on the horizontal reviews? |
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...") 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 |
Done. |
@iherman thanks, we're all set for accessibility. |
thanks @brewerj and @michael-n-cooper |
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. |
Follow up on this issue (from this email to the semweb mailing list):
[1] https://raw.githack.com/w3c/lds-wg-charter/f976d487102ef4c31251e5d2a946ac771e60277d/index.html |
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.
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:
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?
Anything else we should think about as we review?
nothing particular
Cc: @msporny @pchampin
The text was updated successfully, but these errors were encountered: