security-vocab

security-vocab copied to clipboard

Related to point 3 raised by Manu in PR #70

tagging @msporny @peacekeeper @tplooker @dlongley and @OR13 to get this conversation going

EcdsaKoblitzSignature2016

GraphSignature2012 LinkedDataSignature2015 LinkedDataSignature2016

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: EquihashProof2018 equihashParameterK equihashParameterN

For the JsonWebKey2020/JsonWebSignature2020 overlap I see we would drop RsaVerificationKey2018 and RsaSignature2018 (@peacekeeper is that an issue for you. I know you've been testing against it)

I'm unsure which other ones we'd want to drop as well Ed25519Signature2020? Any advice on this aspect from @OR13 would be useful.

Not sure regarding Ed25519Signature2020.... we could reserve it... we might also reserve https://github.com/decentralized-identity/SchnorrSecp256k1Signature2019 which nobody has implemented.

I see we would drop RsaVerificationKey2018 and RsaSignature2018

Hmm I don't think RsaSignature2018 should be removed.

If your argument is that JsonWebSignature2020 can replace it... Well then you could make the same argument for removing Ed25519Signature2018, Ed25519Signature2020, EcdsaSecp256k1Signature2019, etc., but I don't think anyone is suggesting that.

we might also reserve https://github.com/decentralized-identity/SchnorrSecp256k1Signature2019

I originally added SchnorrSecp256k1Signature2019 to the DID context in https://github.com/w3c-ccg/did-spec/pull/207. One of the arguments for reserving it, even though nobody had implemented it at that point, was that the same key could be used for Schnorr and ECDSA signatures, therefore they should both be defined in the context.

@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 EcdsaSecp256k1VerificationKey2019 AND SchnorrSecp256k1VerificationKey2019.

Since ethereumAddress is deprecated in favor of blockchainAccountId, maybe that should be dropped as well.

A second argument for removing ethereumAddress would be the discussion around brand names we had in DID Core (see https://github.com/w3c/did-spec-registries/pull/73).

Finally, since it's not in v2 anyway, we wouldn't really be "dropping" it, just not adding.

@awoie given you added ethereumAddress curious what your thoughts are on that change?

I second not adding ethereumAddress it seems like an attempt to shoehorn credibility to a project that doesn't scale technologically or economically and likely won't exist in 5 years.

I second not adding ethereumAddress it seems like an attempt to shoehorn credibility to a project that doesn't scale technologically or economically and likely won't exist in 5 years.

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.

@peacekeeper hmmm, i feel like @msporny would hate the same key type being used for 2 signatures.

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.

@awoie given you added ethereumAddress curious what your thoughts are on that change?

IMO, everyone should use blockchainAccountId as it is more generic. We also migrated from ethereumAddress to blockchainAccountId. I'm not aware of any DID method that still uses ethereumAddress, so I'm fine with removing it.

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.

This means there will be a CCG Ethereum-specific context? That would be great since we are also working on the EthereumEip712Signature2021 and I think that would be a nice place to host the specific context definitions.

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.

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.

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.

value judgement

Not interested and no time for flame wars btw.

@msporny thanks for the responses

If folks want a term in the security vocabulary, and it's not actively harmful, then they tend to get it

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

I was not making a value judgement for a project

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 ethereumAddress in favor of blockchainAccountId anyway, so folks on both sides of the argument should be happy. :)

as a non-maximalist

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 ethereumAddress term because the relevant information I need to know about it has been answered.

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.

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

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.

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

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 blockchainAccountId and I plan to remove it when this ticket reaches the top of my todo list.

An address itself is not a for profit product

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

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

+1 I think everyone can get behind this resolution, perhaps for different reasons

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

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 ethereumAddress just like they do for ActiveX and Floc :)

+1 I think everyone can get behind this resolution, perhaps for different reasons

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.