14:51:14 <RRSAgent> RRSAgent has joined #rch
14:51:19 <RRSAgent> logging to https://www.w3.org/2023/02/01-rch-irc
14:51:19 <Zakim> RRSAgent, make logs Public
14:51:50 <Zakim> please title this meeting ("meeting: ..."), pchampin
14:52:05 <pchampin> meeting: RCH WG bi-weekly meeting
14:57:32 <gkellogg> gkellogg has joined #rch
14:58:52 <markus_sabadello> markus_sabadello has joined #rch
14:59:33 <gkellogg> present+
15:00:00 <phila> phila has joined #rch
15:01:08 <pchampin> present+
15:01:13 <phila> present+
15:02:40 <Kazue> Kazue has joined #rch
15:02:53 <Kazue> present+
15:03:39 <pchampin> chair: markus_sabadello
15:03:39 <pchampin> previous meeting: https://www.w3.org/2023/01/18-rch-minutes.html
15:03:39 <yamdan> yamdan has joined #rch
15:03:39 <aidhog> aidhog has joined #rch
15:03:39 <pchampin> next meeting: https://www.w3.org/2023/02/15-rch-minutes.html
15:03:39 <gkellogg> scribe+ gkellogg
15:04:01 <yamdan> present+
15:04:10 <manu> manu has joined #rch
15:04:38 <gkellogg> q+
15:04:54 <manu> present+
15:05:05 <dlehn> present+
15:05:11 <markus_sabadello> gkellogg: Work is advancing in RDF* WG, issue activity and some work on getting Editors drafts of those specs in shape
15:05:23 <TallTed> TallTed has joined #rch
15:05:26 <phila> q+
15:05:28 <markus_sabadello> gkellogg: Started on some of the work on canonicalization, we just need definitions for quads
15:05:30 <manu> q+ to note some items happening in other WGs.
15:05:45 <markus_sabadello> ack gkellogg
15:05:47 <markus_sabadello> ack phila
15:06:01 <Kazue> q+
15:06:09 <markus_sabadello> phila: gkellogg is there anything in RDF* that we here need to pay attention to?
15:06:24 <markus_sabadello> gkellogg: Activity has been on semantics.. Some background activity about the mechanical bits
15:06:50 <manu> q+ to also mention Gordian Envelope and ACDC work.
15:07:00 <pchampin> q++
15:07:06 <markus_sabadello> gkellogg: Some things still need to be done before FPWD, hopefully in February
15:07:09 <pchampin> qq+
15:07:11 <markus_sabadello> q?
15:07:21 <markus_sabadello> ack pchampin
15:07:21 <Zakim> pchampin, you wanted to react to phila
15:07:40 <gkellogg> pchampin: The blocking point right now is assigning editors, which is in progress now.
15:07:54 <aidhog> present+
15:08:00 <gkellogg> ... Once we have editors, I don't see an obstacle on having FPWD.
15:08:05 <pchampin> q-+
15:08:13 <markus_sabadello> ack manu
15:08:13 <Zakim> manu, you wanted to note some items happening in other WGs. and to also mention Gordian Envelope and ACDC work.
15:08:19 <manu> Demonstration of Support for EdDSA Cryptosuite Adoption into VCWG: https://lists.w3.org/Archives/Public/public-vc-wg/2023Jan/0027.html
15:08:22 <gkellogg> manu: One of the first crypto suites is up for a WG adoption call today.
15:08:40 <gkellogg> ... We've gotten signatures from a variety of implementers.
15:08:57 <gkellogg> ... We have a list of 16 implementors who have implemented the EDD crypto suite.
15:10:01 <gkellogg> ... there's a vote today on adopting the suite. We've passed three of four hurdles.
15:10:40 <gkellogg> ... Having interoperable implementations isn't a guarantee that the WG will accept it.
15:11:30 <gkellogg> ... Please mail into the VCWG mailing list to support it, if you're a member.
15:12:01 <gkellogg> ... The call today is challenging for people in Europe or asia to make.
15:12:03 <manu> Alternatives to RDF*: https://lists.w3.org/Archives/Public/public-credentials/2023Jan/0073.html
15:12:26 <Kazue> q-
15:12:28 <aidhog> Gordian Envelopes
15:12:31 <gkellogg> manu: There are some alternatives to RDF-star. One called Gordian Envelops.
15:12:50 <TallTed> s/Envelops/Envelopes/
15:12:52 <gkellogg> ... It's a new graph structure that allows you to do interesting things.
15:13:17 <gkellogg> ... There's been some "crankiness" to RDF in parts of the group.
15:13:33 <TallTed> Nested containers. Graphs all the way down.
15:13:42 <gkellogg> ... THese other systems are rooted in the cryptographic community, rather than RDF.
15:14:19 <gkellogg> markus_sabadello: What we're doing here is fundamental to support the VCWG work.
15:14:26 <markus_sabadello> q?
15:15:17 <gkellogg> topic: Horizontal review process
15:15:47 <gkellogg> markus_sabadello: This is a part of the W3C process, and phila has created a number of issues on this.
15:16:17 <gkellogg> phila: I made some issues for us to track progress. Accessibility and Internationalization are the "easy" ones.
15:16:40 <gkellogg> ... I don't think for these there's much to say, but it needs to be done.
15:17:22 <gkellogg> ... There are potentially issues for text strings in triples for internationalization.
15:17:27 <manu> Phil is correct, I don't think we considered I18N canonicalization rules on text...
15:17:35 <gkellogg> ... But, these come up in the RDF specs anyway.
15:17:40 <manu> q+ to reach out to IETF CFRG?
15:18:04 <gkellogg> ... For Privacy and Security, we need text in the document to be reviewed.
15:18:19 <gkellogg> ... I'd ask for that to be pushed up the priority order.
15:18:21 <gkellogg> q+
15:18:34 <markus_sabadello> ack manu
15:18:34 <Zakim> manu, you wanted to reach out to IETF CFRG?
15:18:59 <gkellogg> manu: We didn't consider i18n specific c14n of strings.
15:19:27 <gkellogg> ... It would be a good idea to reach out to the crypto forum research group and IETF and ask for a form or something.
15:20:01 <gkellogg> ... That could backfire, as there may be some lack of sympathy for the c14n approach.
15:20:21 <gkellogg> ... If we go to the TAG, they'll ask if we had any external review.
15:20:39 <gkellogg> ... Of course, we have our own people in the group, but they may want some external review.
15:21:02 <markus_sabadello> ack gkellogg
15:21:04 <phila> q+
15:21:37 <markus_sabadello> ack phila
15:21:37 <gkellogg> gkellogg: I don't have anything to contribute to privacy and security, so looking for support.
15:22:01 <gkellogg> phila: perhaps Kazue or yamdan have something to contribute here?
15:22:16 <manu> q+ to offer /some/ text -- which we know about... and ask Chairs to reach out to IETF CFRG.
15:22:19 <gkellogg> ... Should I write to the CFRG group? I don't know anyone there myself.
15:22:24 <markus_sabadello> ack manu
15:22:24 <Zakim> manu, you wanted to offer /some/ text -- which we know about... and ask Chairs to reach out to IETF CFRG.
15:22:28 <yamdan> q+
15:22:41 <gkellogg> manu: On the S&C considerations, we have at least two sections to add there.
15:22:56 <gkellogg> ... One around BBS signatures and why HMAC.
15:23:30 <gkellogg> ... We should also point to the published mathematical proof, as well as Aiden's work to indicate that there has been mathematical review.
15:24:03 <gkellogg> ... WRT contacting CFRG, probably best if the chairs reach out rather than some other member.
15:24:33 <gkellogg> ... Wendy S used to be the link, but that has changed ...
15:24:55 <gkellogg> action: phila to reach out to CFRG
15:25:45 <markus_sabadello> q?
15:25:48 <markus_sabadello> ack yamdan
15:26:05 <gkellogg> yamdan: As for S&P section, I can also contribute something from the viewpoint of the user of the C14N algorithm.
15:26:42 <manu> ooh, poison graphs is another good addition to security section!
15:26:56 <gkellogg> ... 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.
15:27:18 <gkellogg> ... iherman had already referenced some papers, which is important for the section.
15:27:53 <gkellogg> markus_sabadello: I'm sure you and kazue have deep knowledge on the privay aspects, so that would be very valuable.
15:28:39 <gkellogg> phila: for the process, getting these sections complete are really important.
15:29:15 <gkellogg> markus_sabadello: We were just talking about security and poison graphs, which leads into the next topic.
15:29:19 <gkellogg> topic: Comparison and confidence in algorithms, with invited guest Aidan Hogan
15:29:33 <yamdan> "academic paper about poison graphs" I mentioned is https://arxiv.org/abs/1705.03686 , referred by Aidan in https://github.com/w3c/rdf-canon/issues/10#issuecomment-1397720096
15:29:48 <gkellogg> markus_sabadello: As a reminder, we discussed the two algorithms at the kick-off if this group.
15:30:08 <gkellogg> ... We had presentations from both dlongley and aidhog.
15:30:34 <gkellogg> ... We've begun work on dlongley's algorithm, but we've had open issues on comparing the algorithms.
15:31:24 <gkellogg> ... Aiden commented on #6 and #10 already.
15:32:02 <gkellogg> aidhog: WRT #10, there's a great list of comparison points.
15:32:30 <gkellogg> ... We know that both algorithms are similar, and Ivan has implemented both.
15:32:48 <gkellogg> ... It's not clear to me which is more efficient, and what does "common dataset" mean.
15:32:55 <manu> q+ on time/resource complexity has come up in other groups as well.
15:33:09 <gkellogg> ... The only way to determine this would be to select some representative datasets and run against each algorithm.
15:33:29 <gkellogg> ... We know the poison datasets are something to work out.
15:34:00 <gkellogg> ... Both algorithms have had mathematical proofs, and I think the one done on dlongley's was particularly good.
15:34:21 <gkellogg> ... Of course, they stoped short of saying that "we're certain this is correct"
15:34:38 <gkellogg> ... Also, Dave's addresses dataset and not graphs.
15:35:10 <gkellogg> ... I'd suggest that RDF-star use cases be reified into RDF datasets and canonicalize that rather than trying to extend the algorithms.
15:35:41 <gkellogg> ... On correctness: I'm certain that it's possible to define an algorithm that handles these.
15:35:55 <gkellogg> ... I'm highly confident that both algorithms work correctly.
15:36:12 <gkellogg> ... But, it depends on the risk/benefit analysis in case something goes wrong.
15:36:30 <gkellogg> ... What is sufficient due diligence before we can go forward.
15:36:50 <manu> q+ to note "backup c14n algorithm"
15:37:07 <gkellogg> ... For example, there is a graph isomorphism algorithm that was widely thought to be correct, before it was found not to be.
15:37:25 <gkellogg> ... But, I think it's highly likely that both algorithms are fine.
15:37:55 <gkellogg> ... I don't think you can say that just because algorithms have peer review that they're necessarily correct.
15:38:16 <gkellogg> ... To convince people, we should probably avoid people and look at a proof verification system.
15:38:43 <gkellogg> ... That would be the ultimate of due diligence. But, this would be a slow and difficult process.
15:39:48 <gkellogg> ... On poison graphs, there will always be some that take a long time barring some quantum breakthrough.
15:39:48 <gkellogg> q?
15:39:48 <gkellogg> markus_sabadello: Thanks, this is really helpful. Not all of us have such deep technical knowledge.
15:39:57 <pchampin> q+
15:39:59 <gkellogg> ack manu
15:39:59 <Zakim> manu, you wanted to comment on time/resource complexity has come up in other groups as well. and to note "backup c14n algorithm"
15:40:13 <gkellogg> manu: I agree with everything Aiden says.
15:40:28 <gkellogg> ... On the time/resource complexity question, this has come up in other groups.
15:40:46 <gkellogg> ... For example, people are complaining that RDF C14N is slow.
15:41:15 <gkellogg> ... 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.
15:41:32 <gkellogg> ... There's quite a lot of misrepresentation on how slow or fast these algorithms are.
15:41:46 <gkellogg> ... We do have a benchmark sure (from 5 years ago).
15:42:32 <gkellogg> ... 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.
15:42:46 <gkellogg> ... +1 for finding time to do benchmarking for the algorithms.
15:43:04 <gkellogg> ... Regarding formal verification: +1 to what Aiden said.
15:43:35 <gkellogg> ... We should try to find someone or some group to do a formal proof, because there will always be nay-sayers.
15:43:53 <gkellogg> ... Finding the people with the expertise and time to do this will be challenging.
15:45:11 <gkellogg> ... In parallel, we can look at alternative schemas such as JCS (JSON C14N).
15:45:11 <gkellogg> ... This might be easier to prove, but could be a backup scheme.
15:45:11 <gkellogg> ... If our C14N scheme fails, we should have a backup.
15:45:35 <gkellogg> ... You would loose all kinds of features (selective disclosure, etc.)
15:46:15 <gkellogg> ... We could suggest that if rdf-canon fails, the fallback is a non-RDF C14N scheme (JCS or straight hashing of JSON-LD)
15:46:21 <aidhog> q+
15:46:52 <manu> oh, AND, we could make aiden's alg the backup (which is what I meant to lead with)! :)
15:47:00 <aidhog> Coq
15:47:10 <gkellogg> pchampin: I happen to be in contact with a group of people that know Coq.
15:47:28 <gkellogg> ... I can reach out to them and know if they might be interested in working on this.
15:47:54 <TallTed> see http://dbpedia.org/resource/Coq
15:47:57 <markus_sabadello> ack aidhog
15:48:06 <gkellogg> aidhog: I think it would be great to have a benchmark.
15:48:06 <markus_sabadello> ack pchampin
15:48:18 <manu> Here's the current benchmark we have: https://github.com/digitalbazaar/rdf-canonize/tree/main/benchmark
15:48:26 <gkellogg> ... I think Ted mentioned some datasets to consider.
15:48:27 <manu> s/we have/DB has/
15:48:45 <gkellogg> ... In the case of my algorithm, it runs in memory, which is a MUST.
15:49:02 <gkellogg> ... Most RDF graphs are not anything like graphs you see in isomorphism problems.
15:49:33 <gkellogg> ... There are graphs that will run in milliseconds, and others that will never complete.
15:50:25 <gkellogg> ... Manu asked about a backup, but there's a question about damage done if the original one fails.
15:50:25 <manu> q+ to note "cost and damage" of initial failing... it's "bad"... very bad. :P
15:50:25 <gkellogg> ... It would have an effect on the trust of the group, if not the W3C.
15:50:42 <gkellogg> ... 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.
15:51:08 <gkellogg> ... I'm not sure this is all compatible with the timeframe of the group.
15:51:13 <gkellogg> q?
15:51:19 <gkellogg> ack manu
15:51:19 <Zakim> manu, you wanted to note "cost and damage" of initial failing... it's "bad"... very bad. :P
15:51:36 <gkellogg> manu: It would be very, very bad if it was shown to be a problem after deployment.
15:51:58 <gkellogg> ... It's being used for things like personal identification by government agencies.
15:52:13 <gkellogg> ... That would be Trillions of dollars of trade documents.
15:52:34 <gkellogg> ... We should do what we can, but the timeline question is key.
15:52:50 <gkellogg> ... Having a backup we can switch to is what organizations should be doing.
15:53:09 <gkellogg> ... We could do that in parallel to formal verification.
15:53:51 <gkellogg> ... If there was a problem, we could rescind, or extend the group's lifetime until it's happened.
15:54:28 <gkellogg> markus_sabadello: We've been pursuing a parallel path from the beginning.
15:54:28 <gkellogg> ... We can look at other things to work on at the same time.
15:55:06 <gkellogg> ... Thanks to Aiden.
15:55:08 <gkellogg> topic: F2F meetings and W3C TPAC
15:55:43 <gkellogg> markus_sabadello: The VCWG has an F2F in a couple of weeks, so we maybe skip the next meeting on 15 Feb.
15:56:07 <gkellogg> ... We can also have our own F2F, but there didn't seem to be much support for that last time.
15:56:34 <manu> +1 to skip next meeting due to VCWG F2F meeting.
15:56:42 <pchampin> next meeting: https://www.w3.org/2023/03/01-rch-minutes.html
15:56:50 <gkellogg> ... Next meeting in four weeks. on 1 March.
15:58:21 <gkellogg> gkellogg: we need to consider the outputs of the algorithm, hash and selective disclosure.
15:58:36 <phila> zakim, end meeting
15:58:36 <Zakim> As of this point the attendees have been gkellogg, pchampin, phila, Kazue, yamdan, manu, dlehn, aidhog
15:58:38 <Zakim> RRSAgent, please draft minutes
15:58:40 <RRSAgent> I have made the request to generate https://www.w3.org/2023/02/01-rch-minutes.html Zakim
15:58:47 <Zakim> I am happy to have been of service, phila; please remember to excuse RRSAgent.  Goodbye
15:58:47 <Zakim> Zakim has left #rch
15:59:32 <gkellogg> rrsagent, you are excused
15:59:32 <RRSAgent> I'm logging. I don't understand 'you are excused', gkellogg.  Try /msg RRSAgent help
15:59:40 <gkellogg> rrsagent, bye
15:59:40 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2023/02/01-rch-actions.rdf :
15:59:40 <RRSAgent> ACTION: phila to reach out to CFRG [1]
15:59:40 <RRSAgent>   recorded in https://www.w3.org/2023/02/01-rch-irc#T15-24-55