Linked Data Signature or Linked Data Security? about rch-wg-charter HOT 31 CLOSED

The downside of “Linked Data Proofs” is similar to the problems that came up with Verifiable Claims. In the later case, the expectation was that a claim could somehow be verified as being true. Similarly, would someone expect an LD Proof to somehow prove that the statements mad in a dataset are true?

this seems to me to be more about container integrity, the the statements received by some on are the same statements that the signer made, without saying anything about the veracity of these statements themselves. “Linked Data Integrity?”

from rch-wg-charter.

“Linked Data Integrity?”

I really like "Linked Data Integrity".

from rch-wg-charter.

This alternative came up during earlier discussions. @msporny @dlongley, can you chime in?

Yes, the specification covers more than just "Signatures". What it really does is enable one to express proving things in a cryptographic way: proof of existence, proof of work, proof of possession, etc.

The specification helps you secure Linked Data... thus the request to name the specification "Linked Data Security". We could also name it something like "Securing Linked Data". (SLD -- prounounced "sled")?

My personal opinion is that "Linked Data Signatures" is definitely the wrong name for the specification, because the scope is broader... signatures are just one part of the whole.

from rch-wg-charter.

"Securing Linked Data". (SLD -- prounounced "sled")?

... as long as it is not mixed up with LSD :-)

(Sorry, I could not resist...)

from rch-wg-charter.

I am torn here.

Very strictly speaking the statement

[…] the specification covers more than just "Signatures".

isn't correct. The specification planned in this working group covers just signatures. Clearly, signatures can be used for all kinds of things, including those that you refer to. But none of the details for those, e.g., how you would do proof of possession, is defined normatively in this Working Group.

To be more exact: in this incarnation of the Working Group, because if one envisages on longer term, then we may have to have a continuation working group (after a suitable rechartering) that builds on the output of this one but goes towards the larger set of goals.

Therein lies the problem: should we name the Working Group based strictly on what is in its charter for the coming two years, or should we name it with a set of longer term in mind (knowing that it should be the subject of another discussion to define what those longer term goals are). Pinging @wseltzer here, who may have an advice.

One idea (just fresh in my mind, and it is not fully baked): would it be possible to add to the charter, as part of the non normative deliverables, the creation of a WG Note that would be the first step in specifying the longer term goals, first draft on how to do them, etc? A Note that may become the seed for a new Recommendation in a future incarnation of this WG? That may explain the name of the WG if we keep it as is.

from rch-wg-charter.

... as long as it is not mixed up with LSD :-)

(Sorry, I could not resist...)

Well ... the LDS acronym has its own issues... https://en.wikipedia.org/wiki/The_Church_of_Jesus_Christ_of_Latter-day_Saints

from rch-wg-charter.

I'd prefer the group to be Linked Data Security WG (for the reasons stated above) and a NOTE be created expressing a roadmap -- but the charter limiting current work to what we've already expressed in the charter (focus on canonicalization and signature representation).

from rch-wg-charter.

Thanks for the proposal @gkellogg, I like it too.

I will do the PR hopefully today. I will (probably) use the terms "Linked Data Hash" and "Linked Data Integrity" as the two specification names. We can finalize the titles later if we have to.

from rch-wg-charter.

This alternative came up during earlier discussions. @msporny @dlongley, can you chime in?

from rch-wg-charter.

This alternative came up during earlier discussions. @msporny @dlongley, can you chime in?

Yes, the specification covers more than just "Signatures". What it really does is enable one to express proving things in a cryptographic way: proof of existence, proof of work, proof of possession, etc.

The specification helps you secure Linked Data... thus the request to name the specification "Linked Data Security". We could also name it something like "Securing Linked Data". (SLD -- prounounced "sled")?

My personal opinion is that "Linked Data Signatures" is definitely the wrong name for the specification, because the scope is broader... signatures are just one part of the whole.

So if Ivan's interpretation is right, then "Signatures" sounds appropriate. @msporny if you think the other work is in scope, that should be clearer in the charter (and it might affect my comments on the whole).

from rch-wg-charter.

