owned this note
owned this note
Published
Linked with GitHub
# Secure Data Storage WG Agenda - Thu, May 21, 2020
1. IPR Reminder
2. Introductions and Re-
Kaliya, Dmitri, Tobias, Daniel, Orie <-Chairs & Editors
3. Community announcements, if any
4. WG and Spec name
5. Continuing Architectural Layers conversation
**CHAT HIGHLIGHTS:**
Orie:
Can people DM me issues that you think are “layering” concerns, I will tag them for review.
Eric:
There are *several* issues and discussion
https://github.com/decentralized-identity/secure-data-store/issues/47
Eric:
https://github.com/decentralized-identity/secure-data-store/issues/46
re: use cases : https://github.com/decentralized-identity/secure-data-store/issues/47
I mean 46
Eric:
as is the discussion of https://github.com/decentralized-identity/secure-data-store/issues/50
ERic:
discussion of https://github.com/decentralized-identity/secure-data-store/issues/48 relates to the terminological conclusion
^confusion
Eric:
https://github.com/decentralized-identity/secure-data-store/issues/49 - also, makes a call for working on 1.2 and 1.3 *prior* to discussing Issue #35
Dmitri:
johnnycrunch - I agree with you that emphasis on use cases and requirements is important. We have a start on that, both in our Use Cases document, and in section 1 of this spec.
@johnnycrunch (and everyone) - please help us expand those sections
Eric:
@dmitri - what about the question (Deduplication of section 1.3 & use case document) - issue #46
Adrian:
Dmitri was saying “authorization” in both L1 and L2. This is very confusing. See https://docs.google.com/document/d/1FBfs4shirUAtqD_d_t6F6oi2NZ0Y7400MDoYSm14Yco/edit#
Juan:
Would it make sense to ask for usecase feedback before next week's meeting and have a timeboxed portion at the beginning of that meeting to discuss/settle any questions?
Juan:
+1 to Adrian, I am confused by this term throughout
Artem Key:
I’m sorry if sounds dumb question, but does identity layer fits within defined enough within layer 1 given that master key authorizes access to identificators(dids/keys) where every single key will eventually authorize access to related to this id chunks?
Dmitri:
@Juan - definitely, regarding uescase feedback. I’m not sure that (even time boxed) call time is better for settling questions (than github issues), though
Orie:
Yes, seems like a section of the WG wants to focus on use cases.
Juan:
@Dmitri - Totally agreed! Maybe telling people now that there will be ONLY five minutes for usecases next week will motivate early and iterated usecase feedback on GH issues :D
Daniel:
Replication at layer 1 argument: you must have payloads embedded with the vectors and other bits required to securely converge changes in a masterless, eventually consistent way, or you can't do so securely
Orie:
^ make sure that kind of thing goes into a comment on gjthub Daniel…
Dave:
I'd say the desire is to create consistent interfaces and data models, not reinvent storage or database technologies.
Orie:
Yes, but also DIDs are a new thing… so if we want to support them, you will probably need to at least cover some new interfaces…
That’s part of why there is some familiarity to these interfaces / layers..
Dave:
Yes to Anil! The storage provider cannot see into the data.
We're going to get confused about definitions here with "client" in just a moment again :)
Dmitri:
@Adrian that is the fundamental challenge of this group! that, right there. that’s the crux.
Daniel:
Orie, logged the point here: https://github.com/decentralized-identity/secure-data-store/issues/52
Juan:
now would be a good time to thank all the brave firefighters and catherders dealing with all of our cranky issues :D