Secure Data Storage - scoping #1 - (Superfriends)

8:14PM Mar 26, 2020

Speakers:

Balazs Nemethi

Manu Sporny

Orie Steele

Daniel Buchner

Jonathan

Oliver Terbu

Kyle Den Hartog

Dmitri Zagidulin

George Aristy

Keywords:

objections

scope

object

language

data

group

mechanisms

http

queue

encrypted

people

indexing

api

working

privacy

discuss

http api

daniel

concern

question

I accept binaries.

You know, I accept Manu's statement. I just hope that we agree. Again, if that's not controversial,

and I just hope that we can word it in somehow. And I don't know if you're saying anything different from mine or in other words.

So how about this? Let's Let's ask the question directly. Is it does anyone feel that what I said was is not captured in the charter already.

Okay, so there's just general agreement that we will that that makes sense to most folks on the on the call. Let's go back to the language because we do need to figure out you know, either how to reward this or You know, we need to put something in here. Oliver wanted it. I think orys strong plus one for it. I know. The folks that worked on the encrypted data vault spec are also strong plus one because it's a it's a design consideration there. Jonathan, would you object to the language as it is? And if so, how would you change it? So that was your objection?

I just don't like design that I think that's out of scope. I think like I said, the right explorer encrypted indexing and search methodologies to prevent storage data providers from mining consumer data.

How about implement and existing in encrypted indexing and search mechanism?

Talking about homomorphic encryption encryption, so I think it's just it's it's a heavy lift, and

we're not well we're it's already done. The work is already done. There's at least one solution that exists now and it's being used and implemented.

So it's not an ethic, then explore it and discuss it. And then I don't think it should be in scope to implement. Other maybe that we have to explore expand our scope. But I think that's an awfully large chunk to take off.

Or your hands up.

Yeah. So I mean, it seems like we're dangerously close to talking about actual stuff here. So I just remind people like we're, the purpose of this is to get to the point where we can agreed to have deeper technical discussions. So for me, like the language is clear enough that we, you know, we want to address privacy and security concerns associated with the storage of data. And I just, I feel like if anybody on this call doesn't want to consider privacy concerns of storing data like I just don't understand how that's compatible within the rest of the charter. Like, it seems like we're not talking about a specific thing here. We're talking about accounting for metadata retrieval, private information retrieval, the privacy concerns around storing data. And all of that is is tech. There's technical solutions to that which we shouldn't be talking about on the call right now. We should just be agreeing whether we care about privacy or not.

Excellent point.

Q. Hey, Q. So Oliver is next on the queue.

The people who would be would object to encrypted indexes. I mean, maybe you're not able to talk about the technical details here. If you could, then maybe people would be not scared of this. But maybe you just have to change the language into something what orange just said like

more general life

Define implement or something.

Privacy preserving clearing or indexing? I don't know.

Kyle here up next.

Jonathan, if we said that it had to be efficient, so design and implement efficient encrypted indexing and search mechanisms, which makes it slightly more subjective. Would you feel more comfortable with that?

I'm sorry, what was the phrase you use?

Does discuss and implement or design and implement an efficient encrypted indexing and search mechanism.

How about defined best practices for privacy, privacy, preserving indexing?

I could work with that.

Um, Jonathan, you're next on the queue?

No, that's I think if we just defined best practices, I think it would be sufficient that we explore it, we would actually declare it. And we allowed to discuss it. I'm just hesitant as far as putting in scope that that's the because I think that the, the point of secure data storage as as me as a consumer, is that I can hop from cloud provider to cloud provider, and I have the same exact path to my my data that I can give no matter what underlying service provider I give. So and I think that's the standard. I think we're all working towards how it's encrypted at rest and how the it's provided. I think Is Up To Me as far as like, as a self sovereign individual, I declare in my verifiable credential or my service section of the document. So I think so I'm just hesitant because it it opens up a potential security vulnerability that actually is also just aids the service providers to muck with the data. So I'm just trying and or it's just going to be in boiling the ocean sort of problem of it's gonna be hard to design and implement. And but I'm certainly open to it and I'd like to discuss it and explore it. But I'm worried that actually it will be scope creep.

Let's see we've got the 40 go Ori or he's next on the queue. Followed by Dimitri. Just a reminder, I forgot to say this at the beginning of the call or he mentioned it. Do not discuss implementations do not discuss patents do not discuss, you know, how we're going to do something. So, Jonathan, you've you've touched on how we might implement this twice. Now, please stop doing that. Because it's it's a, we can't get in into that. So just try and avoid saying this is how we do it, or we did better than a, you know, a VC or we'd configure it like x or y. We have to avoid doing that because we have zero IPR protection in place for the discussion or a Europe.

So I know we've committed to a reference implementation. And I'm just wondering whether Jonathan, you are you objecting to any adjustment of these privacy concerns in the reference implementation? Is that what No? Okay, so would you object to language such as the reference implementation, we'll explore best practices for preserving user data in ways that are compatible with decentralized identifiers.

Really

great.

Okay, hold on Ori the reference implementation will explore best practices for preserving user data

privacy.

Can you remember what I said? You the data privacy, integrations involving decentralized identifiers.

Dimitri, you're up next. Thanks very much.

Just wanted to reiterate that we had design and design or identify is fairly standard language that we've used for a bunch of the other items. I'd rather not have this exact argument for each item. I mean, the pattern is clear. These are hard topics. Some of them are are optional and modular, like access control, like privacy, preserving querying and stuff like that. Everybody understands that we don't want to reinvent the wheel. But if there are existing standards, we're going to use those. Can we just pick a standard phrase like, design or identify and not argue about it?

Right, thank you, Dimitri. Next is Troy followed by Daniel. Go ahead, Troy.

Hi, I put the comments into the chat as well. But I think I have two points. One of them is I really just don't want to discuss. I think it's important that those discussions lead implementations. So I would object strongly to wording that's just about exploring or talking or this kind of thing. Secondly, I want to be able to interact with others. So simply talking about reference implementation, exploring it, I also think is not a sufficient solution. I like the first couple ideas of how to phrase this finding right Implementing the privacy preserving indexing or querying, and also the original text.

Great, thank you, Troy. Daniel, you're up next.

Yeah. Unfortunately, I was just able to on Call now for family reasons, obviously.

And Daniel we barely can hear you.

Yeah. Okay. So Is that better? Yes. Okay, so I was just able to go on the call now. I'm sorry. I see that the encrypted indexing and stuff is here. Is this is that if you already past that,

no, we are currently discussing what the language around that's going to be.

Okay. I mean, my biggest thing is, I really want to see that as optional, both not the ability to say everything has to be encrypted and not forcing encrypted indexing. I think there's tons of great cases to be made for data that user would intend to be public, specifically, not and this isn't to be like big, evil corporate, like I just think there's lots of things that people will absolutely want to be publicly broadcast and I want to make sure to allow For those things to be optional, those extra added features, if possible.

Yep. So so that that's why the original language said and encrypted indexing mechanism and didn't say it was mandatory for everything or required for everything. So yes, I believe that this is an optional feature, not a mandatory feature that everybody must implement.

Right? Awesome.

So. let's see. I'm gonna go ahead and put the link to the document in here. If folks could go in and put a, I'm gonna say put a let's see a x by the ones that they absolutely don't want to see

in the document that might have Help us get a get a poll from everyone since we don't have a very decent chat. So things that you would be completely opposed to.

Okay, and then while we're doing this, if you can go ahead and put on put an O beside the thing that you'd be totally fine with, like let's just get this in there. As is

Okay, I'm gonna wait for that to settle.

Okay, I think there's a pretty clear feedback from folks that they don't want to just talk about this, they want to do something about it. The top option seems to be the one that has the most amount of alignment, there's nobody just objecting flat out to the first item. And the second one has a little bit weaker support, but again, nobody objecting to that. So I'm going to eliminate the last two, because it's clear that those aren't going to work for the group. In, we're down to these two, right now it's pointing towards the top one. Jonathan, after seeing that, do you do you have any modifications? Because we need we need to keep going.

No, the first ones fine. I just have reservations as well and Okay, I'm objecting.

Okay, great. All right. So that goes in there.

Let me take off Edit Mode. go into edit mode.

Okay, so that's in there.

And let's let's see in the last one left in this category was focused on in focus on an HTTP API for the implementation, which is basically just route is saying exactly what this says up here. There is a question on whether we need it at all. Or if we just want to go ahead and restate it just to be clear. So uh, would anyone object to us adding this as Strictly in focus, or sorry, strictly in scope, focus on an HTTP API for on weight focus on an HTTP.