@samuelweiler @msporny

Would this be an acceptable change for all?

One idea (just fresh in my mind, and it is not fully baked): would it be possible to add to the charter, as part of the non normative deliverables, the creation of a WG Note that would be the first step in specifying the longer term goals, first draft on how to do them, etc? A Note that may become the seed for a new Recommendation in a future incarnation of this WG? That may explain the name of the WG if we keep it as is.

Note also that there is a connection to #46, mostly to #46 (comment). If that option carries, then we can also keep the name as is.

from rch-wg-charter.

@samuelweiler wrote:

@msporny if you think the other work is in scope, that should be clearer in the charter (and it might affect my comments on the whole).

It depends on what you mean by "in scope"... :)

By "in scope", I mean that the WG is going to make sure it doesn't do anything that prevents the proof of existence or proof of work use cases. That is, the design will be inclusive of being able to do those things in a potential future WG (that may or may not ever spring into existence). The WG will be focusing on digital signatures (proof of possession -- of private key material) as a primary use case.

What I DO NOT mean is that the WG will be working on expressing proof of existence (e.g., anchoring to a blockchain) or proof of work (e.g., burning energy to brute-force a cryptographic hash value) as normative (or even possibly non-normative) cryptographic suites. Doing work is clearly out of scope.

I do understand that there is nuance there and that a number of W3C Members may not try to understand that nuance before having a knee-jerk reaction... so I'm sympathetic to @iherman's concerns.

from rch-wg-charter.

@iherman wrote:

The specification planned in this working group covers just signatures. Clearly, signatures can be used for all kinds of things, including those that you refer to.

Disagree strongly. We've continued to miscommunicate on this point and I've often just let it slide because we had more important things to discuss... but this time, I'm gonna push back a bit. :)

I'm going to be very pedantic here. The specification covers the ability to express more than just signatures as digital proofs. Signatures CANNOT be used to do the things I used as examples... which is why I used them as examples -- those things ARE NOT digital signatures. :)

That is not to say that the WG will work on any of these non-digital-signature use cases, we just need to make sure that WG members are not under the impression that the design space is ONLY about digital signature use cases. See #47 (comment) for more on this.

from rch-wg-charter.

One idea (just fresh in my mind, and it is not fully baked): would it be possible to add to the charter, as part of the non normative deliverables, the creation of a WG Note that would be the first step in specifying the longer term goals, first draft on how to do them, etc? A Note that may become the seed for a new Recommendation in a future incarnation of this WG? That may explain the name of the WG if we keep it as is.

I'd be fine with this.

To be clear -- I'm fine w/ keeping the name as "Linked Data Signatures WG" as long as a W3C Member isn't going to use that against the group (as has happened in the past). "We have JOSE and base64-encoding, these are all solved problems, we don't need this work." <-- remember, that's one of the reasons that this work got delayed for years.

from rch-wg-charter.

I'm going to be very pedantic here. The specification covers the ability to express more than just signatures as digital proofs. Signatures CANNOT be used to do the things I used as examples... which is why I used them as examples -- those things ARE NOT digital signatures. :)

Sigh... indeed we seem to miscommunicate.

At this moment the specification that is currently called "Linked Data Security" is described as:

1. the generation of a canonical form using the algorithm specified in the “RDF Dataset Canonicalization” deliverable,
2. the generation of a cryptographic hash,
3. the generation of a digital proof, such as a digital signature, and
4. the expression of the result in an RDF Dataset in a way that enables a 3rd party to verify the digital proof

It is not clear, now that I look at this again, what the line "digital proof, such as a digital signature" really means. It suggests that this specification may include more than just a signature, and I do not think that is what we meant and I am not even sure what that would be. In my mental model the specification expresses the hash and a digital signature. Then we have a separate, non-normative document that may provide additional cryptographic terms.

That does not contradict what you say above that "Signatures CANNOT be used to do the things I used as examples..." but, at this moment, it is absolutely unclear to me what else we would refer to normatively.

I understand your concern which is, if I understand it well, that the group will have a problem to go on to a broader work later if things are too narrowly constrained. But we should, nevertheless, be more precise and, I am afraid, we are not at this moment.

