Re: [sds-wg] Reminder and Agenda for Confidential Storage Spec Call - Feb 25 2021

The lack of use-cases makes reaching consensus much harder since all we
really have to build on is the charter.

I spent some time today categorizing my personal data relationships and
started a Use Cases document

Please edit or add to the categories from your perspective and also add use
cases. I would like to discuss the authorization perspective in a call.

If it is helpful to separate our work into EDVs and Hubs, then this thread also tries to address
the authorization protocol(s).

- Adrian

On Sun, Feb 28, 2021 at 10:24 AM Manu Sporny <>

> On 2/27/21 8:55 PM, Chris Were wrote:
> > I could break down the list we have discussed over the past few weeks
> and
> > point to the relevant section of CouchDB documentation that addresses
> those
> > requirements.
> Yes, this is a next step. Ideally, we'd map every feature in the spec
> today to
> CouchDB documentation. Chris, it would be good for you to volunteer to do
> this
> since you seem to be the one most driven to demonstrate that this is true.
> It's something we're going to have to document in time anyway, to
> demonstrate
> why the work needs to be done (or that W3C shouldn't waste their time on it
> because... CouchDB exists).
> Once you document it (not just the list of requirements we've been going
> over
> during the last month, but all the features in the existing spec as well),
> we
> can review it as a group to see if there is consensus.
> Zooming out a bit to look at the big picture... thinking about how SQL was
> standardized may help. SQL was first standardized by ANSI in 1986... but
> there
> were databases on the market for years that had the "relational database"
> feature set... relational databases existed in 1970, 16 years before the
> /first/ standard existed. SQL has been standardized ever since.. with the
> most
> recent version being SQL:2019. That's 35 *years* of standardization! Why
> are
> we still standardizing it!?
> To replay your point back to you, but in a different context:
> MariaDB (a popular open source relational database) covers many of the
> common
> use case needs for relational databases... so why do we need an SQL
> standard?
> With that in mind, some thoughts on the questions you asked:
> > This process feels like attempting to reinvent the wheel and produce a
> > sub-par outcome.
> It always feels like that at first... like you're rubbing two sticks
> together
> to create a fire when we already have nuclear power plants. Why don't we
> just
> build a nuclear power plant? (Answer: there is no single specification on
> how
> you build one and some of the skills are so specialized that it's out of
> the
> reach of 99.99% of the population, which is not a good number if you're
> trying
> to document and teach people how to do something).
> The process of standards are not to innovate (at least, not primarily).
> It's
> to look at everything that's out there and try to standardize the simplest
> set
> of technologies that fit a Pareto distribution... that is, what 20% of
> features meet 80% of the use cases. The goal isn't to get the standard to
> support 100% of all use cases.
> > I understand CouchDB is not a specification, but as an implementation
> it's
> > pretty darn close to what we're looking for.
> I have a vague concept of what your requirements are, Chris. :) I'm sure
> you
> don't have a solid concept of what Digital Bazaar's requirements are...
> or Transmute's... or SecureKey's... or Microsoft's... or Michael's. We're
> just
> scratching the surface, these discussions take a LOOOONG time to get to a
> basic understanding on everyone's *public* use cases.
> ... but the way we get there is to talk about it, and documentation of the
> sort you're talking about is vital to that process.
> Thoughts?
> -- manu
> --
> Manu Sporny -
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#83):
> Mute This Topic:
> Group Owner:
> Unsubscribe:
> []
> -=-=-=-=-=-=-=-=-=-=-=-

Received on Sunday, 28 February 2021 19:14:44 UTC