Based let's see HTTP sorry, based

interface for the API. Yes.

Would it would it would pay to, obviously, what the current state of the spec, you can almost say that that's reasonable in nature, would it pay to mention that term? Or is that going too far to qualify the night through the API?

So it would Yeah, that's a great question. Let me check, check to see if there's a queue now.

I think

that's a great question. Typically, when you talk about HTTP API's versus RESTful APIs, if you say restful, you'll get a number of objections. And it might be More limiting than folks might want to do if we say HTTP API, restful is still very much in scope. But it doesn't absolutely mandate that we follow, you know, Roy fielding things dissertation to build the API out. We could mention it. That might be one thing that we could do. So I don't know if that helps to bias.

No, that's okay. So we're like, I'm, I'm not like that strongly, strongly. So sort of biased either way. So we can later kind of generalize at this stage.

Okay. Would anyone object to just that we just waited we don't have to actually write this down. Because restful is a subset of HTTP API. So it's definitely in scope. Would anyone object to having discussions around RESTful APIs as being inspired Go. The assumption is when we say HTTP API, they they are in scope, at least being able to talk about restful design. Okay, so so we have it on the record that no one's objecting to that, which means that we shouldn't be scared to not not mention it.

Or I'm happy to take over.

Awesome, thank you, Dimitri.

All of our year on the queue.

Does this excludes other API's like graph qL? It obviously.

Um, so we have a

if you if you run it over HTTP, no, it doesn't, right? But if you run it over UDP or NFC or Bluetooth, it could potentially we still need to talk about that. But if you can run it over HTTP, then it's Potentially in scope.

Okay.

Um, George, you're on the queue.

Yes. Hi, I'm just wondering if we are going to base the if we're going to focus on an HTTP based interface makes me wonder about whether the semantics of these queries will be based on the will be imbued in the messages themselves? Or are we relying on the transport? And also makes me wonder about how we are going to protect the user's privacy with regards to how the queries are transported over the network? Because I see we already have verbiage saying yes, we're going to encrypt the data on storage as transport. But I'm not sure if that also includes the queries.

That's that's an excellent set of questions that you may need to be discussed when we're actually meeting like I might, my expectation is that all of those things are in scope to discuss. Because we have, you know, we have various things. So you're kind of getting to the how I'm asking questions about the how that we're going to do this. And we should probably wait until we have IPR protections in place. Well,

well, if we're, I get it. We're discussing scope right now. But if we're saying that in in our scope, we'll be focusing on an HTTP based interface. I'm not sure we're like already Locking our scope within a certain like, architecture or something I'm not sure. And I guess what I'm saying is it's not clear to me this is the verbiage of this point we're discussing is not entirely clear to me what the scope is.

So here's another way to or he's actually asking the right question. Would you object to this sentence being in there focus on an HTTP based interface for the API mechanism? Because because that doesn't say, you know, that that doesn't necessarily force a certain type of approach the API, right? You can still do dead calm over it. If that's something that that people want to do. You can still, you know, do binary message passing over it if that's what people want to do.

But there's a general You know,

there's it, it gives us something generally to focus on right rather than not having not being specific about the type of interface that we'd focus on.

So my answer is no, I'm not opposed to http.

That's my answer, basically. Okay.

All right, I'm looking at the queue, is it?

Johnny took himself off.

Okay, queues empty. Okay, so let me ask the question again. Would anyone object to focus on the language focus on an HTTP based interface for the API mechanism?

Okay, let's go ahead and put that in there. And those are all the scoping statements and my expectation now, is that all over Are you happy with the mention of encrypted indexing? Does that resolve your concern around that?

I didn't have a concern. I just wanted to mitigate other people's

concerns. So I'm fine with that. Okay,

all right, does. Okay, so I'm gonna go ahead and click resolve there. Troy, can we resolve your concern here? Since we put the encrypted index stuff in,

yes in chat. Okay, thanks, Troy. Um, let's see, what's this one?

Yeah, so this kind of goes against what I what Daniel wanted.

Let's see,

designing cryptographic security architecture that protects data entry incident and rest, noting that different approaches may be taken for data in transit and data at rest. I'm Daniel, do you have any concerns about this language? preventing, you know,

we could also, I mean, as long as we could say the user can and doesn't say in the way of the user saying I don't want a protective data encrypted. You know, that's all, like their resume, for instance, that they might want everyone to read and not encrypt whatsoever.

Yeah. Okay, Kyle, you're on the queue, then.

I think I may be jumping the gun. I just wanted to clarify my question that I put in the out of scope section. So I'll drop my hand.

Okay. All right. Yeah, I mean, I think the, I think we've covered this case, like a lot, Daniel. The case is basically we want to support encryption. And we also want to support non encryption for people who don't want to use encryption. So I'm very familiar with your arguments about this and the identity hubs thing. And at this point, I think we're fully working towards a world where you get everything you want here. So just yeah,

I mean, I trust I trust everyone in the in the group. So yeah, sure.

Okay, would anyone object back to what origin said you disagree with what you just said.

Okay, good. Remember the call is recorded and transcribed. So, there there is no objection to what we just mentioned. And we also have on the record that Daniel trusts all of us, which is great.

Finally,

let's see. We wordsmith this as Leonard rays. So I think this is fine. Um, Leonard, are you here? No, but I think we addressed it's concerned because we added that text right there. data in transit. Um, okay, do we care about protecting data at rest from any future quantum computers or just classical ones? It would seem prudent if we plan to support long term data storage.

I think what we're

saying here is that we'll you know that we haven't specified exactly what mechanisms and encryption mechanisms we're going to use. And it doesn't preclude us from using quantum resistant algorithms. So I think we're addressing ions. concern here. I know you here today. Would you mind speaking to this it specifically not in general, but is there anything that you feel that we need any language you feel that we need to put in here to address your concern?

You might be muted or you can feel free to just type in chat.

Please, okay.

So you wanted to mention quantum resistance as a goal would anyone object to mentioning quantum resistance as a goal for the working group, meaning that we whatever we it is a goal to develop a quantum resistant mechanism for encryption in data in transit at rest.

So I can make comments Oh, yes, yeah, there you go. Go ahead.

Yeah, just just to, not necessarily,

just to bear in mind as well. What I'm saying because

it might affect design design decisions if that's that's a design property.

Got it? So you would you you want to make sure that it's it's taken into consideration, but you're not suggesting that we use one of the new quantum resistant mechanisms. Nothing new. Okay.

Let's see. Um

Let's see, how do we how do we how do we wire this?

In Would you mind working on some language that we can come back to? Sure. Okay. I'm gonna have a hard time wordsmithing that. Okay, the next thing up is this replication stuff. Steve and Daniel went back and forth a bit. I don't know where that discussion is, but I think we ended up with language that was fun was what everyone was happy with.

Steve, are you here? Yep.

Okay, um, are you happy with the language that we have right now? Yeah.

Uh, yeah, I think in sure maybe is a little strong word.

But I'm fine.

Okay. I if you have a better word, we could consider it now. Daniel, are you fine with the language here?

Yeah, I mean, I think it's the intent of what those two very technical things need to be able to do. So, yes.

Okay. Okay, I'm gonna resolve this then if neither of you are going to object to that. All right. Let's see. This next one hands. George This is just, you know, it was a list supposed to be a list of items of the working group will this and that and this and that and this and that. And then finally, At the end, we can delete it. It's an editorial thing. What would you prefer George?

I'll just delete it, but

there you go deleted. Um,

okay, and we do need to go in and clean up some of these commas and

stuff like that.

Okay, on to the next thing. Okay, so we're, we're basically done with the scope. That section is done done. We we're not going to come back to it except for maybe this inshore language and then Ian's concern.

Okay, I'm out of scope.

Let's see, Kyle, do you want to jump in here and ask the question?

Yeah, I'm not really an objection, just more of a procedural question because it can be done in other working groups. Does this per group approach clewd this working group from registering things and

existing registries,

it my my read is it doesn't it what it precludes the group from doing is actually inventing new crypto in the group in the diff SDS Working Group. That doesn't mean that some other like the CFR g continues to operate and they do something neat and new that we can use. We can still go out and pull that in, because it happened outside the group, but specifically, this group is not going to work on new cryptographic mechanisms.

Perfect. that resolves that statement, then thank you.

