Re: Chartering work has started for a Linked Data Signature Working Group @W3C

Melvin Carvalho wrote:
> However, IMHO the referenced material is not quite ready to go to a WG, 
> just yet
> 
> Let's take the 4th deliverable:
> 
> Linked Data Security Vocabulary (LDSV)
> 
> This has a normative reference on : 
> https://w3c-ccg.github.io/security-vocab/
> 
> "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"

This language is *very old* and needs updating... but that's the sort of thing
you do in a WG. The language is in the general ball park, which is typically
all that is required of input documents to a WG.

> Brilliant, so far, so good!
> 
> However, looking at the terms inside this vocabulary.  The scope is bigger 
> than simply just encrypt, decrypt and sign

Yes, but only slightly... and again, that is a topic for discussion in a WG.

Remember that this vocabulary is largely a registry of things people have
implemented... it's called the "Security Vocabulary", not the "Just
Encryption, Decryption, and Signing Vocabulary". There are some nuanced
decisions that might need to be made in a WG... but that's not a good reason
to block the work by saying the document isn't ready to be used as an input
document.

> For example, the normative vocab includes a term, shoe-horned in, 
> ethereumAddress, without including, for example bitcoinAddress.  This is 
> highly controversial.  Why include one and not the other.  Surely it is 
> better to include neither in a generic vocabulary:

Sure, if we were starting from scratch and didn't have 8+ years of history
there, I'd agree. However, the vocabulary is meant to reflect the state of
affairs as they are now, warts and all. The good news here is that there is
probably agreement to avoid terms like ethereumAddress and bitcoinAddress
moving forward. That doesn't change the fact that people registered those
properties and we need to do something about them (most likely deprecate them
and place them into a clearly marked "Deprecated Terms" section).

There are A LOT of properties in the security vocabulary, and cherry picking
one property, stating that "it's controversial", and using that as a reason to
not use the document as input to the WG is problematic. The W3C Members don't
like taking fully formed and inflexible documents as input into WGs... because
then the W3C becomes a rubber-stamping exercise (and no W3C Member that I know
of is supportive of that approach).

If the WG doesn't have a Vocabulary document, then where do the other items go
that are necessary to do the things you want to do? Where do we define those
terms in a way that supports the ecosystem that's been built over the past 8+
years? We need a vocabulary of some kind... we can argue about the status of
certain terms in that vocabulary, and whether they should be deprecated or
kept, but that we need a vocabulary remains.

Input documents don't need to be perfect to be useful.

> This is the kind of thing that could blow up in the face of the W3C. 
> There's approximately 100 million users, with skin in the game, that might 
> see the W3C as picking favourites here.  Given the way social media works, 
> that could spark some objections from large ecosystem, including some of 
> the best and most cited cryptographers in the world

Statements like that are hyperbolic fear mongering.

If there are 100 million people that want to see *any* feature in the
vocabulary and they implement that feature, and it doesn't cause harm, we
register it; it doesn't have to be any more complicated than that.

However, if we have something like "blockchainAccountId", which we do have today:

https://w3c-ccg.github.io/security-vocab/#blockchainAccountId

... and we have convinced the Ethereum community to move over to that, then we
avoid the debate entirely. Just use "blockchainAccountId"... it supports your
use case... it's not blockchain-centric... done. :)

> I've raised an issue on this here:
> 
> https://github.com/w3c-ccg/security-vocab/issues/110
> 
> So, IMHO the normative references could benefit from a bit of work, to
> make them less controversial, before going to WG

As it has been explained in that issue you raised, this isn't controversial
any more... everyone seems to be moving over to "blockchainAccountId"... even
the Ethereum folks... and the Bitcoin folks haven't asked us for a
"bitcoinAddress" property... ever, AFAIK. If they were to do so today, we'd
ask them to use "blockchainAccountId"... but that would actually need to
happen, and as I mentioned before... it hasn't.

The only controversy here is the issue you raised, Melvin, asserting that
there is controversy. :)

There are 77 properties listed... you picked one, which is already well on its
way to being deprecated, and went hyperbolic with it as a reason that the work
item isn't ready for a WG yet. I have, hopefully, explained why your initial
read on the situation was misinformed.

Given the above, Melvin, do you see any reasons why we shouldn't use this
document as an /input document/ to an LDS WG?

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Thursday, 3 June 2021 15:43:48 UTC