-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which properties should we drop from V3 context that are unused now? #72
Comments
tagging @msporny @peacekeeper @tplooker @dlongley and @OR13 to get this conversation going |
EcdsaKoblitzSignature2016 GraphSignature2012 privateKeyPem (all private members to be moved to a new context with -private postfix.) |
Agree with removing the ones mentioned by @OR13 above. This seems consistent with the fact that none of those are listed at https://w3c-ccg.github.io/ld-cryptosuite-registry/ anymore. |
@msporny mentioned dropping all the equihash parameters and ones covered by JsonWebKey2020 as well. So that would remove for: For the I'm unsure which other ones we'd want to drop as well |
Not sure regarding |
Hmm I don't think If your argument is that |
I originally added |
@peacekeeper hmmm, i feel like @msporny would hate the same key type being used for 2 signatures. |
@OR13 exactly, that's why we added BOTH |
Since A second argument for removing Finally, since it's not in v2 anyway, we wouldn't really be "dropping" it, just not adding. |
@awoie given you added |
I second not adding |
Hey folks, just a reminder that making value judgements about a project is not what this repo is used for. If folks want a term in the security vocabulary, and it's not actively harmful, then they tend to get it. The v3 context is a general purpose context, and there is a new movement afoot to move specific cryptosuites out into their own context... case in point, the Ed25519 stuff is moving out into its own context: https://w3id.org/security/suites/ed25519-2020/v1 I expect the same thing to happen with Ethereum-related things... so, this isn't a zero sum game. Everyone can get what they want. The Ethereum people can go Ethereum their heart out in their context... the Bitcoin people can go Bitcoin their heart out in their context... and the stuff that is useful to both communities can go in the v3 context. Just trying to head off a flame war before it happens -- we don't need to have it, everyone can get what they want because we designed the technology to avoid zero sum games. |
Hate is a strong word... :) -- be deeply concerned, yes, due to the complexity it adds to the security code paths. It's not slap your forehead horrible, but it does add potential attack surface that we could try to avoid. |
IMO, everyone should use |
This means there will be a CCG Ethereum-specific context? That would be great since we are also working on the |
I agree with moving specific cryptosuites out into their own context (e.g. for Ethereum-related things), and I also agree with removing things such as "ethereumAddress" (from the unstable v3 context) if they aren't actually used by anybody. |
I was not making a value judgement for a project, just attempting to point out the fact that the ethereum project directly violates W3C's purpose as a vendor-neutral consortium committed to royalty-free standards, which the Ethereum foundation is not. They are a for profit organization, that is generally given more credibility than they deserve. |
Not interested and no time for flame wars btw. |
@msporny thanks for the responses
Does this not open the door to product placement, and vote stuffing? I think the security vocab, would benefit from just being about security. So sign, encrypt, decrypt. Stick to neutral, non controversial, terms To my mind ethereum is a for-profit product. And that's problematic regarding neutrality and royalty-free, especially as it moves closer to w3c recommendation status |
https://en.wikipedia.org/wiki/Value_judgment :) -- I'll leave it there (as a non-maximalist for all blockchain projects). It looks like we're dropping |
Of course, this was tongue in cheek, however I'd possibly avoid using terms such as 'maximalist', as they can be inflammatory. It implies a degree of close mindedness, which I dont think is the case here Hopefully the thrust of what we are discussing is more around 'fit', than 'values', and I think that's the best way to interpret the comments so far I welcome the move to move ethereum terms into its their own context, and remove from security vocab v3 I think the security vocab is stronger for it, and less likely to attract push back |
@JLSchuler99 Your point is taken. The purpose of this ticket is to identify unused properties and to remove them. Why they're used is not a matter of relevance to me or this topic and is not very helpful for me to get this issue closed. If you wish to provide constructive feedback about an implementation or a particular term that's causing a problem for your usage of the security-vocab please continue to do so. With that in mind, lets stop discussing the Also as a reminder, I cannot take into consideration substantial comments from members who have not signed up for the CCG group as this is an official CCG work item. Please remember to sign up for the CCG group if you're going to contribute here. |
This is a relevant, constructive argument about why the term should be removed that helps me. Thank you for moving the discussion forward in a focused way. |
An address itself is not a for profit product, nor is it encumbered by a patent. It can be generated for free. That's all this term is about. Given this is about an RDF predicate the question should really be about whether this predicate is the right way to model the semantic ontology. From the looks of it, we've decide it's an cumbersome, non-generic term and leads to a bad pattern in terms of semantics. That argument plus the fact that the term is not in use is good enough reason for me to believe that the term should be removed in favor of |
An ethereum address is fundamentally linked to the ethereum platform. So there could be a branding mismatch, as ethereum is often perceived as a for-profit platform. And the W3C is often perceived as incubating royalty free standards When the W3C and the web were created, it was competing with another protocol, gopher. As timbl describes in a few of his talks, the major thing that allowed the web to overtake was a perception that gopher might one day not operate in the spirit of a royalty-free protocol. Gopher didnt actually charge royalties at that point, just there was just the hint that one day they might There is analogy with ethereum with the large premine, and essentially moving assets from one address to another could possibly to be at the cost of a fee to large stake holders (those holding c $100,000 or more) The last thing we want is for people to create protocols, put a tax on them, and then try and proliferate them through the internet via W3C standards There is also the issue of groups being used for product placement. For example, why was ethereumAddress included and not bitcoinAddress, when bitcoin is the larger eco system. It looks like playing favourites So, having such terms in the vocab, imho, is problematic, in that it could attract push back, especially for items, that aim to transition to standards track
+1 I think everyone can get behind this resolution, perhaps for different reasons |
The ultimate tax is creating semantic disambiguity by creating new representations of existing unambigious terms. I'd be careful trusting anyone to build a vocabulary that was not filled with bias at this point, especially the W3C... That being said, the ethereum community demonstrated a remarkable inability to foresee these standards problems, and is getting punished in a way that will hopefully discourage others in the future.... The concept of a "crypto currency address" is relatively new, its not a public key and they tend to be bound to specific networks... so when referring to them, you tend to need to invoke the name of the network... Its a bit like trying to describe iOS or Android apps without acknowledging that Google and Apple exist... Perhaps the W3C has figured out a way to make the web work without relying on for profit corporations? Certainly, public permissionless blockchains have :) This comment is mostly trolling.... I suggest we remove essentially every term from sec-3 that is not required to produce a Linked Data Proof... and let people use extensions for |
I had a huge long post responding to each of your points, but let's just leave it at this. |
I don't know what the status is of this work at this point and I'm unlikely to get around to updating this, so I'm going to unassign myself from this work. |
Related to point 3 raised by Manu in PR #70
The text was updated successfully, but these errors were encountered: