Secure Data Storage - WG
7:48PM Jun 18, 2020
Hi, everyone, welcome to the secure data storage Working Group weekly call gonna give people another minutes to file in.
Okay, it is two minutes after
the agenda. Moving on is in chat.
We know several people are going to be late I think man who
is on another call that's running late
but let's get started.
First up, as always a reminder that one this meeting is recorded to everything that you say any substantial contribution that affects the spec that you make is subject to the intellectual property restriction agreement, meaning in order to make contribution, you have to sign the IPR agreement for the link to the IPR agreement. We will post it in the chat it's found at the bottom of the secure data storage Working Group wiki. So
right, so you're gonna say something that's gonna affect the spec, you need to sign the API agreement first. Moving on, let's do introductions. Who would like ah, who has not introduced themselves in previous calls.
Raise your hand.
All right, Wayne Grande. Introduce yourself,
everyone. My name is Dwayne. I see a lot of familiar names here. So great to see you all again. But I currently work on the claims and credentials group within the diff as a chair up and working in presentation exchange with Dan Buckner and I'm recent I'm the newly nominated chair for elected I guess chair for the W three cc CG. And you know, hoping to drive more participation there and interoperability between different there so that's me.
Thank you again. Let's do let's do one or two more ganache. Have you had a chance to introduce yourself?
I have not but I can go ahead My name is Dinesh, I work at Digital bazaar. And I play a cross functional role doing everything from core implementations of some of the things in a spec to integrate them into products. And then pitching that in working with industry, both public and private, then figure out how to roll these solutions into products that
will will help their business use cases. So from business to to engineering, I play the bridge role
at my company.
Thank you. Perfect.
And one more now I forget. Jonathan hold. Have you had a chance to introduce yourself?
I believe so. I can. Just myself again, yeah, let's do let's start our reintroduction section. Why not?
Go ahead. And Jonathan whole time a triple board certified physician, board certified internal medicine, clinical genetics and clinical informatics. I have three companies that I'm involved in, but the tech companies are transcend x which is my own company, which is a healthcare interoperability. cryptographic identity company, mostly working on verifiable credentials. My contributed the IP ID did method which is built on top of IP Fs and more specific IP LD. I'm a member of diff through transcend x, but I'm also a the CMI Chief Medical Informatics officer for consensus health, which is a partially owned subsidiary of consensus.
Thank you so much. Glad to have you here. Okay, so let's dive into it. today. Our main topics are naming things which is hard and taking a deep Dive on a very first lowest layer of our secure data storage spec. So, first up, we still have the open question of what are we going to name? Our spec? If it's going to be one spec or two? And do do we keep or change the name of the working group? So currently, we have three proposals. I
recommend everybody take a look at the following comment
on issue 35. So as a reminder to weigh in, we do want to resolve this question as soon as possible. So that because with every day that passes before we change our name, that affects our SEO, branding. I don't mean to say Like this is
a hot new product, but that matters. All right, go ahead.
Yeah, so um, it's been a little while since that issue was created. And one thing I've noticed in the conversations, particularly around the higher level API's, identity hub like concepts is there's a tremendous amount of complexity and that layer, and also, it's far less defined or concrete or specified. So one of the things that I've been kind of encouraging us to think about it, think about encrypted data vaults as like a first layer, which you might even be able to cut and use and would be valuable by itself. And then to think about hubs as a set of features on top of encrypted data vaults that give us that higher level API that we like, I find the naming actually still useful to separate them logically, in my mind. So It just just food for thought. I think I my personal preference would still be one spec. Two different names for these, these two different layers. And to kind of go from there.
Thank you. Anybody else?
the lower layer, how many sub layers is that? So in other words, you know, the whole point of my comments in this in these threads is that the access control layer, the policy decision point needs to be separated by a standard in a standardized way from the policy decision point. And and enforcement point, I mean, and so that, you know, this idea of there being a higher level above that, that's called the hub. Sure, but that's not the problem. The problem is at the storage layer below it.
Thank you, Adrian, do you want to remind you like that is an excellent comment. It relates more to our next topic, which is, how are we going to name the layers, whereas this is more what's the overall spec going to be named. But please, please add a comment to the to issue 35 namings back with what you just said, Sergey, I believe you're next on on the queue.
Yeah, my my point was going to be exactly what you've just discussed, Dimitri, which is are we going to name the layers individually, from the data charts perspective, we would be interested in potentially being the lowest layer that's specified in the spec. And we have an interest generally in have in retaining the name of our of that specification separately. So for us, that's a very important. It's not just a layer a, but specifically having that identification as data shards. So that's very important to us personally.
Thank you. And that makes perfect sense.
As So, naming of the layers is going to be our very next topic, and I believe the current proposals is to name the layers separately. We're going to argue what we're going to name them, but I think it's compatible with what point you're asking. In addition, though, we do want to figure out, what are we calling the overall spec, the overall Working Group, in addition to the layers but we very much look forward to working with data charts community on on that particular layer. Let's see Daniel Buckner is up next.
I had a question for you. I'm trying to understand exactly what the effective statement what was is the effective statement that is cordon off a set of the lower layers and call that EDP. And then within the same spec, we would group the higher level potentially these higher level layers as you see them into a separate section, the spec that is called like something like hub or something like that that actually says these two together sort of like Voltron become this this thing is that kind of I see you nodding your head. I think that's Yes. Can we put that on the record?
Yeah, I'm gonna put it on the issue exactly what I mean.
Okay, thank you. And just as a reminder, don't forget to lower your hand to speak. Zoom doesn't do it automatically. And I don't have post access. All right. Anybody else have comments about the overall spec naming issue?
so in my latest comment in a different issue, I raised the possibility that we might want to have two different spec names at this top level. One of them talks about storage related to what I would generally call wallets. I know that's not necessarily a clean name. And you know, where you're storing basically keys for whatever reason, and they could be from the private keys for portability reasons or backup reasons or God knows what. And and the other one would be the kind of stuff where you were talking about playlists, and general app services storage related to SSI, but not strictly related to the wallet functions. And my my proposal there is that if we could recharge ourselves or split our charter or whatever that technical process was into two these two separate things, we would still be the same people at the table doing the same job of the current charter. But we would end up with two different names at the top level.
Makes sense? Thank you. Reminder as always, so that the common doesn't get lost, do leave it or link to it on this naming issue. I and I'm glad you mentioned the charter because I was going to point out that we, as it stands right now, we specifically left key management and key storage out of scope. I think Jonathan Holt is next on the queue.
So just focus on more of the sharing capabilities or exchange so secure data share, or secure data exchange because it has more more to do than just the vaulting of the storage of the data, permissions and so much of actually the interoperability and be able to send an invite or exchange secure information is key to this specification.
That's a very good point. You know what I'm going to say leave a comment on the naming issue.
So that we don't forget.
Michael share, how do you actually pronounce your last name? Shea. Shea. Thank you.
So I guess a question on
splitting it into names is the implication by if two, they end up being two different specifications that one could be the one to be removed and replaced by something else?
Yes, I mean, versus having one full specification that includes both things. Does that make sense to the question makes sense that what we're implying is that you could take the lower one, throw it away put or are they are they are they intimately linked?
Michael, I don't know I'm saying all I'm proposing is that we would converge much faster. consensus if we did that.
Well, I think that I think we're all here for the consensus yet. Don't forget to get in the queue. Adrian
Orie, I see you're on the queue. Do you want to respond to Michael?
Yeah, I mean, basically, like, I'm just noticing that there's a grouping of features that are commonly associated with hubs, which are less far. They're, they're higher level concepts. And so as an engineer, I like to think of these things as sort of a set of intermediate capabilities that maybe don't represent the interface that everyone wants to have. And you know, you can think of this kind of like, some of the internal API's that Firebase provides, are they're kind of rough to use, but then they have another set of API's that are higher level that are built on top of the same interface. I think if hubs fundament don't support the same features as encrypted data bolts, they don't belong in the same specification. But if it's possible to have a set of like raw lower level API's that are useful to either themselves, and then have a set of advanced API's that are an extended feature set and capability set on top of them, that feels like a something that I'm familiar with as an engineer working with various other database data structure, like things out there, orbit D B's structure is another good example of this. They have a set of lower level API's, and then instead of higher level API's, and the higher level API's are really great, but you it's it's not the case that it's just like those lower lower level API's don't exist, they exist, and they're actually built on to get to provide those higher level API's.
Michael. I hope hopefully that answers your question. If not, please come back on the queue. Daniel. Go ahead. You're next
I think my only reservation or not only but a significant reservation for splitting them into two specs and thinking along lines, what Michael actually said is kind of what I'm weary of, is okay, well, can you just swap the lower layer? Now, if swapping the lower layer meant the top layer was completely 100%? compatible, somehow like, then then that'd be okay. But I don't know that you could actually do that. And here's the reasoning like our target. And this is my own Northstar, and I think it should be the group's Northstar is that there is something inside of a browser that accesses personal data store. And it's only one type, the browser doesn't have 50 different native API's for 50 different combinations of personal data store because no browser is going to no implementers are going to do that right? In browser land. they implement one thing, right not 50 different index DBS one index dB. So as long as you could say, if you swapped out the guts of that, that it would somehow magically completely work. exactly the same. Maybe but I think that's kind of like Not likely. So they probably should be one thing and it should be, you know, completely. I think they're Reliant in that sense. If you want one output that everyone shares across the planet, you know what I mean?
Makes sense. Thank you. So it sounds like we have proposals that hadn't been split into two specs. And then a number of proposals that remain one spec, the current three proposals that that are linked to from the agenda item. I believe those are orys. Yep. Are outlining a single spec. So they're talking about name of the working group name in the spec, and then what do we call the example implementation? So as always, we encourage everybody to leave issues. On that thread. We want to get to a point where we can at least do a straw straw poll on which direction we want to go, man, I see you in the game.
Yeah, just just make sure that no one feels like this is a super huge decision we're making right now. I mean, so usually what happens in these groups is you start out with at one speck until the speck grows and grows and grows and grows and it becomes obvious that it really should be two specifications. Right? So um, you know, starting out with two specs has a variety of, you know, concerns I think, you know, people are worried about the coupling it too early. Starting out with one spec doesn't mean that we have to start stay with one spec. If, if the spec gets to be, you know, 500 pages long, we probably need to split some stuff out, right? Or if it's clear that, you know, one part of the spec can kind of live on its own. It's a good example of something that should probably be split out. So it's and it's a, it's a, it's a fluid discussion, it always is in just about anywhere. Working Group. So, you know, I don't want folks to get too concerned about this decision right now, because we can always split later on. It's true that we could always merge later on. But, you know, splitting things prematurely can can lead to a
variety of issues. That's it.
Thank you, man. So we have heard both out loud and in chat number of votes for having him be a single speck. I do want to point out that, if that's the case, we're back to the problem of what do we name that singles back? I believe, man, are you specifically had concerns on leaving it as the secure data source?
If you want to speak to that real quick?
Sure. So the I think the intent and the creation of the group was to call the group the secure stare is storage where Working Group It was not the intent especially if this editor to name the spec the secure data specification I think it's the the names entirely misleading. I don't know if we're like shedding the name right now. But but so they're they're just concerns because because when you use a word when you call something, it's already happening. Right? So we've we've been on a number of calls with other people that are now calling this, you know, the secure hub specification, everyone's getting confused. So they'd like mixing all kinds of different things together. So we need to, I think, be very clear about what we name these layers. One, they need to be very, they need to convey very clearly what each layers doing. And then we may call a set of layers together something but certainly starting out with, you know, secure data storage is I think, a mistake. It's it conflates a whole bunch of things together that that never should have been completed.
That's it. Thank you, Mona. You absolutely right. We don't want to bike shed the name on this call specifically, this is just a reminder of the of the issues at play here. One name versus two. And if it's one name, what's that name going to be? There are several people strongly opposed to leaving it as secure data storage so please take the arguments to the issues as always. There you go. One propose that in the in the Should I like it shed is a great acronym. Okay. So let's move on to the other naming discussion.
Various amazing proposals and chat.
Before we move on to the other naming discussion of layers, Does anybody else have anything else to add to the spec naming issue?
I think there's consensus in the group that we want to look at this whole set of problems and use cases through the lens of layers. And if so, question becomes what are we going to name the layers? At the moment? We have two proposals, one from Kyle. Ah, which is issue number 44. And one from Ori, the alphabet proposal, which is issue 74. Does anybody have so this so first of all, this is a reminder that those two proposals are out there and we should probably converge on one Kyler or Isaac Kyle's on the cube. Perfect. Please. Hi.
So yesterday, actually Actually consolidated the two, since I realized the topics are together, so I took the two proposals from issue 44 and posted it into the Bleep it's Auris, which is 35. And so they should all be together. And in there, I left the comment, basically saying, I like the direction that Ori is heading with it. by splitting it up more. I think it makes more sense in terms of like a architectural standpoint, to be able to understand what are the responsibilities of each layer. And so my i'm in favor of what wery has proposed so far. But Danny was the second proposal that was in that thread that I closed, so maybe he wants to come in as well.
Thank you so much, Kyle. Daniel, do you have any comments? I no longer care. So
whatever you want.
So then procedural question to the editors. It sounds like Kyle wants to merge merchants proposal, or rather to support the alphabet proposal. Does that mean? We can mark Kyle's issue 44 as pending close?
I think he closed it already. I'll close
it. Alright, great
question, though. Just from a process perspective, although it's, if it's your issue, you're responsible for moving it forward. If you feel like the best thing to do is to close it. But there's been a lot of discussion by the group, you might want to ping the group and say, Hey, I think we should close this issue. I think we should move our discussion over here X, Y, and Z. And like, let people object if they feel like they've put a lot of effort into that issue, and they don't want to see it closed. But generally speaking, if there isn't a serious objection to it, I think probably at exactly the right time. And you can always object written request that the issue be reopened.
Okay, fantastic. So
do the editors and chairs have any thoughts on? How do we want to do this? Are there any competing proposed naming proposals to the layers? Do we want to adopt it for now and if somebody has objections, we raise another issue another PR.
Agent Go ahead.
Yeah. So I'm fine with layer one being the storage layer.
concerned about where the secure spying or the policy enforcement Point is, so if we're looking at Kyle's comment, for layer, the naming of layer one, two and three, it's not clear where the policy enforcement point is, across those three layers. Is it layer four? Is it between layer one and two? In other words, is it in layer one? There's a lack of clarity there. So I'm not objecting to the names per se. But that's the the elephant in my room.
Thank you. That makes sense. So are you doing speak about?
Yeah, so I mean, I think my recommendation for the group would be that we tentatively sort of align around the alphabet proposal as a structural vehicle for proceeding through the layers and that we start at the first layer, and we spend as much time on each layer as necessary and that we consider renaming the layers We spend time on that layer itself. And you know what the another way of saying that is that I think the names for any layer other than a layer that we have reached consensus on are made up names. Basically, there's no one should believe that those names are real, because we haven't discussed the necessary prerequisites for the layers beneath it. To have that name in any way. Make sense? So I'm agreeing with Adriana, I think we need to start at the first layer. And as we go through, we will be able to name the layer something that reflects the consensus of the group. So right now, we have the proposal to proceed with layer a, and that's the first layer and we're still trying to figure out what that is. And there's layers bc whatever, but they don't really have any names because we haven't gotten through layer a in my opinion.
Thank you. That makes sense. I see a lot of plus ones to a Tories proposal here in chat Kyle, you're up next.
Yeah, so just to address Adrian's concern, this is exactly what you said is the reason why I didn't, I proposed the right direction. It didn't split things out well enough. My intent was for that to fall in the integrity layer. It's so important that I think it should be a layer of its own. And that's why I think that that proposal is heading in the right direction. And this is also one of the reasons that I wanted to close my eyes in the first places. I didn't want to allow conversation to split and for these things to occur in two different directions when I really wanted to see things move in the direction of what already is proposed.
Thank you, Kyle, and we appreciate your original proposal to get the conversation started. I'm seeing overwhelming amount of plus ones in the chat and no objections so far. Man what you're up next.
Yeah, so plus one to one or you just said I do want to point out as we go through these layers, and I think we can use layer a as a as a good kind of exercise in this. There are kind of two things happening here at the layer in between layers. So, and this is this is the whole, like data model versus protocol discussion and you know, is a layer of protocol is a layer data model, is it both that kind of stuff, and we're going to have to get start getting pretty crystal clear about that, like, for example, layer a is byte storage, so we can assume that they are bytes at that layer, that's kind of a data model thing. And they're like identifiers for groups of bytes. That's the data that's kind of you can think of that as a data model thing. But then how do you interact with layer a well, there's got to be some kind of protocol for how you interact with layer a and those are the those are like the file system calls Let's, let's say one of the ways of, of messing with those bytes and identifiers is doing a file read or a file. Right. And that is kind of, you know, a protocol II type thing. I believe that probably every single layer is going to have some some variation of that. And I think some of the most interesting discussions that we may have is, for example, in layer a, and I've noticed that, you know, the data sharp folks are going well, you know, this is a pretty foundational thing. And there may be other people that feel pretty strongly about their their bite storage mechanism being a pretty foundational thing. And so I want to make sure that I'm into to Adrian's point, um, there are questions around data model and their questions around protocol at every single one of these layers. And I would like us to at least pause as we go through the layers and identify the thing. That our data model and the things that our protocol because that will help us further tease apart what the layers specifically are doing. That's it.
Thank you. It's a very good point that the layers are referring to both data model input call, can think of them as two halves. Does anybody have questions or objections about that?
Okay, so this is a perfect segue into a final topic of the call, which is let's dive into this layer a, we have a number of issues linked to
Yes, before we jump into that, there is somebody dialed in and I don't know who they are.
Um, it's area code 4493. If you can just tell us who you are. As for the attendance
It's one. Okay.
Thank you clear.
Really appreciate it.
let's, let's go through our issues we have
let's see, five or six issues that clearly relates to air a possibly other ones. Let's do an issue review or do you want to take this up or Tobias?
Sure. So I think the main the main issue, we have a single issue for discussing alphabet proposal letter A, and I've linked that in chat. And that's issue number 80.
I think there's a there's been a lot of comments on it. So if you haven't caught up with it recently, I think I think you should I agree with Manny's comments about data model and protocol. And I think my comment about this Layer Layer a raw storage, block storage byte storage, is, I think, I think we need there's there's a couple of things which we we need to discuss, but be very careful about discussing, because the discussion will quickly pull us out of this layer and into another one, which I don't I don't want to take us there. But I'm noticing from the comments, I think Ganesh brought this up before this layer is not concerned with what you're storing. It's about your capability of storing. So it assumes that you have the ability to store something, and with some identifier and get back that thing with some identifier. So if I were to describe it with a data model and an interface, one really naive and potentially terrible interface would be a get and set interface for key value pairs for bytes. So I think can set a block with an identifier and I can get an A block with an identifier and I get back a block of bytes. I don't know what's in those bytes. But that's kind of like what this interface, what this interface what this layers interface means. To me. It's something as simple as that. And I think in the discussion, you can see people discussing what goes into those bytes, like, what, what's the structure of those bytes? And I think one thing that would be super helpful for us to agree on is that before you can have structure, you know, that you care about, you have to have some kind of interface that's usable for reading and writing bytes. So that's my opening salvo. Who's next?
Search Go ahead.
So are you you bring up two excellent points. You know, Dennis Dennis shots, we've expressed interest in being this lowest layer. So to us, the the core issue that you've raised is and again, correct me if I if I misinterpret your words, but it's, from your perspective, what you need is a protocol or a set of methods that you can invoke to talk to that lowest layer. And it needs to be. And I'm not saying it has to be opaque, but in some ways, it shouldn't matter what's kind of going on, you have a getting set. And you should know that whatever happens is happening properly, but you shouldn't have to be then, you know, looking at the results and verifying it you just happen for you. Because data charts does want to be in that position. Does it make sense to have a set of methods or protocols or whatever we're whatever terminology we're going to use that specifies the those operations that you've, you've identified as you've identified getting set. Right, those are pretty good ones, is delete one, you know, things like that. So, and I'm not suggesting that we have to, but I'm just asking is, is that an important component of discussing the layers in general? Is this interfaces?
Adrian, go ahead.
So I'm not as much of a not at all a database person. So I'm just curious. You make it sound like the data model can be the lowest layer and the end it could be separate from the policy enforcement point and I'm just trying to gain clarity As to whether that is what you're proposing. Insane getting set? Are you assuming that somebody is signed into the database in order to issue those commands?
that that's just confusing to me. Thank you.
Can I add to that? Or is that please go ahead. So I am going to be honest with you. I don't know what you mean by databases. And when you talk about signing in, that gets into a question of authentication models and authorization models. That's also something that I think we don't want to discuss here. At this lowest level, the the analogy that I've been using with people is that many of us are used to dealing with files and our file system right. So I open up a document it's a file, I send you a file. Data sharks is interested in being a system, it's interested in being the lower level, that's the block level, because files are actually just collections of blocks. So that's where data shards cares about. And it sounds like from all the discussions that I've been reading, and I only got authorized to, to comment, you know, based on my signing my agreement for four patents today, so I can own that today. I can start commenting, but it sounds like that lowest level a is at that same level, right? Where it's not dealing with these these abstractions of authentication and sign in and, and files and everything. It's just blocks of data.
Thank you, sir. Jen, you're right Ori. So I think I'm up next on the queue. I wanted to reiterate exactly what Sarah said which is a layer a is below the notion of documents below. authentication and Identity is simply concerned with storing raw encrypted pieces of the files. And so he's not concerned with authorization at all. Nor Is he concerned with databases or any other storage medium. It assumes that once the bytes that you need to store are put into the correct data model, they will be stored somewhere whether it'd be a database file system or ipfs. Man, go ahead.
Right. So wanted to reflect a bit on what Sarah said and highlight while we're talking about layer A. So I think, you know, fundamentally this spec is probably not going to talk all that much about layer a other than acknowledging that it exists in implementations will use it. That's my expectation in here's why. I think the reason we're talking about layer a is at several points, people have said, Well, what about ipfs? Or what about data shards? Like, where do they fit in? Right? And this is basically establishing the layer where they fit in. Now implementers I'm in this is still an open question, but but implementers will probably choose to use one storage mechanism over another storage mechanism. Like, for example, I've got an IoT device, I have local storage, my, you know, implementation of this is going to use the local file system. Other people are going to say, Well, you know what, I really want this fully scalable content addressable storage. So but I want it you know, it to be encrypted, so I'm going to use data shards to do that, right, and other people might go, I really love ipfs and I'm going to persist my data to the idea PFS layer. So this is these are just three examples of where there isn't going to be one layer a, that everyone agrees to where layer A is, you know, you're using local file system, you're using a database, you're using data shards, you're using IP Fs are going to be many different choices there, that implementers are going to make. And we just have to make sure that the specification that we write enables that choice to happen, right? Because there's no way that all of us here are going to agree on any one of those things. They're just different things that drive us to pick different different solutions. So, you know, there's, there's a question around, you know, what's the protocol into into layer a? It's true, we could define one or another design choice that we have is just say, Well, you know what, it's up to the implementer. Right? We we just acknowledge that. There's a lot Letter A and it could be any one of these things and your interface into it is whatever the interfaces into ipfs or data shards or or MongoDB. So that's it. I, I don't expect us to do a lot of definition at layer a or the protocol to layer a. But I'm saying that out loud in case other people disagree.
Thank you, man.
I'm next time to kill. So it sounds like I want to clear up a point of confusion because I I thought we were talking about a different layer. Or did you mean layer A to B, the database and file system storage or encrypted chunks because I I assumed manner the thing that you're naming layer a, at least the way I read the proposal was a layer below D encrypted junk storage. So which one are we talking about?
surge believes you're up next.
Yeah. So, two man news assertion. It's very related to what you said to me last week on last week's call. I thought we had consensus that, that we were discussing chunks, and that those chunks were encrypted. So several of the, the technology choices that Manu described don't fit that criteria by by design, so a local file system doesn't encrypt chunks of data. It can be layered on top of a file system, but that's not what standard file systems do. And it's not what ipfs does. So so that's where I'm confused along with you about what layer are we talking about the reason and there's also some confusion exactly about what data shards is. For example, in contrast to ipfs Data sharks isn't concerned with transport. Data sharks is concerned with encrypted chunks of data and there and, and then the second layer of that we have two layers. So the first layer is just encrypted chunks of data. That's it. And then the second layer is updating. Adding a mute immutable layer to that so that we can point to different updatable chunks of data. So if we don't specify transport, and we don't specify types of stores that you may have, etc. So I think we do need to get some clarification on and some and again, reiterate the consensus that we'd reached last week about encrypted chunks of data.
Thank you, Adrian, you're next. So I
just want to go back to mine was a comment and others before him Ah, I don't Have a horse in this race, as long as I interpret monitor his comment, as this particular layer does not know, it's opaque as to whether the data is encrypted or not. So if we have this understanding that we're just talking about what I call the data model, and that would include chunking, and whatever else addressability, etc. Then I, I'll stop commenting, because I have no horse in that race whatsoever. But if we are presuming that the data at this layer is encrypted, by default, then I have a lot of comments.
Thank you, Adrian. Ori, I think you're next.
Yeah. So I think Adrian we there was some discussion of this topic on this issue and I I think the thing that's helpful here is maybe to backing up for a second without discussing layers, think about the, the fundamental nature of information. If I have keys that I'm in control of, I can use encryption to protect information. And I can do that without reliance on any other system or person because I'm the one in control of those keys. So the way that I think of this layer a is that layer A is a storage system, which is fundamentally not trustworthy. It's like any other system that offers you an interface and that you would you know, you would go to use that interface. And my the trust model that I come to the you know, this layer a discussion with is layers in our interface, fundamentally not a trustworthy thing. I will do encryption, where I'm in control of keys, I will bring data to layer a to store and layer a will store that data and layer a will return that data to me so I think calling layer a encrypted is fundamentally dangerous because it's unclear whether it's storing encrypted data or it's doing encryption. And so I think of layer as raw storage. And I and I suggest very strongly that if we're talking about storing data that isn't encrypted, we're talking about privacy violations here. So that's sort of like, I think, targeting the discussion that we're having right now. I think there's ambiguity around this is at the heart of this layer a discussion.
I think because I'm sorry, I just saw a man I'm posted in the chat. And I think because the primary record of this call is audio transcript. It would be great if you raised your hand man and said it into the
agreed. Thank you so much for pointing that out. Yeah, I don't Think Chad gets saved. So,
think it is saved, but it's not gonna be where people look to see the discussion. So okay, okay.
Yes, sorry. I, my next. Sorry.
Yes, go ahead. Go ahead. And then Adrian.
Yeah, sorry. I was I thought I raised my hand and I was thinking out loud by typing. Right. So maybe the clarification that we need to make is layer a is untrustworthy bytes storage. It's just where you put bytes. In we have a new layer B, which is encrypted block storage, encrypted block storage and layer B is where things like data shards come in. It's where the JW E's I think, come in, in the current ETV spec. I'm trying to think of anything else that might come in that layer. But I think that that may be the the thing that that was conflated before. What do people think about splitting it out? The other option is we are just like everybody knows there's untrustworthy bytes storage, like we don't even need to talk about that. And let's just talk about the encrypted block storage. The concern I have with that approach is that all of a sudden people are asking the question like, where does ipfs fit in? So, you know, layer a and trustworthy byte storage is, you know, ipfs MongoDB, standard commercial off the shelf file systems, things of that nature.
Thank you. Thank you, Adrian.
Go ahead. Yes, making this assumption that layer a is untrustworthy. Storage, whatever it is bytes or chunks is I don't think is acceptable to me. Because it's sort of pre pre judges. It sort of introduces this idea that layer eight is not opaque to whether the bytes are encrypted or not. We're going to be making assumptions about access control, or policy enforcement at upper layers based on the fact that we've decided a priori that in all of the cases covered by the spec, the bottom layer, because it's a is untrusted, and that has implications. So what I would say is I right now I'm confused. And I would move to talking about the reasons we are introducing data models and the other things that model and surgery been talking about. And then we talk about the policy enforcement issues again, however it's done with or without encryption. And then we come back and talk about this raw storage layer. That would be my mind proposal to resolve my objection.
Thank you. So just let me see if I can summarize.
In in current or his proposal, the policy enforcement policy definition so the authorization layer is somewhere around layer three. So what you're proposing is we we step away from talking about layers A and B, and touch on authorization and then come back is that what
Yeah, so having heard everything Adrian said, I don't know if this would address his concern, but i i don't think The intent was to say that layer a is untrusted as opposed to layer a could be untrusted that the design enables that layer to be untrusted. It's certainly the case that you could set the system up such that you trust layer in a in some way. But the design goal is supposed to be that you can have a lay that is not trusted.
Man was up next. And my question for Adrian is does that address your concern?
Yes, that's what I meant by opaque if layer eight is opaque through encryption the way Dave said it, I think is the same thing.
Okay, man. Right.
Right. No, that that's good, because I think that's that's the intent. Adrian. The other thing I wanted to point out is that it Nader had a very good question earlier in the call where he was like, Well, you know how to Do you get to the lower layers? Well, obviously you enter in at a higher layer and you go down. But then the question becomes what layer? Can you enter? Enter? Right? So, you know, do you enter at layer II and then go all the way down to layer a through all the layers? Is that how it works? Or can you enter in like layer C and then go down all the way to layer a? So I think that's an excellent question. Because in in this case, Adrian, I don't think there's an expectation that people can hit layer a directly it is opaque. And so the the highest level, you know, the a person using the system or another system using the system, it would only be able to enter at this authorization layer and then go down, right? You wouldn't have the ability potentially to enter at a lower layer than that without like being the software running on the actual computer. So I think it's it's also very, I think it'd be interesting for us to write down whether or not there's an entry point into that layer or who has the ability to, to enter into the layer and then go down the stack that hit layer a. That's it.
Thank you, surgeon Dave Longley. I can't quite tell whether you're on the queue again or from from last time.
Okay, Daniel Buckner, go ahead.
And in terms of entry points, I think it would make sense logical sense. If there were two essentially two entry points. And the demarcation for where the entry points occurred specifically would be if we kept the ones back and I believe that seems to be the resolution, and but split it into two parts where the layers were grouped into the underlying storage layer and the application coordination layers, right? The court I said coordination because more that goes into it. You just talk with API's, right? You could either enter in at that, that level, the lower one, the one that comprises the lower layers that has maybe authentication, or authorization. And then or enter through one of the API layers that's like built on top of it. It seems like those would be the two and that would be the demarcation is where you draw boxes around that. Thank you,
Jonathan. Go ahead.
Yeah, I see Adrian's point as far as like, where this authorization layer is, we're applying it or implicit and implicit into that layer, but really am going to what manhood mentioned is like, it depends on who has the keys. So who, who's encrypting it for whom. So it really is and if so, if you are the data provider actually like is a cloud provider. You can access it Storage, everything in your infrastructure. So I think it would be important to actually delineate who has access at different layers in and that I think will help out, at least cuz it really I see this may be really being a parallel or stack of the authentication authorization is being at all different layers. And in that it really is implemented into at layer a with the decryption keys. And so that, who you have and how you share the decryption keys do matters of actually how you could read those bytes. They're actually stored if the encryption happens at layer A. So but then, how you how you authorize and how you authenticate and then authorized at a higher layer happens to be an integration detail that traverses all different layers in a parallel stack.
Thank you, Jonathan. We have two minutes left Adrian, go ahead.
Oh, just, I put in the chat, the fact that this actually, we're using the term entry at these various layers or multiple layers. It's a perfectly understandable term. But if you look at it from my role, as you know, privacy, whatever, perspective, this actually goes back to the service endpoint issue, and the core spec, and I don't think we're going to resolve this now, but entry needs to be looked at. There's nothing wrong with entering at the different layers per se, but we have to reconcile this with the DI D core.
Thank you. That's a good point. Dave. Go ahead.
Right, yeah, whenever we're talking about entering, we're essentially referring to some kind of interaction. And we might be getting ahead of ourselves without defining that interaction. When we define an interaction. We'll interactions involve roles. And we'll be defining the roles and who's playing those roles. And we'll be able to talk about these things more cleanly if we do it that way. And every layer has some resources involved in that layer. And so there's always going to be some kind of authorization to get access to and use those resources, wherever there's anything tangible. And so when we talk about entering, we need to we need to talk about what are the interactions, you know, are we talking about someone who's implementing a storage provider to call get and set? Or are we talking about a person that's coming in trying to access their playlist is like totally different interactions, and they'll go through the scoping is totally different, the layering is different. And so this group is going to be defining I would expect, mostly a higher when we talk about authorization and trying to find a layer for that. We're talking about that in completely different sense from the fact that there will be different independent authorization layers and protocols within within each layer with regard to the resources in those layers. So if I don't think we'll be able to talk about this cleanly unless we, we define interactions and roles and go from there.
Thank you. So sadly, we are at the top of the hour, which means we have to take this to the streets. And by that I mean the issues. Or he brings up a really interesting point in chat that perhaps we need to reconsider our strategy and start not with the lowest layer, but with the D ID document. So let's, let's make proposals on issues and we'll add that to next calls agenda. Thank you, everyone.