CR Request for RDF Dataset Canonicalization

[pchampin]

Document title, URLs, estimated publication date

Title: RDF Dataset Canonicalization - A Standard RDF Dataset Canonicalization Algorithm URL: https://w3c.github.io/rdf-canon/publication-snapshots/CR/Overview.html Estimated publication date: 2023-10-13

Abstract

https://w3c.github.io/rdf-canon/publication-snapshots/CR/Overview.html#abstract

Status

https://w3c.github.io/rdf-canon/publication-snapshots/CR/Overview.html#sotd

Link to group's decision to request transition

https://www.w3.org/2023/09/11-rch-minutes.html#r04

Changes

https://w3c.github.io/rdf-canon/publication-snapshots/CR/Overview.html#changes-from-fpwd

Requirements satisfied

yes

Dependencies met (or not)

none

Wide Review

https://github.com/w3c/rdf-canon/issues?q=label%3AHorizontalReview+

Issues addressed

https://github.com/w3c/rdf-canon/issues

Formal Objections

None

Implementation

https://w3c.github.io/rdf-canon/reports/

Patent disclosures

https://www.w3.org/groups/wg/rch/ipr/

[plehegar]

Horizontal review requests:

• a11y, closed on Jun 21
• TAG, proposed to be closed last month
• i18n, closed on Mar 27
• Privacy, not closed
• Security, not closed

[plehegar]

• Diff since March 15
• Diff since June 9
• Horizontal review board

[plehegar]

• normative references

[[ The token EOL MUST be a single LF (line feed, code point U+000A). ]]

references a document that does not exist. I'm sure you can find a better document to reference the definition of the EOL character...

[plehegar]

Did the groups listed in the coordination section of the charter got a chance to review the document. If not, feel to explain.

[pchampin]

references a document that does not exist. I'm sure you can find a better document to reference the definition of the EOL character...

Yep, I noticed that one when I made the transition request, and proposed a PR for this: https://github.com/w3c/rdf-canon/pull/179 . As this is non controversial, I went on with the request regardless.

[plehegar]

The document MUST document how adequate implementation experience will be demonstrated (also known as CR exit criteria). I see that the charter lists some as an example but the document must have them.

[plehegar]

Two 2 things to fix:

• reviews from non-horizontal groups
• document must contain the CR exit criteria

[philarcher]

Exit criteria added to status of the doc.

On the liaisons we offer the following:

Verifiable Credentials Working Group To synchronize the definition and usage of the RDF Dataset Canonicalization and Hash, both needed for the ability to provide proofs for Verifiable Credentials.

→ ensured by a significant intersection between the two groups

Dataset Exchange Working Group To synchronize on the needs and requirements of dataset publications and exchange regarding canonicalization.

→ ensures via common team contact; the DCAT-3 references RCH

Web Application Security Working Group To ensure that the canonicalization and hashing mechanisms defined in this group have similar security properties to the rest of the Web, and to take advantage of lessons learned while designing other canonicalization systems.

→ People like Tim Capelli and Pam Dingle, who is head of MSFT identity, are in that W3C group, along with Chaals, Tess and Mike Prorock and they certainly know about RCH/Data Integrity -- there's overlap. There is further overlap between the two groups although they aren't regular attenders. Jeffrey Yaskin is very familiar with this work and has taken a significant look at it. The WG hasn't taken a position, a number have looked at Data Integrity and done review, not really reviewing RDFC but are aware of it.

Web of Things Working Group To synchronize on the needs and requirements of the WoT community, in particular on the subject of WoT Thing Descriptions, regarding canonicalization.

→ joint session during TPAC 2023

Credentials Community Group Coordination on other specifications incubated and maintained the Credentials Community Group at W3C.

→ ensured by a significant intersection between the two groups

RDF-DEV Community Group To synchronize on the further evolution of the RDF Standard, such as canonicalization and hash functions for Generalized or RDF-star Graphs and Datasets.

→ This became the RDF-Star WG of course. There is significant intersection between the two groups. There was direct liaison over the issue of canonicalization of literals, e.g. issue 15. The existing N-Triples spec includes a canonicalization format for literals but not N-Quads. This is being added by the RDF-Star WG but for now we include a section in our spec to cover it.

Internet Engineering Task Force Crypto Forum Research Group To perform broad horizontal reviews on the output of the Working Group and to ensure that new pairing-based and post-quantum cryptographic algorithms and parameters can be integrated into the RDF Dataset Hash ecosystem.

And

Decentralized Identity Foundation Interoperability Working Group To coordinate on broad horizontal review and integration of the specifications developed by the Working Group into the Decentralized Identity Foundation's ecosystem.

→ Greg Bernstein, who has been using RCH, is involved in BBS at IETF through CFRG and also involved with DIF with BBS there. Brent Shambaugh is a part of W3C CCG. So we know there is good knowledge of the RCH work in both groups.

Hyperledger Aries To coordinate on broad horizontal reviews and implementations related to the specifications developed by the Working Group.

→ Manu often speaks to Stephen Curran from British Columbia about Aries. They use CL (Camenisch-Lysyanskaya) crypto. They are doing Data Integrity but probably not RCH.

Additionally The RCH WG will contact each of the listed groups to seek implementation experience during the CR phase.

[plehegar]

Thanks for the success criteria and the report on coordination with other groups (and the fix for the EOL token) .

Approved.

[pchampin]

published on 2023-10-31 https://www.w3.org/TR/2023/CR-rdf-canon-20231031/