05:02:00 <RRSAgent> RRSAgent has joined #ldsec
05:02:00 <RRSAgent> logging to https://www.w3.org/2019/09/18-ldsec-irc
05:02:02 <Zakim> Zakim has joined #ldsec
05:02:13 <manu> Meeting: Linked Data Security
05:02:17 <manu> rrsagent, make logs public
05:02:23 <manu> rrsagent, make minutes
05:02:23 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/18-ldsec-minutes.html manu
05:06:21 <manu> rrsagent, draft minutes
05:06:21 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/18-ldsec-minutes.html manu
05:06:50 <manu> Chair: manu
05:06:57 <manu> present+
05:06:59 <manu> rrsagent, draft minutes
05:06:59 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/18-ldsec-minutes.html manu
05:14:02 <kiyoto> kiyoto has joined #ldsec
05:17:37 <yoshiaki> yoshiaki has joined #ldsec
05:28:41 <yoshiaki> yoshiaki has joined #ldsec
05:34:20 <yoshiaki_> yoshiaki_ has joined #ldsec
05:34:59 <yoshiaki_> yoshiaki_ has joined #ldsec
05:35:56 <gkellogg> gkellogg has joined #ldsec
05:36:09 <azaroth> azaroth has joined #ldsec
05:36:19 <azaroth> present+ Rob_Sanderson
05:36:24 <gkellogg> scribe+
05:36:31 <bigbluehat> bigbluehat has joined #ldsec
05:36:33 <gkellogg> present+ Gregg_Kellogg
05:36:41 <bigbluehat> present+ Benjamin_Young
05:36:42 <deiu> deiu has joined #ldsec
05:36:47 <JoeAndrieu> JoeAndrieu has joined #ldsec
05:36:54 <st> st has joined #ldsec
05:37:11 <JoeAndrieu> present+ Joe_Andrieu
05:37:19 <deiu> present+ Andrei_Sambra
05:37:25 <gkellogg> present+ manu
05:37:29 <gkellogg> present+ ivan
05:37:38 <deiu> present+ Ivan_Herman
05:37:38 <Dudley> Dudley has joined #ldsec
05:37:57 <gkellogg> manu: Just a handful of slides. (link forthcoming)
05:38:00 <Dudley> present+ Dudley_Collinson
05:38:05 <Franck> Franck has joined #ldsec
05:38:14 <manu> slides: https://docs.google.com/presentation/d/1dn4uotAHXgKIwrPW3dlPArB19NZzxUf_cOSQcSlxb2Y/edit
05:38:37 <azaroth> azaroth has joined #ldsec
05:39:16 <gkellogg> … We’ll discuss LD security and whether to push forward at W3C.
05:39:37 <gkellogg> … There have been a number of initiatives floating around for 7+ years (jcarroll 2003)
05:39:49 <gkellogg> … Why now?
05:40:01 <gkellogg> … C14N, proofs, signatures
05:40:24 <tpk> tpk has joined #ldsec
05:40:26 <gkellogg> … I’m co-inventor of VC, JSON-LD, Diigital Bazaar, …
05:40:56 <gkellogg> … The VC spec will be a REC in about amonth, and specifies proofs using JWT and LD Signatures.
05:41:12 <yoshiaki> yoshiaki has joined #ldsec
05:41:15 <gkellogg> … The concerns are that there’s no recommended specification of LD sigantures.
05:41:49 <gkellogg> … The US Fed Govt through DHS has mandated the use of JSON-LD and VC and DIDs. They want an official standard for LD Sigs.
05:42:04 <gkellogg> … (no supprize, but now it’s important).
05:42:11 <gkellogg> … Also banks, healthcare, etc.
05:42:16 <jc> jc has joined #ldsec
05:42:29 <gkellogg> … DID camp needs signatures too.
05:42:55 <gkellogg> … Other groups have provenance use cases, graph equaility, etc.
05:43:00 <gkellogg> … Also WoT needs signatures.
05:43:22 <gkellogg> … (picture of stack)
05:43:28 <yoshiaki_> yoshiaki_ has joined #ldsec
05:43:57 <gkellogg> … At the bottom is RDF Dataset C14N, to ensure that different expressions result in the same hash.
05:44:32 <gkellogg> … Above, LD Proofs. A digital signature is just one type of proof. (proof of work, stake, elapsed time, …)
05:44:55 <gkellogg> … Above that is LD Signatures, and above that Cryptography standards
05:45:35 <gkellogg> An example proof mechanism is Equihash which is not a digital proof.
05:46:24 <gkellogg> … RDF C14N transforms N-Quads into a canonical serialization
05:46:59 <jc_> jc_ has joined #ldsec
05:47:05 <gkellogg> … There are two mathematical proofs, one by Aiden Hogan, and the most recent by Rachel Arnold and David Longley undergoing peer review. (Aiden’s has been peer reviewed).
05:47:53 <gkellogg> ivan: The C14N of an RDF graph has been an open issue. jcarrol and Pat Hayes had an algorithm in 2002, but indicated that it was not complete (there were graphs for which it wouldn’t work).
05:48:14 <gkellogg> … For a long time, nothing happened, because there was no proof.
05:48:54 <gkellogg> … Aiden published a paper which was complete, and had an implementation (in Java). I implemented in JavaScript, but the paper is not REC quality.
05:49:32 <gkellogg> … In parallel, dlongley came out with their algorithm, but it had no proof. manu and I have been discussing for a while.
05:49:38 <jc> jc has joined #ldsec
05:50:05 <yoshiaki> yoshiaki has joined #ldsec
05:50:30 <gkellogg> … We expect a peer review of the associated paper, and we’ve discussed on how to put into a REC. Most RECs aren’t mathimatical, and W3C is not equiped to judge mathematics. But, with peer review, we feel we can publish such a REC.
05:50:51 <gkellogg> arnod: two papers, are they the same?
05:51:42 <gkellogg> ivan: I understand that the two papers are very close. Simple cases plus some esoteric casses. a WG would need to choose between them.
05:52:12 <Dudley> Dudley has joined #ldsec
05:52:24 <deiu> q?
05:52:40 <gkellogg> sander: you mentioned that W3C doesn’t have mathematical capability, but many members do have the expertise.
05:53:12 <deiu> q+
05:53:37 <gkellogg> ivan: You need different worlds to work together, SemWeb/RDF is one thing, and Crypto people looking at RDF would be difficult to make happen. They’d have to deeply understand things like BNodes.
05:54:08 <gkellogg> … Aiden is a mathematician with a SemWeb background, and the other is a combination of mathematician and engineer.
05:54:23 <gkellogg> manu: We’re trying to find good review from other universities.
05:54:54 <gkellogg> ivan: If we get close to the point where we need to get a charter, we will have to call out university members who’s opinion would be important.
05:55:16 <gkellogg> tobias: W3C has said they would incubate?
05:56:06 <gkellogg> ivan: For now, there’s an understanding in W3C is that if there is an “official” proof that says the algorithms are okay, that W3C would accept that as input, and we would not have to review.
05:56:28 <gkellogg> … We would accept that the community of Crypto people have accepted it.
05:56:46 <deiu> ack
05:57:05 <NJ__> NJ__ has joined #ldsec
05:57:07 <jc> jc has joined #ldsec
05:57:11 <azaroth> q?
05:57:15 <azaroth> ack deiu
05:57:22 <yoshiaki> yoshiaki has joined #ldsec
05:57:48 <gkellogg> Scribe notes that discussion is that it’s not simply JSON-LD.
05:58:09 <gkellogg> manu: Is there support to charter a group to handle these specs?
05:58:42 <gkellogg> ivan: Need is not just for VC, there is a broad need for signed RDF data.
05:59:29 <gkellogg> … We need to understand boundaries of the WG. Obviously, C14N is necessary. What else do we need?
05:59:39 <azaroth> q+ re dependent canonicalizations
05:59:52 <azaroth> q+ to note dependent canonicalizations
05:59:52 <gkellogg> … If I compare to XML Sig, it has C14N, a vocabulary, and a further XML serialization.
06:00:07 <gkellogg> … We may have to have a vocabulary to describe how to put the data back into LD.
06:00:14 <yoshiaki> yoshiaki has joined #ldsec
06:00:58 <gkellogg> manu: Shows JSON-LD to C14N in N-Quads. (the _:c14nxxx is part of the serialization).
06:01:23 <gkellogg> … That gives you a cross-syntax signature.
06:01:55 <gkellogg> … The key is that it is syntax/serialization independent.
06:02:31 <gkellogg> … LD Proofs are used to express digital proofs. (THere are other types of proofs).
06:03:00 <gkellogg> … LD Proofs are a way of attaching a proof to an RDF document.
06:03:40 <gkellogg> … (illustrates a proof)
06:04:07 <jc> jc has joined #ldsec
06:04:25 <gkellogg> … A CuckooCycleProofOfWork2019 could be used to show proof of work.
06:04:53 <gkellogg> … comes with domain, proofValue, nonce, and other annotations that are included in the verification of the signature.
06:05:30 <gkellogg> … Above proof is LD Signatures. It adds a verification method (e.g., pub key). What matters is the graph, not where the graph is located.
06:05:43 <gkellogg> … This is the vocabulary part.
06:06:01 <gkellogg> … Proof requires C14N to get hash.
06:06:36 <gkellogg> … There aren’t many developer options when picking a signature method.
06:07:30 <gkellogg> … LD Cryptosuites are provided pre-packaged suites that bundle the various pieces together in an easy to use type.
06:07:45 <yoshiaki> yoshiaki has joined #ldsec
06:07:52 <bigbluehat> q?
06:07:53 <gkellogg> q?
06:07:56 <azaroth> ack azaroth
06:07:58 <Zakim> azaroth, you wanted to discuss dependent canonicalizations and to note dependent canonicalizations
06:08:03 <gkellogg> q+ ivan
06:08:22 <gkellogg> azaroth: isn’t there also a sute of other C14N bits?
06:08:44 <gkellogg> manu: There could be, we have a univeral RDF Dataset canonicalization algorithm.
06:09:12 <kiyoto> kiyoto has joined #ldsec
06:09:17 <gkellogg> azaroth: If we have a JSON literal and the encoding doesn’t canonicalize that, there would be a different hash generated by an algorithm which uses different white space, for examples.
06:09:31 <bigbluehat> q+
06:09:38 <kiyoto> kiyoto has joined #ldsec
06:09:42 <bigbluehat> q-
06:09:57 <gkellogg> ivan: for datatypes, there are C14N issues. There is one for XML, probably not for HTML.
06:10:55 <gkellogg> azaroth: The WG would not consider JSON canonicalization as being in scope.
06:11:02 <gkellogg> manu: We don’t go into literals.
06:11:03 <bigbluehat> JSON Literals in JSON-LD 1.1 (for the curious) https://w3c.github.io/json-ld-syntax/#json-literals
06:11:08 <gkellogg> ack ivan
06:11:18 <azaroth> q?
06:11:26 <gkellogg> ivan: The signature algorithms shown exist? Who defines them.
06:11:32 <kiyoto> kiyoto has joined #ldsec
06:11:46 <gkellogg> … My feeling is that we standardize the vocabulary, and C14N, but not the specific methods
06:12:05 <gkellogg> manu: Customers need the algorithms to be standardized.
06:12:54 <gkellogg> manu: the specs don’t define the encodings, just the vocabulary.
06:13:06 <azaroth> q+ to ask about registries?
06:13:25 <bigbluehat> scribe+ bigbluehat
06:13:38 <bigbluehat> gkellogg: the RDF canonicalization does define 3 mechanisms
06:13:52 <bigbluehat> manu: other things (signature algo, etc) would be out of scope
06:14:00 <gkellogg> manu: hashing and signature algorithms are out of scope, but signatures are
06:14:32 <gkellogg> azaroth: We are not defining, but we are selecting. THis plays into registries and such, which may need to be updated.
06:14:41 <azaroth> ack azaroth
06:14:41 <Zakim> azaroth, you wanted to ask about registries?
06:14:47 <bigbluehat> q+
06:14:54 <bigbluehat> q-
06:14:55 <gkellogg> manu: The CCG is currently in charge of the registry, but could be handed off.
06:15:27 <gkellogg> manu: next steps. We still need peer review, then we need to seek a charter
06:16:05 <jc> jc has joined #ldsec
06:16:11 <gkellogg> ivan: Speaking for myself, if we have the reviews for the algorithms (reconciled). Creating a charter using the algorithms as input that it is doable.
06:16:35 <gkellogg> arnod: Why isn’t one peer reviewed algorithm sufficient?
06:16:55 <gkellogg> manu: We need two independent proofs.
06:17:48 <gkellogg> ivan: We have an implementation of an unproved algorihtm, and no production ready implementation of the one which is reviewed.
06:18:03 <gkellogg> … At some point, we will make the bridge to reconcile the two different algorithms.
06:18:04 <deiu> q+ to talk about IPR
06:18:13 <gkellogg> manu: Expectation is that they algorithms converge.
06:19:02 <deiu> q-
06:19:07 <gkellogg> ivan: Aiden’s algorithm is IP free. DB’s has been published to the public domain.
06:20:02 <gkellogg> ken: just to clarify that the box at the top defines out to call out to an external crypto library and how to apply them (protocol?)
06:21:41 <gkellogg> manu: What remains is if anyone sees issues around formal objections or organizations that may object.
06:21:49 <igarashi_> igarashi_ has joined #ldsec
06:22:01 <gkellogg> ivan: There will be “the usual” objections.
06:22:04 <jc_> jc_ has joined #ldsec
06:23:16 <gkellogg> tony: I tried to implement this, but couldn’t. Spec is incomplete.
06:23:34 <gkellogg> ivan: that’s why the mathematical paper needs to be done, but not that the spec is complete.
06:24:07 <gkellogg> tony: I worked on XML C14N and it was a disaster.
06:24:27 <jc> jc has joined #ldsec
06:24:55 <gkellogg> … The processing time required was a problem, required sender vs receiver C14N.
06:25:21 <gkellogg> … Is it going to be fast enough?
06:25:43 <gkellogg> ivan: I know Aiden ran his implementation through large LD sets and showed performance.
06:26:04 <gkellogg> manu: Depending on the type of graph (poison graphs) it can take 50-100ms to detect an attack.
06:26:32 <gkellogg> … In the easiest case, all your doing is sorting, takes about 5-25ms.
06:26:56 <gkellogg> … If we put JSON Schema in, it takes 10x longer to do it vs C14N.
06:27:10 <gkellogg> … A Base64 encode takes about 1/2 the time.
06:27:23 <gkellogg> … It’s on the order of Base64 enode time.
06:28:48 <gkellogg> xxx: would it be possible for graph stores to just use canonicalized bnode names?
06:29:02 <azaroth> s/xxx/sander/
06:29:04 <gkellogg> ivan: In theory, but any change throws it off.
06:30:12 <gkellogg> manu: You can also canonicalize to a template and reuse at very fast speed.
06:30:55 <gkellogg> tony: can I use some XPath like thing?
06:31:19 <gkellogg> manu: you could, but it’s likely unnecessary, as we don’t have the same problems. E.G., there’s no nesting.
06:32:00 <gkellogg> … You could use framing and JSON pointer.
06:32:07 <yoshiaki> yoshiaki has joined #ldsec
07:31:35 <yoshiaki> yoshiaki has joined #ldsec
07:39:00 <manu> rrsagent, draft minutes
07:39:00 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/18-ldsec-minutes.html manu
07:39:08 <manu> rrsagent, make minutes
07:39:08 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/18-ldsec-minutes.html manu
07:39:12 <manu> rrsagent bye
07:39:15 <manu> zakim, bye
07:39:15 <Zakim> leaving.  As of this point the attendees have been manu, Rob_Sanderson, Gregg_Kellogg, Benjamin_Young, Joe_Andrieu, Andrei_Sambra, ivan, Ivan_Herman, Dudley_Collinson
07:39:15 <Zakim> Zakim has left #ldsec
07:39:17 <manu> rrsagent, bye
07:39:17 <RRSAgent> I see no action items
07:46:26 <RRSAgent> RRSAgent has joined #ldsec
07:46:26 <RRSAgent> logging to https://www.w3.org/2019/09/18-ldsec-irc
07:46:47 <Zakim> Zakim has joined #ldsec
07:48:12 <manu> rrsagent, make minutes
07:48:12 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/18-ldsec-minutes.html manu
08:27:28 <yoshiaki> yoshiaki has joined #ldsec
08:28:11 <yoshiaki> yoshiaki has joined #ldsec
08:33:39 <yoshiaki_> yoshiaki_ has joined #ldsec
08:35:47 <jc> jc has joined #ldsec
08:40:17 <jc> jc has joined #ldsec
08:40:38 <jc> jc has joined #ldsec
08:41:16 <gkellogg> gkellogg has joined #ldsec
08:51:14 <jc> jc has joined #ldsec
09:04:27 <jc> jc has joined #ldsec
09:20:17 <jc> jc has joined #ldsec
09:21:59 <jc> jc has joined #ldsec
09:28:50 <jc> jc has joined #ldsec
09:34:48 <yoshiaki> yoshiaki has joined #ldsec
09:38:54 <yoshiaki_> yoshiaki_ has joined #ldsec
09:57:30 <Zakim> Zakim has left #ldsec