Secure Data Storage - scoping #1 - (Superfriends)
8:02PM Apr 2, 2020
Kyle Den Hartog
I just started recording.
anyone with the link can let's say it, let's say, let's say at it, save.
Okay, did that fix that?
Hey, Orie , can you confirm that that's fixed?
I'm trying to get back to the zoom link. Okay. Yeah, it seems to have worked. Okay,
there we go.
Yeah, and Balazs if you don't mind, I can for whatever reason my zoom client at home does not let me see participants and share my screen at the same time. So if people have their hands up, I might miss the notification. Sure. Great. Thanks. We'll get started in about 30 seconds. Blush Daniel, I don't know if I don't know if Reubens here. If you all want to give some quick updates on candidate status, whatever items you feel are appropriate, we'll start there and then we'll move into the charter and then the use cases discussion.
Sure, I'm happy to do so. So hi, everyone, and thanks for joining. I think people will be coming in but it will be in the recordings. So Dave is going to approve early next week. If everything writing a new charter that enables the sort of goal, the ability for participation in this working group without becoming a member. So basically, this is introducing a new form of participation, this is going to be called a contributor, which basically enables companies to participate in an IPR protected work within dif without becoming a full paying member. And it's a it's a free format. And basically, I'm, I'm happy to share with the crowd the draft of the extension of the charter. And as soon as it's accepted, I think, maybe next call. It's just easier if we go through exactly how it looks. But I'm very happy to share it because maybe some legal teams or some lawyers will want to take a look at it. Just for clarification, and on The other side. Now there is an additional discussion between w Tracy management and the fleegle. Because there might be an opportunity to directly transfer created IP from this to a W Tracy working group. And the lawyers just clarifying that as we speak, but if that wouldn't come through then the previous the agreed process through CCG and then signing an FSA is still realistic and is in place but we just want to make sure that it's as simple for everyone and for us as possible. So these things are moving as we speak. And I think it's a question whether I should share a draft or I just shared the final version once it's accepted next week, mono and and maybe others. Um,
yeah, I just share the one that gets passed. Okay, I do. I do have a question about Some other things that we might all be able to do in parallel. So until that's passed, there's nothing that we can sign I know IPR agreement design, or is there something that we can do in parallel?
So I would say that's early next week. So for this call, it would be late, I would say because and then we can distribute it as soon as it gets signed, you know, legal format for for anyone and everyone. So if everyone is able to get ready to be signed by the next meeting, we can actually have an IPR protected call. Okay,
got it. So we'll, I guess we will wait and watch for that in our inboxes. And whenever you feel it's appropriate to distribute it, you distribute it we would have as companies and individuals who take a look at it companies would have their legal counsel take a look at the agreement, and then sign it and then send it back to diff. Is that right? Or?
Yes? No, we have all the addresses just we haven't said we
have everyone's we have everyone's email who signed up for for the meeting. So anyone who got invited at did basically I we have all the email addresses for individuals, I can already start signing so we have a different format for individuals, that's also free. The bigger question was always that how to enable companies. So for those who are interested to participate on an individual basis and representing themselves, the easiest if you reach out directly to me Balaji at identity dot Foundation, and I can share with you the right document and you can start a collection and potentially even sign it.
Okay, sounds good. Thank you for lunch.
Have you been pushed very likely, late or late Monday? next week?
Okay, great. Sounds good. All right, on to the next items in our agenda. on the agenda today, is basically talking about basically finishing up the working group charter. We just have a few items to close out there. And then we'll be running a poll through zoom to see if there, how many acceptances and if we're there any objections and then we will start our work on the use cases document and starting to put that together. I'll share a link so I shared these links a bit earlier before everyone is on so here's the charter, Link charter. And then here are the use cases based document which basically pulls from the rebooting paper that was done with a number of the people on this call in various communities. There's use cases document, are there any additions or changes to the agenda or anything else people would like to cover during the call today?
with that, let's go ahead and go top to bottom in the charter. There have been a number of language suggestions for the remaining items
money your posted my is the same document.
Oh, I'm sorry. Uh, you are absolutely correct use cases these cases. Yeah, let me let me let me try and see, there we go. Sorry. There's a use cases document. Um, So, in the working group charter, we're going to take George's item first. So George was concerned that people might interpret data to mean just the bytes that are stored and retrieved instead of the actual communication between client and server, meaning it could be that they could misconstrue it as clear, clear text communication with the server. So we've changed that too. From data to information, so design a cryptographic security architecture that protects information in transit and at rest, noting that different approaches may be taken for information in transit, and information at rest. And then this last bit here was a suggestion from Ian to be aware of quantum computing based attacks while we think about that security architecture so that we can take quantum resistance into account. So this is the modified language. We're going to do the same thing that we've been doing on calls and ask for any objections and if there are objections, we will move on to the next item and then eventually come back to this one. Are there any objections to this suggested language? So, Daniel, more quantum computing based attacks, or just quantum computing attacks. Okay, any objections to that language?
Okay, not hearing any I'm going to go ahead and make those changes. Defense Against the Dark Arts should definitely have that in there. I think that's a standard boilerplate for any standards charter. Here we go. Okay, so that's done. I'm good. We have a solid first page. And I'm gonna resolve your concern because it's been integrated set work for you.
Yep, that's good. Okay, done.
Okay, next up, Johnny crunch. There is a there's some texts that we adopted last time that basically said invention of new mechanisms for querying or inserting data such as SQL or Gremlin is out of scope. We are not going to use mechanisms that are not standardized or not work items of the W three CCC, diff or existing standards working groups. Johnny crunch mentioned, did URL matrix query parameters? And what about the use of dead URLs for querying and inserting data? I don't quite follow what that means. Jonathan, are you here today? Yeah,
I am. Here. me okay. Yep. Yeah, mostly because, you know, selling to URLs is a method of querying the data in a like, it's a good document. So I just want to make sure that that is covered as a mechanism for discovery of data in the secure data stores.
Yeah, so I would say clearly and always answered as it as well. Did URLs are under development of Wi Fi, which means that they're in scope for the work that we're doing? Okay. Okay. Can I resolve your issue? Since? Yep, it's in scope. Okay. Is that done and I think this one is also the same. Yeah. So that's in scope. Okay, so next item. Daniel, you had a concern over making sure that the design is worksheet easily across different types of different types of protocols. There
could, could you pick just could could you just put Is there any way we can such as like a best to more, you know, you don't block or put undue barrier. and supporting those I don't maybe that's just inferred maybe started maybe I'm overreacting just
think I think get enough people care about it that I would be surprised that I mean it's it's something we're Deaf certainly going to take into consideration right I mean, so so I think this boils down to like you are as dead calm the mechanism that you use to communicate with these things are not right. That's that's fundamentally it in and I think we're it's gonna be impossible to avoid that discussion.
Why don't we just remove my thing like, I don't care. It's probably
okay right. All right. So resolve. We didn't as a group accept this yet, though. So design or development of non HTTP based API's are out of scope. I'm trying to think Daniel, if there's a way for us to say that discussion, we can still do this. Got that stuff
on the queue? Oh,
sorry. Go ahead. pori.
So I did have a conversation with the folks at stranger labs about this. And it's, it's my, I think, I think I probably introduced this language like a while ago. And my intention was just to prevent us from getting pulled into the weeds on really hard radio, you know, poor communication protocols in addition to HTTP and needing to like, basically have too many different design targets and not be able to get anything concretely done. I think that in terms of support for radio technology, or pigeon, you know, carrier pigeons or, you know, paper based, you know, whatever, I think we should 100% think about those cases, as we design our HTTP endpoints. I just really don't want to have someone bring in like, support for Bluetooth 1.2 Like protocol related stuff into the working group and have to spend, you know, a tremendous amount of time focused on that layer of communication. And my recommendation for radio technologies would be that we design the HTTP API such that it's obvious and really great and easy to translate to those other transports, either programmatically via machine translation, or just because it's designed so well, like it's obvious to see how you would do that for Bluetooth. So I think we can totally think about these things. This is saying we're not going to go build radio technology communication protocols, like and I would object really strongly to anything that allowed us to do that in this working group.
Right. So the question is, do We reward this? We could say, primarily focus on the design or development of that history. Some some amount of weasel wording that allows us to talk about it but not primarily focus on it.
You could say something like, go Don't go and input considerations. You know, like, like people like if someone comes and provides you white paper says, do it this way, it's not gonna work. It could be five or six or whatever inputs for, you know, like we accept that we're not going to take it on it's work items,
right. The other
thing that we could do, playing off of that Daniel is a country consider how the design of the HTTP based interface will interact. Well will will affect the communication protocol for non HTTP based API's?
Yeah, that's good.
Although that means we'll consider it it doesn't mean that we have to say, Well, yeah, it's not it's not a very strong statement, but it at least attempts to balance and capture these two things. So okay, so if we put both of these things in, was that balance everything? I guess let me let me say, Would anyone object to putting both of these items in?
I'm objecting less, because I think it opens up the door for us to communicate because I think I just don't want to have a preconceived notion of how to solve this with where I can I think we need to have a discussion about the design constraints that, you know, certainly maybe HTTP is not the best solution, or when we actually get the rubber meets the road, like, you know, some solutions like that would be binary exchanges, of which the transport and communication level could still be similar to HTTP, where you don't have to rewrite the whole thing, but actually, like you have flexibility to extend us. Okay. I like the wording better than we're considering designing. But it's, again, focused on HTTP based interface. And so I think it's a it's an it's the original focus can be HTTP based, but I think the general framework and consideration shouldn't be it should be unconstrained to allow for the maximum exploration make sure if you fit for purpose
okay. It but but I'm hearing your your you're not objecting or you're still are objecting
I'm not objecting, I think I just want to make sure that it's worded such that we actually have to explore this thoroughly to make sure we get to a result that is solution focused. Okay, just constrained to one way.
Okay, so my suggestion is that language does exactly what you just said. And if it doesn't, we have the group on record, meaning the call is being recorded. That, you know, no one's objecting to what you're saying right now, Jonathan. So I'm going to go ahead and hit accept on both of these items because I'm not hearing any objections, and then that will be that Okay, so that's that. One in chat I saw you suggest something out of scope actively ensuring compatibility or translate ability with non a fee based interfaces.
It's a bit vague
thing. Okay, changes cover it.
Okay, um, alright, so those are all the items from the first, second and third pages. We have nothing else in here that people have added commented on or anything else. So, in theory, this is the charter, right. So what we need to do at this point is determine if there are any outstanding objections to the charter. Please, if you're going to object keep in mind that we've been at this for multiple weeks, and there has been plenty of time for feedback and input and raising the objection at this point. Is is not going to make you any friends. But at the same time, if you feel like we're, this is this is a really bad charter It's really dangerous, or there's something that we absolutely have to cover. This is your last opportunity to do so your last opportunity to object. So, with that said, I'm going to ask if there any objections before we run the poll just to make sure there are no surprises during the poll, and then we'll run the poll. So Balaji, if you could get the poll ready. Let me ask one last time. Would anybody object to the contents of this charter as is at this point in time?
Okay, with that, please fill out the poll. You should have seen you should see a window pop up on your screen that says except to charter a poll, do you agree with the charter as it is to be considered final?
yes or no? And then village, I have no idea how we see the results of that poll.
We have 15 to 12 people filled out. Okay. The question is, are we going to read for everyone because we have some folks on phone, but it's more about it's just the people know, if someone would object Please say it. Yeah.
Yeah. So how does how does that work? If people are just observing, then no, this is
not an IPR protected call. So there is it's hard to observe. Everyone is equal at the moment and anyway, and everyone's equal, so. Alright, no, 12 of the 23 people filled out I'm just gonna end and there are no objections.
Okay, great. Sounds good. Does it put the The results in the chat channel or anything are up there we go. 100% That's awesome. It doesn't get account. Um, okay, well, yay, we should all feel good about that. It's actually notoriously difficult to develop charters in the way that we've just done it but it also maximizes the amount of buy in on what we are doing. So Good job everyone. Thank you very much for staying with us while we went through that. Okay, so now that the charter is there, the next steps Balaji if I if I understand correctly, is the charter does go to diff steering committee for final approval. And then we need to do a chair selection at some point. Do you know what the timing for the chair selection is going to be yet blush
Um, I think If we do it now that's better it two people should be selected before the, the chair should be at least one chair should be selected before it goes into becoming a charter approved by the steering committee so at least one person should be known.
Right so so the community has to do that blog in that in we probably need to set up a poll for that. And it needs to be more than the people on the call. Because you know, we're we're at 25 people and we've had you know, 60 people show up in the in the past. Are you going to the The other thing that that's pretty typical here is that you normally have a nominations process so that certain people can step forward. So I'm making this up as I go bylaws, but what do you think about having a week to send out a call for chair nominations? For the SDS working group and get a whole bunch of people, whoever wants to be chair can put their name forward. And then we can run a rank choice poll that will just among everyone on the mailing list that will do a rank choice vote, so that you know, the top three will end up. You know, being being selected that way. What do you think of that? Daniel abhilash. Is that fine? As far as a chair selection process?
Yeah. Yep. Okay.
Okay, so Balaji I think the action then after the call is for you to send out a request for chair nominations. Clearly the people have to agree To be fair, you can't just nominate anyone even against their will. And then we let's say it's open for seven days bylaws and then you know announce it broadly so everyone knows and they know to send their names in to you. And then after seven days we can announce that and then open another poll for seven days a rank choice poll perfect.
And I will also reach out to anyone who got nominated. Okay, person who's not self nominating just to discuss so we know by next call who is actually can be elected or not to be elected. Alright, perfect. I mean, that's
great. Thank you might also be good idea to describe what the difference between a chair and an editor is and if diff is going to have an opinion on that that's the same as the WBC are different because the duties of a chair and the duties of editors are different things I'm not sure that everyone who's about to get notified of this will know the difference between those things.
That is an excellent point. I was I was assuming that there would be two very different roles. I don't know how diff diff handles that.
It's pretty flexible inside looking. kind of fun.
Okay. Okay. Well,
it's so to be to put a very fine point on that the chair should not be an editor. Ideally. It does happen from time to time in very small groups, but this is not a very small group. Ideally, we have very, very strong separation between duties there. Okay, that is that that's the charter. That's how we're going to do elections. For the initial chair, one question.
separation of duties. I kind of get that like editor you know, except the chairman's What about that. chairs if someone was a chair, they can still do prs.
Yeah, absolutely. Yeah. Yeah chairs can still put forward prs but they can't put forward a PR and then nominate themselves to approve the PR based on the chair decision. Right. That's a clear violation of of the the separation of duties there. But yeah, absolutely. Chairs can process issues, chairs can put in p Rs. They can do everything that a regular member can do that answer the question, Daniel.
Okay, that's that for the charter. Are there any other questions, concerns or comments regarding the charter, we're going to tie a nice little bow around this and then lead that's on the diff, steering committees. porch, I guess. In, move on to the use cases.
Okay, that's that moving on to use cases. Just in an attempt, I'm going to put this link back in the chat channel use cases. I wanted to preface preface this document with no one's agreed to anything in this document yet. It is just a proposal. The proposal is just to get us started with the basic structure and a set of things that have been discussed in the past at rebooting the web of trust in various other fora. So just to give you some background on where the texts in this document came from, there were a subset of us from various different communities the the area's community, the solid community, the CCG The diff and a couple of other people that worked on like secure scuttle button, and things like that, that got together at rebooting the web of trust. And we tried to identify use cases requirements, deployment topologies and design goals just at a high level, just to just to say, you know, these are the things that we're trying to work on and do. So I believe they're, you know, there are between six to 15 of us working on this at any given time, and God reformed mind as a rebooting paper and was published as a pre booting paper. That content was then wholesale copy and pasted into the encrypted data vaults. document. What I haven't done yet is gone through any identity hub content, we did go through the identity hub stuff and rebooting to pull the use cases in. But that doesn't mean that it has all of them. is, you know, is correct or anything like that. The proposal here for use cases and requirements is for us to go through two stages, one of them where we just collect as many use cases as people want to throw out there, right. So there's no wrong use case. You just, you know, write your use case down in the same format that it's written here. And just get in, get it into the document. So for example, here, the use cases can be a sentence long, right? So search data, for example, is a use case. Over time, I will store a large amount of data, I want to search the data but don't want the service provider to know what I'm storing or searching for. Right. So that's just a, that's a simple example of a use case. It's a sentence long, it can be as simple as that you can get more elaborate. So the the, the request to the group is add as many of these as you want into the The sections as we go along. Hopefully this is this, this can be done while we're on the call or asynchronously. So we're so we're basically going to collect a whole bunch of data from anyone that wants to provide input. And then we're going to go through a prioritization phase. Again, this is just a suggestion, but the suggestion for prioritization is we go through rank choice voting, you jump in, you tell us what your first, second, third, fourth, fifth priority is, that's weighed against everybody else's priorities. And we will end up with a list, one through whatever of the use cases, one through whatever of the deployment topologies, one through whatever of the requirements. Same thing for design goals. And then once we have that rank choice, voting thing that's basically the order in which we work on These things, we will have to have a little bit of discussion to just make everything kind of logically line up. There's a chance here that, you know, we put a use cases number one priority, but as far as requirements are concerned, it becomes like the last priority that can happen sometimes. And then basically, you know, we're not trying to be perfect here. We're just trying to get a base set of use cases that we can we can talk around my see Daniels on the queue. Go ahead, Daniel.
For a meeting, um, yeah, so I think right now, they seem to be a you know, it's focused on kind of almost, like tech cooperation versus like, application level, is that intentional, or is that just one type of use cases like the operational characteristics versus say, Hey, I wonder that there's an interface for doing secure or I'm starting semantic data. You know, it or something?
Yeah, there's, there's no, I don't think that there's any limitation. So so the document is the way it is because a bunch of people got together and collaborated, and this is what they came up with. But if you feel like it doesn't capture your use case, or he doesn't capture what you want, and you're concerned about it, your use case, requirement, whatever not being represented in here at it, the best thing that you can do at this point is just added so that we can then have a discussion about whether or not two items are the same. Or if there there's enough of a distinction for them to be two different things. Okay. Yeah. So this is supposed to be a very inclusive process. We're not trying to, we're specifically not trying to say your use cases wrong, right? We're just, you know, go ahead, go ahead and add it. Ideally, don't do it. Try not to do duplicates, if you if you don't know if it's duplicate or not go ahead and add it in and then we can decide as a group, whether or not it's Duplicate.
any questions or concerns about that process? Or in general what we're trying to do here?
Okay, it's hopefully everyone's crystal clear on what we're trying to do. It's not complicated. There's no no no tricks. It's just we're trying to document what what people want to try and do with these secure data store storage things. Um, let's see, at this point, what we can do is we can start going through the document from top to bottom. And as we read through it, that may trigger use cases that you want to make sure that you put in here. You don't need to ask permission to write anything in here, just start typing. Right. So this is we've got, you know, 2026 people on the call if all 26 of you start typing that story. Fine. Okay, so let's go ahead and start off the document is structured in the way that it is, again, just because a bunch of people got together and felt like this was the best structure. We wanted to place to talk about use cases in general, like I want to do these things. The deployment topologies had to do with how am I going to use How am I going to interact with this thing? So it wasn't it didn't clearly line up with a use case it it had to do with a, like, for example, the searching data use case, well, maybe I'm on a mobile phone, or maybe I'm on the laptop, or maybe I want to use my mobile phone to do part of it, and then my laptop does do something else. That's why it was split out because each one of these use cases you might be using a different device or topology, network topology to interact with with the system.
Hey, hi. My name is Yep. And while Sorry, I'm jumping into doesn't
know their dad keys I'm thinking Go ahead.
Okay. Um, I remember from this conversation, one of the things I'm not sure we're not certain use case or requirements. But we had a conversation about split of responsibilities that I that definitely made us kind of line up around the boundaries. Yes, we. Yeah. So I don't know, that's placed in here or
it's down at the bottom design goal. So layered and modular architecture is where I think that language ended up,
So So yeah. So. So, yeah. So let's keep going requirements are basically things that we need the system to do based on these two things. Right. So based on the use case, in the deployment technologies, well, we need privacy and multi party encryption. Well, we need identifiers of some kind, well, we need versioning and replication of some kind, right. So So these Things drive requirements sections one and two drive requirements. And then the design goals are just, they're kind of like the goals that we talked about in the charter. They're just things to keep in mind. So when we're making a difficult decision, you know, one of the design goals is to prioritize privacy. So if, you know if we're trying to figure out if we should do it, you know, in one way or the other, we look at the design goals and go, well, we're really supposed to prioritize privacy. So that is an argument for option B and not option A, right? Or we're trying to figure out if we need to put something in the server, the client and we're going back and forth on it. Well, we've got a design goal that pushes implementation complexity to the client, right. So the goals are meant to make our decision making process a little easier and more predictable to the group. The more of these design goals that we write down the Hopefully more predictable the decisions the group makes over time are. So those are the four broad categories that are in there. It doesn't mean those are all the categories, or that, you know, we've got everything in every single category. But again, just just a starting place. Any question about the broad categories before we dive into it?
Okay, so hopefully that those are clear. Let's start off with use cases. The use cases I'll admit, need a bit of editorial cleanup, right. So they're all kind of they're they're one of the issues with the use cases right now is they're all written in the first person and use cases are typically written in the third person. So you can identify, you know, people in actors. So Alice, Bob Carol, versus I want to do this and I want to do that. So these will be edited in time. We don't need to do any editorial stuff. Right now we're just trying to get broad brush. I believe these are in priority order. So again, you know, a couple of people got together, and they prioritize these use cases, in most important to least important doesn't mean that that's what it's going to end up with. But that's kind of what it is right now. Okay, so one one store and use data, I want to store my data in a safe location. I don't want the storage provider to be able to see any data that I store. This means that only I can see and use the data. So that's a use case. And I think it's important to point out here that, you know, I know Daniel, you have a use case where you don't necessarily want the everything to be encrypted everywhere. And you may want to be able to publish files so that your service provider can see them or the general public can see them. Right. And so this use case doesn't preclude that use case. But I will point out that your use case that you outline Daniel isn't written down here,
right? I added it. Okay.
There we go. There we go. Perfect. Exactly that that's perfect. That's exactly what we want to see. Okay, and people are already typing stuff out here. So that's great. Um, okay, second one, search data over time I will storage store large amount of data, I want to be able to search the data but don't want the service provider to know what I'm storing or searching for. So again, this starts hinting at things like encrypted searching, but it doesn't outright call it out on purpose. A good use case doesn't mandate a particular solution. It just tells you what the person wants to wants to accomplish. One three sharing data with more than one entities I want to share my data with other people and services, I can decide on giving other entities access to data in my storage area when I save the data for the first time or at a later stage. The storage should only give access to others when I have explicitly given consent for each item. I want to be able to revoke the access of others at any time when sharing data, I can include an expiration date for the access to my data by a third party. Right so this is kind of like Google Doc sharing or sharing in in those those sorts of ecosystems. One for store the data in more than one place, I want to backup my data across multiple source locations, in case one fails. These locations can be hosted by different sort of storage providers and can be accessible over different protocols. One location could be my could be local on my phone, while another might be cloud based, the location should be able to synchronize between
So data is up to date in both places, regardless of how I create or update data and this should have happened automatically and without my help as much as possible. So again, this is hinting at replication, but it doesn't call it doesn't call it out, right? doesn't call that solution out, right? Okay. Let's see. So those were the ones that existed, people are adding theirs here. So if we could if the people that added the item could jump on the queue and present it, so who did who didn't? One five, Alice wants to publish plain text about Bob, Carl? Or go ahead, Ori.
So I think based on my understanding of identity hubs and conversations I've had with Tobias and Daniel, there is a desire to be able to publish authenticated plain text via these services. And I think that this 1.5 basically says, Alice wants to publish authenticated plaintext period. Now, let me Whatever that authentic plaintext is, it's like it can be anything is Alice just wants to publish it. So it could be about Bob or Carol. And Alice just doesn't want anyone to be able to censor her from publishing authenticated plaintext. So I think it accounts for, like the use case of I have a did and I want to publish some authenticated plaintext material. That's the authenticate double to that did. But I don't want any kind of restriction on what that data is that I publish. Okay, got it. Um, okay. resistance on the queue, I would say like censorship resistance basically just means that you can't be blocked from publishing and the authenticated plaintext based on the structure of this, the these these data stores, right. So we'll be like, if it's a valid authenticated, plaintext object that's being submitted. Then it's accepted.
Dimitri, does that answer your your question?
Sure. I mean, I still find that's like saying, I want to save a file to my hard drive in a censorship resistant manner. Like if it's my hard drive, who is gonna stop me?
But anyways, no problem I think I understand
yet. So when it comes into play when you're talking about saving it to something that includes a cloud based instance, so that potentially you can expose it to either whitelisted set of people or because at that point, you want anyone to be able to find it back to it, and that may not be possible. You're offline. Okay, so
So I think the the general ask that I'm hearing is maybe some clarification around what's meant by censorship resistant or in white. You know, what, what that like that cloud comment was, was was helpful. Um,
next up, is one six, enable storage of semantic data who added that one?
Yeah, that was me. Basic. So this is this is a little bit akin to, you know, being able to push plaintext data. But it's not just a plain text to be encrypted to a certain subset of parties. The goal here is that I would like there to be an interface. If we have a rest, you know, an HTTP based API, where the data stored can be queried in a self describing way. So like, I go and store schema or offer objects, for instance, and I want to create a decentralized Craigslist. The problem in the world today is that you might even use the same objects in some different systems. But everyone then slaps their own REST API. And for some reason, leads it's a good idea to call the REST API different than what the actual data is. So I was I'd like to be able to say, What if I could crawl the DI D space? Right? Imagine there's a giant list in the sky of D IDs. And I could say, Gosh, darn it, I want to build a Craigslist world. I'm going to ask for all their offer objects, because I know that's how people describe offers where I want to ask for all their software source code objects, because that's how people describe you know, a repository like if I want to create DPM, I'm so any of these things, basically, any decentralized staff, right, wants to say, what is the common semantic object to describe this thing? And let me go find all of those. Does that make sense? Yep,
yep, absolutely. Um, any questions from the group about this this use case?
I think it's pretty, pretty solid one. Okay, so that that one's good. Did you Well, I think each one of these
Yeah, this Second one about the messages. Yeah, I can add other examples to that.
Yeah. I mean, yeah, yeah. So that's good. I was I was gonna say, we might want to cut down on the language. But, you know, but but at the same point, it's good to have multiple examples. Okay, so, one seven provide a mechanism for receiving and handling a queue of task based messages. Who added that? So?
Yeah, so, you know, when we talk about everything's gonna object that comes into this hub, or, I'm sorry, this SDS thing. But what I what I probably want, and you see this in the community already, right? There's certain people who want to send messages based on you know, credential negotiation, for instance, I don't know, maybe there's like seven messages that happen or could happen in credential negotiation. Like, here's the stuff. Was it right, here's the issue thing. If there's going to be a zillion of these tasks based flows, credentials are not the only thing in the world. We don't want them to be special. snowflakes. So what happens when I want to negotiate purchase of a secondhand item? Well, I would hope that I could create some semantic message or series of messages that stands for that flow. So what I'm really asking for is a generic way that I can send a task based messages, like think about it, like almost like an email inbox, where it's not just me storing data on someone else's hub, you know, in a static way, it's like, oh, here, I'm just gonna drop a file off. It's like, I'm sending you a semantic message into an actual queue, that when it gets synced to all the instances, maybe one of them is your wallet, it's picked up and it's kind of handled, like almost like an education type thing. So that's, that's the general mechanism. And that would be very useful across credential negotiation, and pretty much any other type of action based flow.
um, I'm wondering, so we definitely need text in that what you said was, was great, we need probably all that text in here. So that we can refine
I have to be specific here to anyone on the call, I'm not trying to define a series of specific messages, there's only a certain set of primitives that have to be true. Like, there's usually an initiating message, there's like, you know, things that happen in response to it that are kind of threaded off that all the data store would not used to say, this set of messages is linked together, like these are part of the same learning. So nothing about like actually defining the credential, negotiation flows or any other flows. It's all text.
Okay, thank you.
Alice wants to upload executable code that service providers will run based on an event system. Who added that and that seems like it's the what?
I added it. I just feel like it's more accurate way of describing handling of queueing and task based message systems. So I'm basically following Daniel around trying to clean up his language in a way that that makes sense to As a programmer, because if we're going to be handling, you know events in a specific way, we might as well call them events, we're going to have special stuff that handles them in a special way might as well call that an event handler. We're going to be subscribing to certain kinds of events, you might call those subscriptions. Now, we have lots of stuff out there that does this kind of thing. And I consider this to be like kind of an advanced feature that's super powerful, but you know, maybe it's a thing that everybody wants. It might be a thing that only a couple people want.
Got it. I just made a note that one seven and one eight, maybe we have some overlap, I should say me have some overlap. Maybe restatement the item above or at least have some overlap.
Okay, that's it for the use cases. No more use cases were done.
Going on to deployment topologies Okay, so so you know, everyone, I think some work is add stuff to the use cases over the next week, we'll come back and see what new ones get added. And at some point, we're just going to stop taking use cases and prioritize them. Next up are deployment topologies. These are fairly self explanatory. We have four topologies, that were considered your mobile device and on your mobile device, that's where you vault is your mobile device plus Cloud Storage. So there's some kind of backup sinking mechanism that goes on multiple devices with a single user, so your phone, your laptop and your cloud storage, and then multiple multiple devices with multiple users. So let's say your family members in a family storage location in each family member has a phone and a laptop and they are all sinking in some way or another replace family with, you know, corporation or enterprise or small business or community group. It's the same same sort of thing. Are there any other deployment tech topologies folks could think of I know some people were talking about IoT as they feel like that's a that's a very specific one that they'd like to call out. Some have argued that that's just multiple devices. But you know, if you feel strongly about that IoT one, go ahead and add it there. Are there any other deployment topologies that folks are interested in? cloud only on that's that's a very interesting
one. Could I offer some tells you that with drawn. Yeah, this point. So I think that's in scope. And I think that is definitely doable. I think we've got demonstrated approaches. With some of the password managers, for example, they have water, they have their own vault specifications that allow encrypted synchronization of state. The only thing you have is if your cloud only you're in a user agent, and you basically need to have the input secret required to actually decrypt some aspect of your of encrypted content that's hosted at the storage provider. And so typically, they use a master password, but you could use mobile theme and that sort of stuff. So I don't think we've added anything in here that would prevent us from a cloud only option.
I mean, I just just to be just to be clear, Verify. When we say cloud only, we're still saying it has to be some form of client for interacting with that data capable of decrypting. It In that case, we're basically saying a user agent or a browser is where most of that logic would be residing. Is that what you mean?
Yeah, well, I mean, I was thinking just tonight, cheap terms, but I don't know. Other people should talk. There's people on the queue that probably speak my mind better than I would.
Yeah. I've actually, I'm just wrapping up a proposal for a large multinational that is specifically targeting the West African market. And we've been looking at the dynamics, the platform availability for Android and iPhone and multiple devices and extending government services out into rural areas. So this is very much an area where one of the The very specific requirements was we must support people who do not have mobile devices or cannot, are not in a position to operate special kind of hardware or engage in special hardware based key management. So there had to be a cloud, a cloud only version of that. And just just for for giggles, what we proposed was was basically using a whole bunch of biometrics that you could use at an internet cafe to kind of unlock the key storage, nobody wants to keep keys on the the cloud, nobody wants to, but if that's the barrier to getting access to government services, then it seemed like a reasonable compromise. So that was a something just I'm actually in the middle of writing right now. It's, it's doing six hours in Switzerland, so
got it. Okay. So, we're just gonna we're just gathering right so There's let me let me, Dimitri, you're on the queue, and then we're going to have to close the call. I'll wrap up really quickly. Go ahead, Dimitri on the taking myself off. Thanks. Okay. All right. Um, thank you that this is great. This is exactly what we wanted to get out of this. We're just collecting data. Next call, we will go through requirements. And we will go through design goals. If you can, please jump into the document and add items over the next week, so that we've got more to look at when we do this again, the the following week. In the meantime, look for the request for chair nominations from blush, look for the fine light charter document after next Monday. And at the very least, we will always talk again next Thursday. Same time, same channel. Any questions last minute concerns before we end?
Okay. Thanks all for a great call. We'll chat again next week. Mike.