OR13
commented
4 years ago cc @dlongley @msporny
Open OR13 opened 4 years ago
OR13
commented
4 years ago cc @dlongley @msporny
dlongley
commented
4 years ago I don't think we should name the spec after the group -- it makes it seem like there will only be one spec coming out of the group which may not be true, particularly with a layered approach. I'm happy with the name "Encrypted Data Vaults" for the current layer that the spec we have so far is targeting.
OR13
commented
4 years ago I agree we should not name the spec after the group, unless we are only going to do 1 spec.
I would be ok with naming the spec "Encrypted Data Vault" and the implementation "Encrypted Data Vault", as long as we agree that this layer only applies to encrypted only, and that we will build a "Secure Data Store" or some higher level layer on top of it, and that we will have unique names for those layers... for example:
This raises questions about multiple specs vs specs with multiple layers.... and how that may or may not harm our ability to move things forward to W3C....
I would rather us not have the implementation and spec names differ significantly.
If there is a hint (and there is) that we might want to change the name later, I suggest we tackle this asap...as it will cause a lot more damage the longer we wait to do so.
cc @tplooker
In summary here are my preferences:
dlongley
commented
4 years ago Given that we're taking a layered approach, I would expect implementations to be named after the layers that they provide -- and that we can plug and play. So +1 to that aspect. I don't think it's a problem to have multiple specs to transition and it keeps the parts clean. Even if we did go with a single spec, I would expect there to be internal layers -- including the "Encrypted Data Vault" layer, after which implementations of that layer could derive their names.
msporny
commented
4 years ago Digital Bazaar agreed to the name of the group being Secure Data Storage WG... we didn't think it was a good idea to name the EDV part of the spec that.
We're fine w/ layering the spec and keeping the entire thing called EDVs. We're fine w/ two specs where the lower layer is called EDVs and the higher layer is called "Identity Hubs" (or something else). We are concerned about two specs being named slightly different things because people will get confused. We already have people replacing "Encrypted" with "Enterprise" and other things... and people don't really know what an "Identity Hub" is, because it hardly has anything to do with Identity and more to do with storage. Soooo, all of these options may be ok:
We would specifically NOT be ok with:
OR13
commented
4 years ago ^ I think it's very wise not to bring the concept of "Identity" into the name... for a very large number of reasons...
Let me revise my proposal:
gannan08
commented
4 years ago ^ I think it's very wise not to bring the concept of "Identity" into the name... for a very large number of reasons...
Let me revise my proposal:
- 1 spec, 1 implementation "Encrypted Data Vaults", layers internalized.
- at least 2 specs, 2 implementations , first layer "Encrypted Data Vaults", second layer "Decentralized Data Hub / Secure Data Hub"
I am in agreement with the proposal. If there is consensus, then I can make the PR.
OR13
commented
4 years ago This clearly needs more discussion, we don't have anything close to consensus... hopefully we can hit this issue in review at some point.. cc @csuwildcat @tplooker
msporny
commented
4 years ago This clearly needs more discussion, we don't have anything close to consensus.
What!? Three people sort of agree... I was promised Swift Justice at DIF! What is this consensus mumbo-jumbo -- that's what those people over at W3C do... commit early and often! :P
agropper
commented
4 years ago I propose we name our work: Secure Data Storage.
OR13
commented
4 years ago @agropper which work?
We have to name the spec, and the software that implements the spec (reference implementation software name).
Is this your proposal?:
Working Group: Secure Data Storage Spec Name: Secure Data Store Ref Impl: Secure Data Store
I think the other proposal is:
Working Group: Secure Data Storage Spec Name: Encrypted Data Vault Ref Impl: Encrypted Data Vault
agropper
commented
4 years ago Definitely Working Group: Secure Data Storage Spec Name: Secure Data Store Ref Impl: Secure Data Store
I propose we avoid encrypted data vault because different use-cases will secure the store in other ways. Zero-trust architecture might be a useful reference.
dlongley
commented
4 years ago I propose we avoid encrypted data vault because different use-cases will secure the store in other ways.
I would think that different use cases may do additional things, but what happens at the lowest layer with Encrypted Data Vaults would always be there. Similar to "always use TLS" -- but that says nothing about what else your application is doing. Perhaps the naming should be such that a "Secure Data Store" represents a number of different configurable software components, whereby Encrypted Data Vault servers and clients always play the lowest level storage roles and Agents/other components play other higher-level roles.
csuwildcat
commented
4 years ago I personally feel Encrypted Data Vaults is too specific, and lasers in on one facet of the datastore that some entities may not even use. For example: if I run one of these for some public agency, all the data on it may be public info that I am publishing in a semantically locatable dataset for others to freely consume. I also starting to feel uncomfortable with a few things about this: I purposefully didn't impede EDV being the main input to the spec because I didn't want to obstruct progress, but now we're talking about calling the end result EDV, and people are talking about components of EDV as if there's not going to be lots of churn and reassessment - this should be a well-informed clean slate.
As such, I would propose the following names:
'Secure' can encompass all configurations, because objects may or may not be encrypted, but they certainly will be secured by DIDs and a permissioned-capability access layer. 'Storage' also implies the concept, while 'Store' is an actual noun, which lends itself to being the implemented Store of the Storage spec's concepts.
agropper
commented
4 years ago +1 @Daniel's naming proposal and most of the logic but I don't see the "certainly will be secured by DIDs".
A secure data store, like any data processor, does have some interface to an access control process. The data processor relationship to its access controller is as a policy enforcement point vs. a policy decision point.
Decentralized identifiers might refer to the data subject in the Store or to the controller / policy decision point. The protocol between the PEP and PDP may benefit from the DID standard or not. The PDP certainly does benefit from a standardized DID. The PEP might prefer a capabilities approach or something else.
On Mon, May 25, 2020 at 1:34 PM Daniel Buchner notifications@github.com wrote:
I personally feel Encrypted Data Vaults is too specific, and lasers in on one facet of the datastore that some entities may not even use. For example: if I run one of these for some public agency, all the data on it may be public info that I am publishing in a semantically locatable dataset for others to freely consume. I also really am starting to feel uncomfortable with a few things about this: I purposefully didn't impede EDV being the main input to the spec, because I didn't want to obstruct progress, but now we're talking about calling the end result EDV, and people are talking about components of EDV as if there's not going to be lots of churn and reassessment - this should be a well-informed clean slate.
As such, I would propose the following names:
- Secure Data Storage specification
- Secure Data Store implementation
'Secure' can encompass all configurations, because objects may or may not be encrypted, but they certainly will be secured by DIDs and a permissioned-capability access layer. 'Storage' also implies the concept, while 'Store' is an actual noun, which lends itself to being the implemented Store of the Storage spec's concepts.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/secure-data-store/issues/35#issuecomment-633662900, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YJAYQIX6INLQGBVUPTRTKTZ3ANCNFSM4M3NV6UA .
csuwildcat
commented
4 years ago @agropper just mentioned DIDs because that was what the bulk of folks here are familiar with, but it needn't mandate that.
OR13
commented
4 years ago Here are some scenarios that I can see happening at this point;
Working Group: Secure Data Storage Spec: Encrypted Data Vault Impl: Encrypted Data Vault
Assumes a PR with name changes is accepted... seems unlikely given the current debate.
Working Group: Secure Data Storage Spec: Secure Data Storage Impl: Secure Data Store
(@csuwildcat 's proposal) Assumes a PR to change the spec name, and a home for a reference implementation...
Working Group: Secure Data Storage Spec: Secure Data Store Impl: Encrypted Data Vault
This happens if no changes happen, because there are 3 implementations that already use the term "encrypted data vault"... and the working group does not seem to have agreement on how to handle a reference implementation.... The benefit of this approach is that it allows the organizations who have already invested in the "Encrypted Data Vault" brand, such as Transmute, SecureKey, DigitalBazaar and DHS SVIP... to continue to leverage the brand, while allowing the spec to be more general... these folks are also most likely to help get the reference implementation started, so it might be worth taking this approach if we want to move quickly... we can also take a layered approach and implement a "Secure Data Store" reference implementation after we have a working "Encrypted Data Vault" implementation.
I'm in favor of Scenario C.
msporny
commented
4 years ago Scenario B is unworkable - it sends the wrong message about what the specs are about. Fundamentally, I think the debate is occurring is because it's not clear where the layering is. What I thought we were doing was layering things properly, with EDVs on the bottom and "Storage stuff" on the top.
I do want to make it clear that this isn't a debate over features, I think we can accomplish all of the features that everyone wants. It's a debate over what we call the layers and what's acceptable at the lowest layer.
To be crystal clear, a solution that doesn't encrypt at the base layer is unworkable for Digital Bazaar. The reason we are involved in this work is to do something that hasn't been done w/ Dropbox, Google Drive, FTP, S3, and other storage mechanisms, which is to put encryption at the lowest layer so one is building on a known secure implementation.
That doesn't mean that one can't put "public storage" (@csuwildcat's use cases) on top of the encrypted stuff. That's a perfectly legitimate use case, but not one that needs to drive a notion that the lowest layer isn't always encrypted.
I thought we were headed in this direction:
WG Name: Secure Data Storage WG Lowest layer: Encrypted Data Vaults Higher layer: Identity Hubs / Storage Hubs / Secure Storage Hubs Implementation: Whatever you want to call it.
We'll need to discuss this during our next call since it is a part of the layering discussion.
agropper
commented
4 years ago "Building on a known secure implementation" would be easier to discuss in the context of a use-case. For example, my 1Password manager app syncs through Dropbox. I use it to authorize transfer of money stored in my bank to the money stored in the merchant's bank. The password manager is my agent but does not handle the money. Dropbox is encrypted storage I control but it's invisible to all of the principals in the transaction (except me when I first set up the sync).
(Point 1) Having a standard protocol between 1password and Dropbox enables me to switch from Dropbox to Google Drive without disturbing my connections to the banks and merchants.
(Point 2) Dropbox and Google Drive currently force me to use their control agent in order to share documents with other people. I can't use 1Password to authorize access to a Power of Attorney document for my bank. If I switch from Dropbox to Google Drive, I need to revisit the sharing policies between my document store and the bank.
My goal in the layering discussion is to enable apps like 1Password to act as my authorization agent for both Point 1 and Point 2. Whether the stored material is encrypted (Point1) or not (Point2) would be none of Dropbox's business. If we can agree on the layering / protocol between the policy enforcement point (PEP, Dropbox) and the policy decision point (PDP, 1Password) then the naming will follow.
On Tue, May 26, 2020 at 11:52 AM Manu Sporny notifications@github.com wrote:
Scenario B is unworkable - it sends the wrong message about what the specs are about. Fundamentally, I think the debate is occurring is because it's not clear where the layering is. What I thought we were doing was layering things properly, with EDVs on the bottom and "Storage stuff" on the top.
I do want to make it clear that this isn't a debate over features, I think we can accomplish all of the features that everyone wants. It's a debate over what we call the layers and what's acceptable at the lowest layer.
To be crystal clear, a solution that doesn't encrypt at the base layer is unworkable for Digital Bazaar. The reason we are involved in this work is to do something that hasn't been done w/ Dropbox, Google Drive, FTP, S3, and other storage mechanisms, which is to put encryption at the lowest layer so one is building on a known secure implementation.
That doesn't mean that one can't put "public storage" (@csuwildcat https://github.com/csuwildcat's use cases) on top of the encrypted stuff. That's a perfectly legitimate use case, but not one that needs to drive a notion that the lowest layer isn't always encrypted.
I thought we were headed in this direction:
WG Name: Secure Data Storage WG Lowest layer: Encrypted Data Vaults Higher layer: Identity Hubs / Storage Hubs / Secure Storage Hubs
We'll need to discuss this during our next call since it is a part of the layering discussion.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/secure-data-store/issues/35#issuecomment-634112982, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YNZM47EPBEMLQEVKBLRTPQURANCNFSM4M3NV6UA .
rhiaro
commented
4 years ago +1 Encrypted Data Vaults for the specification name. Secure Data Stor[e|age] seems like a very generic term. If someone heard about our spec in passing and went to search for it, they'd likely not find it very quickly given all of the other products that purport to offer secure data storage.
Bonus points: eVaults is a cool shorthand.
csuwildcat
commented
4 years ago I just don't understand why we'd call something an encrypted data vault for three reasons:
I'd much rather call it something that represents its intended purpose, like Secure App Datastore, wherein James Bond double secret encrypted data is but one type of object it holds, right next to your-not-at-all encrypted resume data, public tweets, picture you want to share with the world, and all the other things that make up the vast majority of data users presently store in centralized app databases.
msporny
commented
4 years ago Looks like there are two viewpoints that continue to talk past each other. We're going to have to explore the solution space in depth to get past this roadblock... but before we do that, I'd like to assure @csuwildcat that we have taken his use cases into account and we do have a different design to accomplish them. I think we all want the same thing, it's just the specific implementations that differ.
Let me try and give it a shot at explaining the rationale:
- The majority of data in many of these things might be intended-public unencrypted data.
Full Disk Encryption is often used in cloud service providers to encrypt the underlying disk. It is also true that the web servers that run on top of the full disk encryption publish a subset of the information that's on the fully-encrypted disk to the general public.
I think that's the closest analogy to how some of us expect Encrypted Data Vaults (the analog to Full Disk Encryption) are layered below Identity Hubs (the analog to a web server transparently using Full Disk Encryption for all data stored).
- The term vault doesn't invoke the thought "Oh, this is the thing most of my dynamically written and frequently interacted with data that most of the apps on my phone use as their backing DB, like a serverless, self-sovereign, application backend"
As a everyday user of this technology... I don't even think about that. As a developer, I'll read an article that states the above clearly. As an implementer, I'll read the spec and quickly understand that what you state is the case (and if I don't get that from reading the abstract of the spec, then we've done a bad job at explaining what the technology is about).
- I'm going to again voice my concern that after I graciously agreed to make the Hub content a footnote without any drawn out discussion, we're now using basically all the content for EDV, looking to call the thing EDV, and have many people thinking it may not change much from EDV as it currently is architected.
I don't think that's what's going on. I think we're talking about how all this stuff is layered. Where does the EDV stuff fit, where does the Identity Hubs stuff fit. I don't think anyone is saying "remove the majority of Identity Hubs" or "remove the majority of EDVs". There is a recognition that there are important use cases across the board and we'll need to meticulously sort out which feature goes in what layer... because there are going to be some people in the group that don't need 100% of the features in EDVs and IdHubs.
I'd much rather call it something that represents its intended purpose, like Secure App Datastore, wherein James Bond double secret encrypted data is but one type of object it holds, right next to your-not-at-all encrypted resume data, public tweets, picture you want to share with the world, and all the other things that make up the vast majority of data users presently store in centralized app databases.
Again, I'd suggest that the design above is a monolith design and layers things inappropriately. The use case is solid and we should preserve that. The assumption that all of that gets shoved into Layer 1 is where the discussion is happening right now.
agropper
commented
4 years ago Seems to me that we could postpone the naming discussion until after we settle the Layers.
On Thu, Jun 4, 2020 at 9:36 AM Manu Sporny notifications@github.com wrote:
Looks like there are two viewpoints that continue to talk past each other. We're going to have to explore the solution space in depth to get past this roadblock... but before we do that, I'd like to assure @csuwildcat https://github.com/csuwildcat that we have taken his use cases into account and we do have a different design to accomplish them. I think we all want the same thing, it's just the specific implementations that differ.
Let me try and give it a shot at explaining the rationale:
- The majority of data in many of these things might be intended-public unencrypted data.
Full Disk Encryption https://en.wikipedia.org/wiki/Disk_encryption is often used in cloud service providers to encrypt the underlying disk. It is also true that the web servers that run on top of the full disk encryption publish a subset of the information that's on the fully-encrypted disk to the general public.
I think that's the closest analogy to how some of us expect Encrypted Data Vaults (the analog to Full Disk Encryption) are layered below Identity Hubs (the analog to a web server transparently using Full Disk Encryption for all data stored).
- The term vault doesn't invoke the thought "Oh, this is the thing most of my dynamically written and frequently interacted with data that most of the apps on my phone use as their backing DB, like a serverless, self-sovereign, application backend"
As a everyday user of this technology... I don't even think about that. As a developer, I'll read an article that states the above clearly. As an implementer, I'll read the spec and quickly understand that what you state is the case (and if I don't get that from reading the abstract of the spec, then we've done a bad job at explaining what the technology is about).
- I'm going to again voice my concern that after I graciously agreed to make the Hub content a footnote without any drawn out discussion, we're now using basically all the content for EDV, looking to call the thing EDV, and have many people thinking it may not change much from EDV as it currently is architected.
I don't think that's what's going on. I think we're talking about how all this stuff is layered. Where does the EDV stuff fit, where does the Identity Hubs stuff fit. I don't think anyone is saying "remove the majority of Identity Hubs" or "remove the majority of EDVs". There is a recognition that there are important use cases across the board and we'll need to meticulously sort out which feature goes in what layer... because there are going to be some people in the group that don't need 100% of the features in EDVs and IdHubs.
I'd much rather call it something that represents its intended purpose, like Secure App Datastore, wherein James Bond double secret encrypted data is but one type of object it holds, right next to your-not-at-all encrypted resume data, public tweets, picture you want to share with the world, and all the other things that make up the vast majority of data users presently store in centralized app databases.
Again, I'd suggest that the design above is a monolith design and layers things inappropriately. The use case is solid and we should preserve that. The assumption that all of that gets shoved into Layer 1 is where the discussion is happening right now.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/secure-data-store/issues/35#issuecomment-638851808, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YIK6EYNXNHNXRZK7CDRU6PMTANCNFSM4M3NV6UA .
OR13
commented
4 years ago Layer A - Trusted Storage CRUD (IPFS / MongoDB / Whatever...)
Layer B - Logical Storage CRUD (Vault, Document, Index)
Layer C - Logical Permissions CRUD (ZCaps / OAuth / TXAuth)... can <role>.<action>.<resource>... however you want to enforce that.
Layer D - Message Based CRDTs (firebase style, gun.js, etc...)
Layer E - Standards Based Data Structures (app manifest / webrtc rendevouz / didcomm connection preferences / aries connections / xbox user profile / bing ad preferences)
Layers A - C => Encrypted Data Vaults as they exist today (at least 3 implementations) Layers D - E => Identity Hub feature list (no functional implementation)
Let's define an "encrypted data vault" as a provider of layers A - C. Let's define a "secure data store" as a provider of layers D - E.
First question.... is a "secure data store" also an "encrypted data vault"?... if the answer is yes, then it's clear that 2 separate names are needed... If the answer is no... then 2 separate names are needed because many members of this working group came here to work on "encrypted data vaults" first.... and then maybe later work on "secure data stores".
The spec should be structured as follows:
Define EDVs / Interface... Define SDSs / Interface...
If SDS interface does not expose a superset of interface exposed by EDVs, then it belongs in its own spec... because it provides a competing high level interface, which will be confusing if its not a super set of edvs.
I'm ok with keeping everything in 1 spec, but not if the layering confusion persists for much longer.
If we can't work together in 1 repo, and as 1 group on this, with consensus on the layers as described...
We can create the following soul crushing / contributor destroying repo structure:
decentralized-identity/edv-reference-implementation decentralized-identity/edv-spec decentralized-identity/sds-spec decentralized-identity/sds-reference-implementation
^ doing this will completely destroy the whole point of this workgroup, and all the effort we put into getting it started.... these are all "layers" of a single spec and a single working group, in my mind, but I don't have endless energy to make this case... if there is a continuous desire to not have these things be layers with useful names, in a single spec... we should probably address that soon, so we can make faster progress.
agropper
commented
4 years ago Layer A - Secured Storage - a Customer uses a FIDO token as credential to write data and metadata that may or may not be encrypted. Metadata may be plaintext even if the associated data is encrypted. Content-addressed data (IPFS) is supported. Data and metadata storage may be structured according to either standard (HL7-FHIR) or published data models. The secured storage provider enforces scoped access tokens or capabilities signed by the Customer.
The storage provider maintains logs that are accessible to the Customer via their FIDO credential. There is no relationship between the identity of the customer and the identity of the data subject. Encryption is optional.
Layer B - Access Control - a Customer authenticates into their access control agent. There is no entity relationship assumed between the access control agent and any secured storage provider. A Requesting Party presents an Access Request including the scope or address of the data requested, their credentials, and their intended use. The requesting party may be issued a scoped access token or capability signed by the Customer.
Layer C - Messaging - Connects Secured Storage, Access Control, User Agent entities for both the Customer and Requesting Party identities.
On Mon, Jun 8, 2020 at 5:25 PM Orie Steele notifications@github.com wrote:
jonnycrunch
tplooker
dmitrizagidulin
The spec is currently "Secure Data Store 0.1"
The working group is currently "Secure Data Storage Working Group".
If you have a proposal for a name for the spec, software implementation that differs, please make it, and provide reasoning behind your choice.
Lets the bikeshedding commence!