Okay, thanks. Um, let's see, what's this quick?

Why is that not popping up? Um,

I don't know what's going on there. Okay, so, here are the things that we couldn't agree to last time.

These just needed wordsmithing here down at the bottom. Specifically, the thing that was added was the bit at the end here.

Except all these changes.

Okay, so, um, there was a concern that we were going to invent there was a concern that we couldn't use authorization capabilities in the working group. And so it's been further clarified along lines of the the clarification that we just made for Kyle out of scope, his invention of new mechanisms for authentication or authorization, and invention of new mechanisms for querying or inserting data like SQL or Gremlin, the bit that was added was at the end. I do not use mechanisms that are not standardized and not work items of the W three CCC dif or existing standards working groups. So that's the language is is is the same? There. It's the language is a little complicated because it's all the double negatives. But it's basically like if if somebody else in some other Working Group hasn't invented it or hasn't standardized it. And it's not an active work item. We can't, we can't and we can't decide it invented here. Right? So that's that both of those things are out of scope. Would there be any objections to either of those statements as out of scope statements?

mono I just I know, this is only an example less, but I just want to be clear that such as HTTP signatures, which is a work item that's going you know, being dispatched for sick dispatch group that's in scope. We can use that

correct. Okay, cool. Yep. And it's in scope, specifically because the HTTP working group is picking it up in they're going to standardize it. It's in in transit towards a standard we can see it headed that way. Cool,

great, Any objections?

Okay, I'm gonna lift both of those up here

and

put that in Okay, the last last item left is this is out of scope design or design or development of non HTTP based API's such as API's over Bluetooth UDP, NFC,

carrier pigeon, any of those things out of scope.

So we are basically focusing on HTTP

Any objections?

What about

this did come completely out of scope and did calm mapping. I mean, that could always be done independently, but I'm just curious is it strictly HTTP only?

So Sam, Sam gave you your your answer in the chat channel so it did come can happen over HTTP.

Okay, can we say something where we'd like to take care? You know, I don't know how you would say this, but I don't want to do anything because hcps or target that would fundamentally make it like, impossible or really, really intractable to do it over another, you know, is there language that we can say like that, like, take care to at least analyze? What we're, what we're saying reflects on those other transports.

I get what you're saying. I don't think that's easy to say. And, and I think it's, it's more of a part of the discussion, right. So I think we have enough other language here. Where if we, if we, we, if we make it if we tie this protocol so tightly to you know, HTTP or we prevent any other protocol from being able to interact with these systems, then it people are going to object and have issues with it, right? So we're gonna, we're gonna talk about it about it. If we Looks like we're headed down that path.

Sure, that's fine. Okay.

I'm not hearing any objections. So I'm going to put this in.

As So actually, I I don't think we sit explicitly state that we're excluding the possibility. So I think because we may actually in the working group come up and say really, that maybe HTTP isn't the right protocol, but we focused on it. We actually gave it our all. But actually, we realized, actually, there's a better way of doing it.

No, it might be.

Well, yeah, I think that's the problem is that is that we've we've said multiple times in here and have gotten agreement on us focusing on an HTP based interface. And so but now This contradicts that which is where we're focusing on HTTP based interface. But now by by keeping it out of scope, we're only doing an HTTP interface

or You're on the queue.

Yeah. So can we start with I object or I don't object just so that we don't get a ton of comments without any kind of clear understanding of whether there's a real objection in there or not. I think the intention behind this language is specifically so that we don't get derailed by people's prefer transfer mechanisms when we've clearly already agreed to focusing on HTTP and a limited scope for this work. So I think I may have contributed this language initially. And my intention was to prevent people from D railing the working group with their own preferred transport mechanisms and just focus being focused specifically on HTTP. Obviously, we can design HTTP in ways that are supportive of other things or not supportive of other things. I think we already have carved out plenty of room to discuss that in the working group.

Yep. So Jonathan, are you objecting to this line?

I think it just shouldn't be there.

So you are objecting? Yeah. Okay.

We will come back to this then.

So I'm going to put it back in suggest mode.

And we're going to have to come back to it.

Um, let's see.

I'm going to try and since we're running out of time, I'm going to try and do a blanket.

Is everyone okay with

