IRC log of ldsec on 2019-09-18
Timestamps are in UTC.
- 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