Hi @gkellogg @dlongley @yamdan @philarcher @peacekeeper

We (@hadleybeeman and I) reviewed this in our virtual face-to-face this week. We like the direction of the work, and the design is sensible.

We noticed you haven't yet filled out the privacy and security questionnaire. Understanding that not all of the questions may be relevant, please could you do this?

Also, we see that you are using quads instead of triples and adding in the graph name once? It sounds more complex — but we suspect you have considered this at length. We are just interested in your thought process here. (This is the sort of thing we normally expect to see in an explainer.)

Also, we'd love to see the explainer when you've updated your explainer to bring it in line with the spec.

And finally, what happens if the hashing algorithm becomes insecure? It might be helpful to put a comment in the security considerations section to advise implementers in the future to consider that possibility.

Thanks @rhiaro, we'll need to take this up in the WG.

As for the use of quads vs. triples, note that this a spec for datasets, not just graphs, so the graph name component is necessary for recording this information. Use cases including Verifiable Credentials depend on the use of datasets, and not just graphs, so canonicalizing the entire dataset is important. Algorithmically, including the graph name as a potential location for a blank node in addition to the subject and object positions has a fairly minor impact.

Although RDF Concepts suggests an interpretation of a set of graphs, all but one of which can have a graph name, it is fully consistent with the N-Quads representation which is convenient for the algorithm. A hypothetical variation might have created a hash for each graph and then hash the graph name/graph hash pairs, but it remains necessary to consider that blank nodes may appear across graphs, and indeed as the graph name, so it doesn't really change the need to consider blank nodes across the dataset and not just within each graph.

Good point about noting the implications on the algorithm for some potential future vulnerability. Note that there is text to indicate that the algorithm can be use with different hashing algorithms with minimal change

NOTE Implementations can be written to parameterize the hash algorithm without any other changes. However, using a different hash algorithm is expected to generate different output from RDFC-1.0.

However, the security issues that might motivate this can be better highlighted.

@rhiaro, @hadleybeeman We have added text related to potential for hash algorithms to be shown to be insecure Markus's addition above can be seen as a short section at https://www.w3.org/TR/rdf-canon/#insecure-hash-algorithms). A further addition concerning use of alternative has mechanisms is in preparation (https://github.com/w3c/rdf-canon/pull/161).

Meanwhile, we have been through the P&S questionnaire and offer the following responses.

As an overall comment, RDF Dataset Canonicalization takes an RDF dataset as input and returns a different form of the same dataset as output (unless the input is already canonicalized - the process is idempotent). The questionnaire is well-suited to highlighting potential security and privacy issues with Web applications running in browsers. As our specification only specifies an algorithm for handling data, many of the questions don’t apply to our work.

Implementations may interact with the Web, of course, but such interactions are not specified in the document and are therefore out of scope. That said, the privacy and security considerations sections of the document highlight issues of which any implementation should be aware.

2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

The document defines an algorithm that canonicalizes an RDF dataset. It does not introduce or remove any information from the dataset, and does not expose any new information.

2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes. The specification defines an algorithm that canonicalizes whatever data is given. The output from the algorithm includes canonicalized identifiers for blank nodes that are produced from the input. New information that wasn’t in the dataset being processed isn’t introduced.

2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

The algorithm canonicalizes any data given to it. Decisions on handling personally identifiable information are up to the application. Therefore these issues, while obviously important, are out of scope for the draft standard.

2.4 How do the features in your specification deal with sensitive information?

See previous answer. Data is only used internally within the application. How any sensitive data is handled is up to the implementation.

2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions?

No.

2.6 Do the features in your specification expose information about the underlying platform to origins?

No.

2.7 Does this specification allow an origin to send data to the underlying platform?

No.

2.8 Do features in this specification enable access to device sensors?

No.

2.9 Do features in this specification enable new script execution/loading mechanisms?

No.

2.10 Do features in this specification allow an origin to access other devices?

No.

2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI?

No.

2.12 What temporary identifiers do the features in this specification create or expose to the web?

None. While the specification defines an algorithm that transforms identifiers, the algorithm itself does not expose these to the web. It is up to the application that uses the algorithm to decide whether or how to expose any output from the algorithm.

2.13 How does this specification distinguish between behavior in first-party and third-party contexts?

It does not. The specification defines a canonicalization algorithm that internally rearranges input data to output data. It is up to the application to feed data into the algorithm and use whatever its outputs are.

2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

This is out of scope. The specification defines an algorithm that can be run in whatever context the application decides to run it in and the algorithm only rearranges input data into a canonical form. Whether the application runs in a browser at all is not defined by this spec.

2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

Yes. Privacy considerations. Security considerations.

2.16 Do features in your specification enable origins to downgrade default security protections?

No.

2.17 How does your feature handle non-"fully active" documents?

It does not, this is out of scope for a canonicalization algorithm. The canonicalization algorithm works on RDF datasets which are unrelated to non-”fully active” documents.

2.18 What should this questionnaire have asked?

As noted in the preamble, the questionnaire focuses on browsers/Web apps. It does not target the needs of data representation formats, so it is not particularly useful for a whole category of specifications. This might be useful feedback for the privacy group in the long term to add questions to cover more specifications.

So sorry for the delay in closing this, we thought we already had! We're happy to see this go forward, and thanks for your detailed responses to our questions.