Here is a way I'd see forward. We do the following changes.

1. We rename the LDS spec as Linked Data Signature (and the Linked Data Signature Vocabulary for the other deliverable).

2. The goals of the LDS document would be slightly narrower, namely:

   1. the generation of a canonical form using the algorithm specified in the “RDF Dataset Canonicalization” deliverable,
   2. the generation of a cryptographic hash,
   3. the generation of a digital signature, and
   4. the expression of the result in an RDF Dataset in a way that enables a 3rd party to verify the digital signature.

   (Note that I've removed references to proofs.)

3. We add a separate non normative deliverable under 2.2 (emphasize "deliverable", not only a vague "may be created"!) described, roughly, as:

   Linked Data Security
   This document outlines possible approaches to generate Linked Data Proofs based on the Linked Data Signature specification combined with existing cryptographic algorithms and tools. This would include, for example, proof of existence, proof of work, or proof of possession. Elements of this work may become subject of standardization in future Working Groups.

4. With an eye on issue #46 we also add the Linked Data Security Registry to the list of WG Notes deliverables. (Whether we make a reference to the upcoming process changes, as referred to in #46, or not is a different matter.)

I believe that, with these changes, the spec goals and chartered elements are clear, but we also clearly lay out that we intend to go beyond that when the time comes.

WDYT?

from rch-wg-charter.

@iherman,

-1 to the above approach. Here's why:

The way we want to structure this work is that we're creating a way to express Linked Data Proofs, where the first and only examples we're normatively working on in the group are proof of type "digital signature". This is how the layering should be done, so to jump up a layer and define only signatures and then say we may come back later to create the lower layer for those signatures to fit into is backwards.

What do we need to change, language wise, in the charter to make it clear that this is the approach and to be specific that we're only tackling digital-signature-style proofs in this iteration?

Would it be helpful to say that we intend to create a registry for decentralized extensions of other proof types (or at least indicate how such extensions could be created) that may be considered for future standardization -- but that the WG is only going to normatively define some digital-signature style proof types?

from rch-wg-charter.

@dlongley

The way we want to structure this work is that we're creating a way to express Linked Data Proofs, where the first and only examples we're normatively working on in the group are proof of type "digital signature".

My question is then: what else would the document entitled "Linked Data Security (LDS)" contains normatively? Because the only thing that the WG is working on, at least normatively, is digital signature; this is what you are saying! I.e., that document would only contain Linked Data Signature normatively!

There is something that I seem to fundamentally misunderstand but, I am afraid, others will also misunderstand it big time...

from rch-wg-charter.

Maybe... something that I have said before.

The essence of the work is canonicalization of the graph, then a specification on how the n-quads of the canonicalized graph are precisely ordered in order to hash it. Ie, a graph hash function.

What if the second document stops there: it "just" defines the proper hash function which is then used for all kinds of things. We know that this can be used by itself, without signatures (see the use cases).

Then we have a separate document which we call LD Proofs (or something similar). That document has only one normative section, which is the definition of a signature for graphs, and a number of other, non-normative sections for different other possible proof mechanisms (whatever they are) with an eye on future standardization.

Ie, the list of deliverables consists of four documents (at least conceptually, remember that we can reorganize those in the WG) which more clearly separates the layers.

from rch-wg-charter.

My question is then: what else would the document entitled "Linked Data Security (LDS)" contains normatively?

Minimally, I expect us to talk about how to define an LD proof:

https://w3c-ccg.github.io/security-vocab/#proof

And express how it needs a type, and should have a proofPurpose, etc. We would then define digital signature types and how those work/what those express and what the constraints are. We would also say that type is an extension point for others to create non-standard, non-digital signature proof types of their own.

from rch-wg-charter.

Then we have a separate document which we call LD Proofs (or something similar). That document has only one normative section, which is the definition of a signature for graphs, and a number of other, non-normative sections for different other possible proof mechanisms (whatever they are) with an eye on future standardization.

Precisely -- which is why the language is "proofs" not signatures at the lowest layer. We're defining how to do an LD proof -- and specifying the first normative example of such a proof: a digital signature. We're also saying that if others want to create their own non-standard LD proofs, where the extension points are. We can non-normatively discuss other possible proof types (such as proof of work, proof of existence, etc.) and express that those proofs may use the hash that is defined normatively as an input to their machinery and/or as part of their expression.

from rch-wg-charter.

huge -1 to binding to "signatures".... what we are really interested in here is a stable canonical representation that can be content addressed / hashed.... yes, signatures use hashing... but stable hash-able data structures exist without RSA / EC... etc... for example, in IDS / IPS auditing scenarios.

I would focus more on hashing, rather than signatures.

I might even suggest Linked Data Integrity, Linked Data Hash.

or even more controversially: Linked Data Canonicalization

If the intent is to cover a vocabulary that can go along with canonicalization that supports common cryptographic concepts:

Linked Data Security or Linked Data Cryptography would seem appropriate.

I imagine folks will more often abbreviate this as LD-Sec...

another one for the bikeshed:

Verifiable Data Security

from rch-wg-charter.

Then we have a separate document which we call LD Proofs (or something similar). That document has only one normative section, which is the definition of a signature for graphs, and a number of other, non-normative sections for different other possible proof mechanisms (whatever they are) with an eye on future standardization.

Precisely -- which is why the language is "proofs" not signatures at the lowest layer. We're defining how to do an LD proof -- and specifying the first normative example of such a proof: a digital signature. We're also saying that if others want to create their own non-standard LD proofs, where the extension points are. We can non-normatively discuss other possible proof types (such as proof of work, proof of existence, etc.) and express that those proofs may use the hash that is defined normatively as an input to their machinery and/or as part of their expression.

@dlongley should I read your reply as agreeing with a restructuring of the deliverables into four entries instead of three to more clearly separate the concerns (see my comment in #47 (comment))? I am happy working on a PR on Monday if that is the case; it may be easier to continue this discussion on something written down...

from rch-wg-charter.

@OR13, as I proposed in #47 (comment), I will come up with a PR next week. My current thinking is more in favour of "Linked Data Hash" and "Linked Data Proof", but let me see how the various pieces fit together.

My intention is to be as specific as just possible; let us remember that the AC reps who will, eventually, vote on this charter do not know the details, things must be crystal clear...

from rch-wg-charter.

@iherman,

I read your reply as agreeing with a restructuring of the deliverables into four entries instead of three to more clearly separate the concerns...

Yes, I'm ok with that as a conceptual basis for the deliverables that better separates concerns.

from rch-wg-charter.

Clearly, "Linked Data Security" is too general (and might give wrong expectations), and "Linked Data Signature" is too restrictive.
"Linked Data Cryptography" (proposed by @OR13 ) sounds appropriate but may give the impression that the WG will create new crypto functions, which is not the goal.
From what I read above "Linked Data Proofs" sounds good to me -- all the more that it is already the title of the CG report that is expected to be used as input...

from rch-wg-charter.

I will (probably) use the terms "Linked Data Hash"

Hmm... -1 to "Linked Data Hash" -- we're not defining a hashing function (SHA-256, Blake 2, etc.). We're defining a RDF Dataset Canonicalization algorithm and a way to ensure the integrity of Linked Data.

from rch-wg-charter.

Linked Data Integrity Canonicalization?

from rch-wg-charter.

Yeah +1 to the idea that Linked Data Signatures is too narrow and instead that there are a broader range of cryptographic techniques we want this work to apply to.

As another example, the work around BBS+ doesn't fit well into the "signatures" bucket entirely either, for instance the BbsBlsSignatureProof2020 is not actually a proof block describing a digital signature but instead a proof of knowledge of a signature that remains unrevealed for correlation reasons.

from rch-wg-charter.

There is a PR, based on the discussions so far, on #56.

from rch-wg-charter.

Thanks for poking on this some more and, IMHO, getting some more clarity.

from rch-wg-charter.

#56 has been merged... closing

from rch-wg-charter.