Meeting minutes
<markus_sabadello> gkellogg: Work is advancing in RDF* WG, issue activity and some work on getting Editors drafts of those specs in shape
<markus_sabadello> gkellogg: Started on some of the work on canonicalization, we just need definitions for quads
<markus_sabadello> phila: gkellogg is there anything in RDF* that we here need to pay attention to?
<markus_sabadello> gkellogg: Activity has been on semantics.. Some background activity about the mechanical bits
<markus_sabadello> gkellogg: Some things still need to be done before FPWD, hopefully in February
<Zakim> pchampin, you wanted to react to phila
pchampin: The blocking point right now is assigning editors, which is in progress now.
… Once we have editors, I don't see an obstacle on having FPWD.
<Zakim> manu, you wanted to note some items happening in other WGs. and to also mention Gordian Envelope and ACDC work.
<manu> Demonstration of Support for EdDSA Cryptosuite Adoption into VCWG: https://
manu: One of the first crypto suites is up for a WG adoption call today.
… We've gotten signatures from a variety of implementers.
… We have a list of 16 implementors who have implemented the EDD crypto suite.
… there's a vote today on adopting the suite. We've passed three of four hurdles.
… Having interoperable implementations isn't a guarantee that the WG will accept it.
… Please mail into the VCWG mailing list to support it, if you're a member.
… The call today is challenging for people in Europe or asia to make.
<manu> Alternatives to RDF*: https://
<aidhog> Gordian Envelopes
manu: There are some alternatives to RDF-star. One called Gordian Envelopes.
… It's a new graph structure that allows you to do interesting things.
… There's been some "crankiness" to RDF in parts of the group.
<TallTed> Nested containers. Graphs all the way down.
manu: THese other systems are rooted in the cryptographic community, rather than RDF.
markus_sabadello: What we're doing here is fundamental to support the VCWG work.
Horizontal review process
markus_sabadello: This is a part of the W3C process, and phila has created a number of issues on this.
phila: I made some issues for us to track progress. Accessibility and Internationalization are the "easy" ones.
… I don't think for these there's much to say, but it needs to be done.
… There are potentially issues for text strings in triples for internationalization.
<manu> Phil is correct, I don't think we considered I18N canonicalization rules on text...
phila: But, these come up in the RDF specs anyway.
… For Privacy and Security, we need text in the document to be reviewed.
… I'd ask for that to be pushed up the priority order.
<Zakim> manu, you wanted to reach out to IETF CFRG?
manu: We didn't consider i18n specific c14n of strings.
… It would be a good idea to reach out to the crypto forum research group and IETF and ask for a form or something.
… That could backfire, as there may be some lack of sympathy for the c14n approach.
… If we go to the TAG, they'll ask if we had any external review.
… Of course, we have our own people in the group, but they may want some external review.
gkellogg: I don't have anything to contribute to privacy and security, so looking for support.
phila: perhaps Kazue or yamdan have something to contribute here?
… Should I write to the CFRG group? I don't know anyone there myself.
<Zakim> manu, you wanted to offer /some/ text -- which we know about... and ask Chairs to reach out to IETF CFRG.
manu: On the S&C considerations, we have at least two sections to add there.
… One around BBS signatures and why HMAC.
… We should also point to the published mathematical proof, as well as Aiden's work to indicate that there has been mathematical review.
… WRT contacting CFRG, probably best if the chairs reach out rather than some other member.
… Wendy S used to be the link, but that has changed ...
ACTION: phila to reach out to CFRG
yamdan: As for S&P section, I can also contribute something from the viewpoint of the user of the C14N algorithm.
<manu> ooh, poison graphs is another good addition to security section!
yamdan: As for security, my understanding of C14N is not enough to contribute. Particularly for "poison graph" attacks. This requires some deep knowledge and specific types of "bad" graphs.
… iherman had already referenced some papers, which is important for the section.
markus_sabadello: I'm sure you and kazue have deep knowledge on the privay aspects, so that would be very valuable.
phila: for the process, getting these sections complete are really important.
markus_sabadello: We were just talking about security and poison graphs, which leads into the next topic.
Comparison and confidence in algorithms, with invited guest Aidan Hogan
<yamdan> "academic paper about poison graphs" I mentioned is https://
markus_sabadello: As a reminder, we discussed the two algorithms at the kick-off if this group.
… We had presentations from both dlongley and aidhog.
… We've begun work on dlongley's algorithm, but we've had open issues on comparing the algorithms.
… Aiden commented on #6 and #10 already.
aidhog: WRT #10, there's a great list of comparison points.
… We know that both algorithms are similar, and Ivan has implemented both.
… It's not clear to me which is more efficient, and what does "common dataset" mean.
… The only way to determine this would be to select some representative datasets and run against each algorithm.
… We know the poison datasets are something to work out.
… Both algorithms have had mathematical proofs, and I think the one done on dlongley's was particularly good.
… Of course, they stoped short of saying that "we're certain this is correct"
… Also, Dave's addresses dataset and not graphs.
… I'd suggest that RDF-star use cases be reified into RDF datasets and canonicalize that rather than trying to extend the algorithms.
… On correctness: I'm certain that it's possible to define an algorithm that handles these.
… I'm highly confident that both algorithms work correctly.
… But, it depends on the risk/benefit analysis in case something goes wrong.
… What is sufficient due diligence before we can go forward.
… For example, there is a graph isomorphism algorithm that was widely thought to be correct, before it was found not to be.
… But, I think it's highly likely that both algorithms are fine.
… I don't think you can say that just because algorithms have peer review that they're necessarily correct.
… To convince people, we should probably avoid people and look at a proof verification system.
… That would be the ultimate of due diligence. But, this would be a slow and difficult process.
… On poison graphs, there will always be some that take a long time barring some quantum breakthrough.
markus_sabadello: Thanks, this is really helpful. Not all of us have such deep technical knowledge.
<Zakim> manu, you wanted to comment on time/resource complexity has come up in other groups as well. and to note "backup c14n algorithm"
manu: I agree with everything Aiden says.
… On the time/resource complexity question, this has come up in other groups.
… For example, people are complaining that RDF C14N is slow.
… We do have a benchmark which shows just the opposite. RDF C14N is 100's to 1000's of times faster than JSON Schema, for example.
… There's quite a lot of misrepresentation on how slow or fast these algorithms are.
… We do have a benchmark sure (from 5 years ago).
… We have other datasets that are either going into production are are already there. But people may still claim that it's not representative of their datasets.
… +1 for finding time to do benchmarking for the algorithms.
… Regarding formal verification: +1 to what Aiden said.
… We should try to find someone or some group to do a formal proof, because there will always be nay-sayers.
… Finding the people with the expertise and time to do this will be challenging.
… In parallel, we can look at alternative schemas such as JCS (JSON C14N).
… This might be easier to prove, but could be a backup scheme.
… If our C14N scheme fails, we should have a backup.
… You would loose all kinds of features (selective disclosure, etc.)
… We could suggest that if rdf-canon fails, the fallback is a non-RDF C14N scheme (JCS or straight hashing of JSON-LD)
<manu> oh, AND, we could make aiden's alg the backup (which is what I meant to lead with)! :)
<aidhog> Coq
pchampin: I happen to be in contact with a group of people that know Coq.
… I can reach out to them and know if they might be interested in working on this.
<TallTed> see http://
aidhog: I think it would be great to have a benchmark.
<manu> Here's the current benchmark DB has: https://
aidhog: I think Ted mentioned some datasets to consider.
… In the case of my algorithm, it runs in memory, which is a MUST.
… Most RDF graphs are not anything like graphs you see in isomorphism problems.
… There are graphs that will run in milliseconds, and others that will never complete.
… Manu asked about a backup, but there's a question about damage done if the original one fails.
… It would have an effect on the trust of the group, if not the W3C.
… I don't think it's necessary to be super formal, but if the damage done by failing would be critical, we should look further.
… I'm not sure this is all compatible with the timeframe of the group.
<Zakim> manu, you wanted to note "cost and damage" of initial failing... it's "bad"... very bad. :P
manu: It would be very, very bad if it was shown to be a problem after deployment.
… It's being used for things like personal identification by government agencies.
… That would be Trillions of dollars of trade documents.
… We should do what we can, but the timeline question is key.
… Having a backup we can switch to is what organizations should be doing.
… We could do that in parallel to formal verification.
… If there was a problem, we could rescind, or extend the group's lifetime until it's happened.
markus_sabadello: We've been pursuing a parallel path from the beginning.
… We can look at other things to work on at the same time.
… Thanks to Aiden.
F2F meetings and W3C TPAC
markus_sabadello: The VCWG has an F2F in a couple of weeks, so we maybe skip the next meeting on 15 Feb.
… We can also have our own F2F, but there didn't seem to be much support for that last time.
<manu> +1 to skip next meeting due to VCWG F2F meeting.
markus_sabadello: Next meeting in four weeks. on 1 March.
gkellogg: we need to consider the outputs of the algorithm, hash and selective disclosure.