Comments (7)
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.
from rch-wg-charter.
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...
from rch-wg-charter.
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. :)
from rch-wg-charter.
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.
from rch-wg-charter.
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.
from rch-wg-charter.
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
- RDF Dataset Canonicalization (Algorithm) - Used to take an RDF Dataset as input and canonicalize it to a deterministic output in NQuads format.
- Linked Data Security (Algorithms and Vocabulary) - Used create and verify mathematical proofs (algorithms) on a canonicalized dataset and express the algorithm inputs/outputs (vocabulary) and a mechanism used create and verify concrete digital signatures (algorithms) on a canonicalized dataset and express the algorithm inputs/outputs (vocabulary).
from rch-wg-charter.
I believe per #12 (which has been merged) the issue is settled; closing.
from rch-wg-charter.
Related Issues (20)
- AUEB/MMlab supports the W3C LDS WG HOT 3
- Jolocom supports the W3C RCH WG HOT 5
- Create a registry of hash functions HOT 3
- Semmtech supports the W3C RCH WG HOT 4
- Rename "Linked Data Hash" as "RDF Dataset Hash" HOT 1
- A is B considered harmful HOT 6
- Need a glossary for the acronyms the lds-wg-charter HOT 1
- ED of explainer points to charter doc. HOT 1
- W3C Web of Things (WoT) WG supports the W3C LDS WG HOT 8
- Vague mentions of json-ld context work item needs clarification HOT 25
- 3 Round Stones supports the W3C RCH WG HOT 5
- Vrije Universiteit Amsterdam supports the W3C RCH WG HOT 5
- Coordinate with WebAppSec HOT 6
- Consider defining a canonical serialization to bytes, rather than a hash HOT 5
- Stale expressions of support HOT 1
- quantifier scoping HOT 3
- bad terminology in explainer document HOT 9
- status of [arnold-longley-2020] HOT 19
- how the canonicalization algorithm is chosen HOT 3
- fix HTML title
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rch-wg-charter.