search

w3c-ccg / security-vocab

The Linked Data Security Vocabulary
https://w3id.org/security
Other
20 stars 21 forks source link

Consider moving controversial terms into an extension vocab #110

Open melvincarvalho opened 3 years ago

melvincarvalho commented 3 years ago

The Security vocabulary is used to enable Internet-based applications to encrypt, decrypt, and digitally sign information expressed as Linked Data. It also provides vocabulary terms for the creation and management of a decentralized Public Key Infrastructure via the Web

Love the idea and would like to reuse the cryptographic primitives in this vocab for linked data related projects

However, some terms, in particular, ethereumAddress, would be considered highly controversial in the cryptographic community. One of the reasons for this is that it had a premine (some estimates as high as 70%), making it not as appropriate as some in royalty-free standards

This is a wide ranging sentiment, spanning, I would guess, dozens of thought leaders, 100s of companies, 1000s of cryptographers, millions of users, and 100s of billions of dollars in investment

In contrast, terms such as publicKeyPem, are uncontroversial, have a wide range of use across the web

The nature of web documents is that you cant take one term without pulling in all of them. So in a smart semantic agent (e.g. like tabulator and derivatives) which has auto complete on predicates, as soon as you type some characters, it would pull in the predicate, making an end user perhaps think that ethereum addresses were endorsed. One would have to code round this, to remove those terms, or instead fork the vocab creating a duplicate of effort

The vast majority of terms in this vocab are imho completely uncontroversial. Could we consider moving the more controversial ones to its own extension vocab, as linked data was designed for. Similar approaches have been taken by sioc and schema.org etc.

I suspect focusing on a core set of uncontroversial predicates (to encrypt, decrypt and digitally sign) may be a way to get this and related work through the standards process more quickly and easily. The main purpose in raising this issue is to try and gauge the future direction of this vocab, as we decide whether to reuse to avoid duplication of effort

peacekeeper commented 3 years ago

Just a few quick pointers regarding ethereumAddress:

melvincarvalho commented 3 years ago

@peacekeeper thanks for the pointers. I have upvoted https://github.com/w3c-ccg/security-vocab/issues/72#issuecomment-785436460

JLSchuler99 commented 3 years ago

I'm not sure why you refer to the premine data as if it were a conspiracy, or speculation. All the data is public, but only for those who care to look. At the time of launch 72million ethereum were premined, representing 100% of all coins. Now 6 years later, 116million total ethereum exist, meaning over 62% of all Ethereum existed today we're given to developers and investors. Less than 38% given to the miners expending electricity in order to process and secure the networks for more than half a decade. To make this even worse the developers plan to change the minting method away from mining (work) to staking. Meaning those with the large majority of coins (developers) will be able to acrue the majority of new tokens without any work. Does this sound like solid economics to anybody?

melvincarvalho commented 3 years ago

@JLSchuler99 thanks alot for the break down, I wasnt aware of those exact figures

The W3C is (or at least aims to be) a vendor-neutral consortium committed to royalty-free standards

So, aside from the economics, there would be to my mind the topics of vendor neutrality, and whether the ethereum protocol is in the spirit of the royalty-free type standards that the W3C tries to incubate

There is also the issue of partisanship, for example, it may be reasonable to ask, why is it that ethereumAddress would be included, and not, bitcoinAddress

As this is a normative input to work that hopes to be escalated to working group status, and eventually W3C Recommendation, it might be a more optimal path to move more controversial terms into an extension

For the record, I dont personally think that ethereum is a royalty-free protocol, but rather, more like a proprietary product, security offering, and branded product. I appreciate views may vary on that one!

JLSchuler99 commented 3 years ago

@melvincarvalho thanks! I'm glad that I could help to shed light into the issue. To reinforce your concept of it being more similar to a product or a security, I'll include one more point. Unlike a Proof-of-Work protocol like Bitcoin, where anybody with a turing complete processor is capable of participating in the protocol, a Proof-of-Stake system (which ethereum is already in the process of transitioning to) REQUIRES that new participants purchase tokens from existing users (62% of which originate from the premine).

kdenhartog commented 3 years ago

Remember the purpose of this term. It's purely focused on whether or not the semantics of the RDF predicate are valuable. Other considerations are barely relevant because the term is merely looking to provide a semantic predicate of a string of text. It wouldn't make sense to make the RDF predicate aBrandWhichMustNotbeNamedAddress because that produces a horrible semantic ontology. Given the fact that an address is not patented, unencumbered by royalties, and free to produce I don't see how the arguments made to date are relevant to the term. Instead it seems like we're conflating political discussions with technical semantic discussions. What am I missing?

melvincarvalho commented 3 years ago

I had a go at answering why this term might be viewed as controversial here:

https://github.com/w3c-ccg/security-vocab/issues/72#issuecomment-855396037

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

Given that the controversial term is being removed, that would be a satisfactory resolution. I'm definitely more likely to reuse this vocab

Happy to close this issue, or to perhaps explain why this term is controversial, when viewed by a broader audience

As an aside, as this work progresses, I do think it would benefit from review from the bitcoin community, which contains some of the best cryptographers in the world