search

w3c / rch-wg-charter

Charter proposal for an “RDF Dataset Canonicalization and Hash Working Group”
https://w3c.github.io/rch-wg-charter/
Other
12 stars 7 forks source link

Change name of charter to "Linked Data Security" #4

Closed msporny closed 3 years ago

msporny commented 3 years ago

This WG could standardize the following things over multiple iterations. For the sake of this issue, let's call these phases.

Phase I Specifications

Phase II Specifications

Phase III Specifications

We should name the WG such that it can easily be rechartered to handle each of these phases.

iherman commented 3 years ago

While I agree with the goals, I am a bit worried about the choice of the name v.a.v. the AC vote. The AC votes on the content of this charter, and if there is no reference to those further phases then we may face a push back. On the other hand, referring explicitly to those phases in the charter may generate push backs again. It looks like a source of problems whichever way we do this.

Why is it a problem if, in a later stage, we change the name of the Working Group? We would have to go through rechartering anyway. (Eg, the 'maintenance' version of the Publication Working Group is now called Audiobooks WG, due to change in focus.) The only thing we would have to be careful about is to choose the WG's 'short name' when we set up the WG's home page, repository names, etc, because changing those in the future might create a mess.

iherman commented 3 years ago

The only thing we would have to be careful about is to choose the WG's 'short name' when we set up the WG's home page, repository names, etc, because changing those in the future might create a mess.

Incidentally... 'lds-wg', 'lds-spec', etc, is a perfect fit...

msporny commented 3 years ago

The AC votes on the content of this charter, and if there is no reference to those further phases then we may face a push back. On the other hand, referring explicitly to those phases in the charter may generate push backs again. It looks like a source of problems whichever way we do this.

Yes, I agree that all of that is a problem. I do want to make it clear during these early stages that it is expected that this isn't the end of the road... there is future work contemplated and we're aggressively scoping on purpose. Perhaps the place to do this is in the explainer.

Why is it a problem if, in a later stage, we change the name of the Working Group?

We went through this for the "Verifiable Claims WG" => "Verifiable Credentials WG" transition. It was painful getting people to change the name and how they talked about the technology. We /do/ want people to talk about "Linked Data Security"... not necessarily "Linked Data Signatures". It's more of a long-term strategic/language concern... but we made the wrong decision wrt. "Verifiable Claims" and I didn't want us to make that same mistake here.

That said, I agree with you that we can probably figure out a way to message both without risking the charter.

Incidentally... 'lds-wg', 'lds-spec', etc, is a perfect fit...

Yes, I agree that in this case, we lucked out with the "lds" shortname. :)

iherman commented 3 years ago

It's more of a long-term strategic/language concern...

Maybe it is worth adding a separate section into the explainer document, spelling out the longer term goals. That does not bake in the charter and makes it o.k., but makes the situation clear to those who really care about this area.

iherman commented 3 years ago

We went through this for the "Verifiable Claims WG" => "Verifiable Credentials WG" transition. It was painful getting people to change the name and how they talked about the technology.

I think this analogy is actually not a good one. Although the VC name change was indeed a problem and, I must admit, I still get it wrong sometimes. But, as far as I could see, what happened there was that essentially the same technology was renamed and the WG had to follow because the technology name was reflected in the WG's name. This isn't the case here. We may have a longer term goal, which is to have LD security reinforced but, as you yourself made it clear, this is done in phases. This WG is only the first phase, essentially one of the basic building block. The next WG may bear another name, depending on what we will plan to do in two years, it may be LD Security if it takes on Phases 2 and 3 in one step… let us leave this open.

msporny commented 3 years ago

The next WG may bear another name, depending on what we will plan to do in two years, it may be LD Security if it takes on Phases 2 and 3 in one step… let us leave this open.

I spoke with @dlongley about this... he agreed that saying "Signatures" for the WG would send the wrong signal. What if we combine the "Linked Data Proofs" and "Linked Data Signatures" specification into one specification called "Linked Data Security"? The work really is not ONLY about digital signatures, it's about a way of canonicalizing a graph and providing security around it (one form is a digital signature, but calling that out explicitly puts the focus on the wrong thing).

So, what about:

Phase I Specifications

iherman commented 3 years ago

I believe per #12 (which has been merged) the issue is settled; closing.