it with with saying that we're going to coordinate with these groups, my data a new governance, which I think Kalia is, is a is a different group. This big data public Working Group cncf ISO standards. Would there be any objections to listing these these entities as coordinating with them?

Okay, I'm not I'm not hearing an objection here.

Oliver, go ahead, you're on the queue.

What does coordination mean?

someone telling them what we're up to from time to time. So that one did. The next question I was going to ask is who's going to volunteer to coordinate with these groups? Because if we don't have a volunteer for it, we're going to strike it.

Okay, great. Thanks Oliver. no objection mark, you're up.

I'm volunteering for the groups that are listed there that I know about. I'm not in my data.

I can cover NIST IEEE I so

that we don't have

HL seven in there.

Just Just a Just so people don't think this is too high stakes, we can always change. We can always add a group later, right? It's not this is not like we can never talk to anyone other than these ones. These are just the ones we know of. This is super lightweight and part of it is to attract other people to come pay attention. Yep, exactly. Okay, I've got your volunteer to liaise with these groups down. Thank you. Mark. My data, Kalia.

Kalia, are you? Let's see, yeah. Adrian also said he'd help.

All right. All right. All right. So we've

got, we've got this tick covered. Brilliant, okay. All right. So we've got all of these in. We've got volunteers for it. So they can all go in. So I'm going to go ahead and put all those in. Just mode, and I'm not hearing any objections. So they're all in Okay, that's the coordination section.

got six minutes left, let's see if we can do this one.

There was a request for rewording Daniel, I think you asked that we record this last time, so I think they took a shot at it. I'm just gonna pull his changes in.

So here's, okay, well, maybe it was someone else.

Someone asked for it to be rewarded before we put it in there so that the group will build solutions that are focused on the needs of the individual, but that are also compatible with institutional needs. The group desires a level playing field where all participants can achieve their goals. Are there any objections to that new language? Or the goal in general? I made a suggestion

Oh, With commercial offerings,

what about non commercial offerings? Is that is my mic, you know, we put commercial offerings in there, then all our nonprofit things like not included. That's why we just put needs in there. Would you still want your commercial offerings language in there somehow?

It's just a the approach is towards the individual has been the consumer, or user. And I think if I had objected to the original phrasing, which put the institutional needs first above the consumer, okay,

all right. So what about and or commercial offerings?

Okay, I'm gonna resolve that any objections to this item?

Okay, that is in and I believe that modulo the very thing At the very, very top is everything. So we do need to come back next time and cover this. Hopefully it won't take too long. And then we'll you know, need to make sure we'll make another pass just to make sure. So if you've got any concerns, mark them in the document for the next call. Next time be ready to talk about use cases and requirements. A large, we should probably create a Google Doc in move some of the use cases requirements from identity hubs and the encrypted data vaults spec into it just so everyone has the ability to edit that document. Below, do you want to say something about the next next meeting time?

We could either doodle it or we could go back to last week's meeting. That was Then the MDT on Friday.

I think it's up in there

yet, these are the options or we can just Google it and see what happens.

So people might be getting doodled out.

I'm wondering if so so Kyle Tobias, my expectation is that you'd rather this time then then at 10am, Eastern Time, forget what time That's for you.

Yeah, that's about 3am our time.

Yeah, that's pretty terrible. Um,

how about that? Well,

that's preferable because the other one that we had at the start was like, 6am. Saturday morning. Yeah,

yeah. So let's let's do you know, Thursday, um, what? It's the Europeans that are feeling a bit of pain right now in the call time. Amy, any Any other markets any other Europeans have a preference? Like is would this be okay, I know it's painful but okay, Amy's Amy's willing to do this time

Okay, so Balazs let's let's try this to Oliver saying okay. Oh yeah, next week's daylight savings. So, okay, so let's keep this time So next we'll have this call again next Thursday 4pm. Eastern.

And, and go from there.

Okay. Again, great, great work everyone. We've You know, we've really knocked this charter out in effectively like three meetings. So that's that's really difficult to do. So thank you everyone for working towards that. Please Put in comments if you still have them into the charter. Otherwise, we'll basically finalize it during next call, and then move on to use cases and requirements. All right, thanks all. Stay safe, stay healthy, and we'll chat again next week. Ciao.

Thanks, everybody.

Thanks, guys.

Thanks a lot.

Thank you.