W3C

- DRAFT -

Linked Data Security

18 Sep 2019

Attendees

Present
manu, Rob_Sanderson, Gregg_Kellogg, Benjamin_Young, Joe_Andrieu, Andrei_Sambra, ivan, Ivan_Herman, Dudley_Collinson
Regrets
Chair
manu
Scribe
gkellogg

Contents


scribe+

manu: Just a handful of slides. (link forthcoming)

<manu> slides: https://docs.google.com/presentation/d/1dn4uotAHXgKIwrPW3dlPArB19NZzxUf_cOSQcSlxb2Y/edit

manu: We’ll discuss LD security and whether to push forward at W3C.
... There have been a number of initiatives floating around for 7+ years (jcarroll 2003)
... Why now?
... C14N, proofs, signatures
... I’m co-inventor of VC, JSON-LD, Diigital Bazaar, …
... The VC spec will be a REC in about amonth, and specifies proofs using JWT and LD Signatures.
... The concerns are that there’s no recommended specification of LD sigantures.
... 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.
... (no supprize, but now it’s important).
... Also banks, healthcare, etc.
... DID camp needs signatures too.
... Other groups have provenance use cases, graph equaility, etc.
... Also WoT needs signatures.
... (picture of stack)
... At the bottom is RDF Dataset C14N, to ensure that different expressions result in the same hash.
... Above, LD Proofs. A digital signature is just one type of proof. (proof of work, stake, elapsed time, …)
... Above that is LD Signatures, and above that Cryptography standards

An example proof mechanism is Equihash which is not a digital proof.

scribe: RDF C14N transforms N-Quads into a canonical serialization
... 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).

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).
... For a long time, nothing happened, because there was no proof.
... Aiden published a paper which was complete, and had an implementation (in Java). I implemented in JavaScript, but the paper is not REC quality.
... In parallel, dlongley came out with their algorithm, but it had no proof. manu and I have been discussing for a while.
... 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.

arnod: two papers, are they the same?

ivan: I understand that the two papers are very close. Simple cases plus some esoteric casses. a WG would need to choose between them.

sander: you mentioned that W3C doesn’t have mathematical capability, but many members do have the expertise.

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.
... Aiden is a mathematician with a SemWeb background, and the other is a combination of mathematician and engineer.

manu: We’re trying to find good review from other universities.

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.

tobias: W3C has said they would incubate?

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.
... We would accept that the community of Crypto people have accepted it.

<deiu> ack

Scribe notes that discussion is that it’s not simply JSON-LD.

manu: Is there support to charter a group to handle these specs?

ivan: Need is not just for VC, there is a broad need for signed RDF data.
... We need to understand boundaries of the WG. Obviously, C14N is necessary. What else do we need?
... If I compare to XML Sig, it has C14N, a vocabulary, and a further XML serialization.
... We may have to have a vocabulary to describe how to put the data back into LD.

manu: Shows JSON-LD to C14N in N-Quads. (the _:c14nxxx is part of the serialization).
... That gives you a cross-syntax signature.
... The key is that it is syntax/serialization independent.
... LD Proofs are used to express digital proofs. (THere are other types of proofs).
... LD Proofs are a way of attaching a proof to an RDF document.
... (illustrates a proof)
... A CuckooCycleProofOfWork2019 could be used to show proof of work.
... comes with domain, proofValue, nonce, and other annotations that are included in the verification of the signature.
... 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.
... This is the vocabulary part.
... Proof requires C14N to get hash.
... There aren’t many developer options when picking a signature method.
... LD Cryptosuites are provided pre-packaged suites that bundle the various pieces together in an easy to use type.

<Zakim> azaroth, you wanted to discuss dependent canonicalizations and to note dependent canonicalizations

azaroth: isn’t there also a sute of other C14N bits?

manu: There could be, we have a univeral RDF Dataset canonicalization algorithm.

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.

ivan: for datatypes, there are C14N issues. There is one for XML, probably not for HTML.

azaroth: The WG would not consider JSON canonicalization as being in scope.

manu: We don’t go into literals.

<bigbluehat> JSON Literals in JSON-LD 1.1 (for the curious) https://w3c.github.io/json-ld-syntax/#json-literals

ivan: The signature algorithms shown exist? Who defines them.
... My feeling is that we standardize the vocabulary, and C14N, but not the specific methods

manu: Customers need the algorithms to be standardized.
... the specs don’t define the encodings, just the vocabulary.

<bigbluehat> scribe+ bigbluehat

<bigbluehat> gkellogg: the RDF canonicalization does define 3 mechanisms

<bigbluehat> manu: other things (signature algo, etc) would be out of scope

manu: hashing and signature algorithms are out of scope, but signatures are

azaroth: We are not defining, but we are selecting. THis plays into registries and such, which may need to be updated.

<Zakim> azaroth, you wanted to ask about registries?

manu: The CCG is currently in charge of the registry, but could be handed off.
... next steps. We still need peer review, then we need to seek a charter

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.

arnod: Why isn’t one peer reviewed algorithm sufficient?

manu: We need two independent proofs.

ivan: We have an implementation of an unproved algorihtm, and no production ready implementation of the one which is reviewed.
... At some point, we will make the bridge to reconcile the two different algorithms.

manu: Expectation is that they algorithms converge.

ivan: Aiden’s algorithm is IP free. DB’s has been published to the public domain.

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?)

manu: What remains is if anyone sees issues around formal objections or organizations that may object.

ivan: There will be “the usual” objections.

tony: I tried to implement this, but couldn’t. Spec is incomplete.

ivan: that’s why the mathematical paper needs to be done, but not that the spec is complete.

tony: I worked on XML C14N and it was a disaster.
... The processing time required was a problem, required sender vs receiver C14N.
... Is it going to be fast enough?

ivan: I know Aiden ran his implementation through large LD sets and showed performance.

manu: Depending on the type of graph (poison graphs) it can take 50-100ms to detect an attack.
... In the easiest case, all your doing is sorting, takes about 5-25ms.
... If we put JSON Schema in, it takes 10x longer to do it vs C14N.
... A Base64 encode takes about 1/2 the time.
... It’s on the order of Base64 enode time.

sander: would it be possible for graph stores to just use canonicalized bnode names?

ivan: In theory, but any change throws it off.

manu: You can also canonicalize to a template and reuse at very fast speed.

tony: can I use some XPath like thing?

manu: you could, but it’s likely unnecessary, as we don’t have the same problems. E.G., there’s no nesting.
... You could use framing and JSON pointer.

<manu> rrsagent bye

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/09/18 07:48:18 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/xxx/sander/
Default Present: manu, Rob_Sanderson, Gregg_Kellogg, Benjamin_Young, Joe_Andrieu, Andrei_Sambra, ivan, Ivan_Herman, Dudley_Collinson
Present: manu Rob_Sanderson Gregg_Kellogg Benjamin_Young Joe_Andrieu Andrei_Sambra ivan Ivan_Herman Dudley_Collinson
No ScribeNick specified.  Guessing ScribeNick: gkellogg
Inferring Scribes: gkellogg

WARNING: No "Topic:" lines found.


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]