Secure Data Storage - WG

7:58PM May 28, 2020

Speakers:

Balazs Nemethi

Manu Sporny

Orie Steele

Daniel Buchner

Kaliya Young

Dmitri Zagidulin

Adrian Gropper

Tobias Looker

Juan Caballero

Michael Boyd

Venu Reddy

Keywords:

issue

label

cases

replication

comment

link

encryption

layers

spec

layer

group

adrian

people

discussion

daniel

document

add

queue

chat

point

It's being recorded. Yes, good. Shawn belies the audio for this call is being recorded. And afterwards it's automatically transcribed. So we don't need to do transcription. scribing. Yay. We're going to do um, we're going to start doing introductions and reintroductions to support the community getting to know each other. And some of the chair folks introduce themselves last week we'd like to Daniel, can you introduce yourself? This week, please. Okay.

Yes, sir. You mean me, right.

I mean, you

have some people can I wouldn't Microsoft on DVD Work standards open source and this particular work sts or just in general, nobody really wanted to see happen for a long time. So I'm happy to know so many people working on.

That's fantastic and okay we are having Where are Manchu, and

Dimitri Ah, they're not here yet. And Tobias anyways, and we were gonna have manuals. Is there someone who is new on the call? Who would like to introduce themselves? Anybody because we haven't done this much yet.

Hi everyone. Just real quick for me. Yes. I am Michael Boyd from secret ID.

We are heavily involved in the in the hyper ledger Aries project and build a cloud service for individuals and organizations to use Aries and we would like to get more involved in the diff specifically around the secure storage.

Hey, thanks and where in the world are you located?

As of right now I am in Utah.

Excellent, great. Thanks, Michael.

Okay, I am the only chair here. Where are they? They must be stuck in zoom heaven like

trying to get in still pasted him the link. I'm not sure why the calendar invite link isn't working for him, but It's working for me.

Yay. Okay, Tobias, this guy here or he came, and then he went, Okay. So our and where's Dimitri? Some? Yeah,

sorry. We just we just realized we were having two separate meetings.

It appears about half the working group was on the old link.

Oh,

wow. But like, delete.

Delete, we use it. We just got

to zoom rooms. So

yeah, we run the Zoom Room.

How cuz I was wondering where everybody was.

So, can we hop over to that other Zoom Room, paste the link to this one and close another Zoom Room. Can someone do that? No.

Let's stay here because there's way more people on this call

somehow, someone go there and tell them to leave and come here.

What is this like the two Pope's problem?

Yes.

My bedroom

wondering how is it possible that like the Google Calendar update, isn't it update for everyone the zoom link?

No. I think people who are not actually like the Google Calendar link, because Google I think refuses to interoperate sending emails to anyone. If you don't go look at the actual calendar link, you're not going to click on you're dragged in ICS stuff.

And I was I clicked off of the Google Calendar link and it went to the different one. So did not update

the official diff calendar and then there's some other thing but we will figure it out. And now it seems like we're all here. So Okay, my goddess kicked off and we had Daniel Buckner introduce himself and I was waiting for me a man and Michael Boyd introduce himself and man who would you introduce yourself?

He Yeah, hi. My name is Mona Swanee. I do various spec editing things at WWDC in have done some stuff at IETF. Work at Digital bazaar. I'm excited to be editing spec stuff with this group that

I'm wearing the world are you located?

East Coast Virginia, small mountain town called Blacksburg, Virginia.

Excellent. Um,

one more thing um, we were advised by wise elders that we might turn our video on at least as we get going in this group to build rapport And connection and since it looks like we'll probably not be able to meet face to face maybe ever who knows when this is a good thing so if you're capable and willing, that would be a great support to helping us get started in jail is a community of human beings not just voices. Um, and today we're gonna label issues so I'm gonna turn it over to the meat Rita.

Did we did we give the IPR

warning? All

right, so welcome, everyone. here's the here's the link to the today's agenda. The quick IPR warning is this is working group of the central identity foundation joint item with the W three c community group. The meeting The calls are free to free to join and free to listen in. If you are to make any substantive contributions, you need to sign the IP restriction agreement, which can be found at the front front page of our working group. So I'll post that link is all right, so we went through our introductions. Did Daniel Wagner, did you have a chance to introduce? Yeah. Okay, great. So yes. So, first order of business we just saw. It is now time to start going through our issues. And one one way to ease into it is, let's go through the 26 existing issues and categorize them. And then we'll start on the layers and the use cases related issues and get into the actual details.

So hey, Dimitri. Keep Yes, sorry, I put my hand up. I don't know if it's showing. Yeah. I wanted to ask about the the meeting minutes. Just real quickly if we could cover that for three or four minutes as an addition to the agenda. Of course, yes.

So

the meeting minutes can be can be found off of the front page wiki link on the right, for each each day's minutes. For example,

last week's

if you click on last week's link in the right sidebar, there's the audio recording the AI transcript and the link to very similar hack MD document, which has the agenda and some chat highlights which I think is a pretty cool feature.

Any other questions, concerns?

Yeah, so it's more of a concern. So I remember talking about the way that we were going to keep minutes in, in audio recordings and everything, and I thought we had agreed that we were going to archive them someplace that we have control. So what I note is that all these links go out to third parties that may disappear. And that's a that's a problem. So, for example, let's just say otter AI, closes up shop and goes under three months from now, right? We would lose all of our meeting minutes unless they're backed up somewhere and same thing with the zoom recordings in to a certain degree the transcription so what so that's the first item it has about the concern is around archival, because we have to prove, you know, what discussions happened where and who said what over time, if there's Any kind of patent thing that that that comes up. The other issue is that I went to go and try to find the minutes because I missed last week's call in no amount of googling sent me to this page. So the so that's one item. And the other other concern I have is that because this is a joint group, I thought we were going to be cross posting the minutes to at least the CCG mailing list so that they could understand what's going on. So there are multiple concerns that I have with there are multiple concerns that I have with the way we are. We're dealing with the archival of this stuff, and it may sound esoteric to people. But if you've ever been on the receiving end of a potential patent infringement suit or just a lawyer calling you up asking you to get clarity around where the IP for a global standard came from. These things start to matter, like a lot. So I want to understand kind of what is what is our plan. We don't have to spend a lot of time talking about it. I do want to get to the issues, but I do want to understand whether people are thinking, Oh, everything's operating as planned or, oh, yeah, we need to do those things.

Okay, well, so first things first hosting of the audio recordings and the chat transcripts. Allows Would it be possible to copy those over to a different controlled server?

Yes, on the zoom that is already happening. I'm just not linking the downloads and counting the downloads on Altair, I'm working with otter to make that happen. And they are exported out automatically and then we have an instance yes So Monday, I'm working on it to make that and thanks for raising the the question on the archival and yes, we talked about it and it's not forgotten.

Yeah. Okay, great. Um, there was one one other item that I was concerned about, but it's completely escaped me now. I'll come back later. Yep, can't remember. Sorry.

Thank you, man. Oh.

All right. Unless there's any other pressing questions. Let's get to categorize

sorry. Yeah, I just remembered it. If you look at the Auto AI transcripts, it has person five, person six, person seven, person eight person nine. And that makes it impossible for us to say who contributed what. That's another thing that's that's an that's an issue because if if person nine contributed some fundamental IP lawyer is going to say who was person nine. And then we're going to have to figure out if we can do that. Find somehow who it was so that we can go and talk with them if there's any ever any ever concern around patent stuff it. So I don't know if there's a way for us to correct the auto transcripts after the fact. But having person 56789 is is we can't do that from a from an IPR perspective.

How does how does Bosch you may or may not know this, how does the author know that it is because some of the people are labeled. So how is that labeling happening? Why isn't it happening for everyone?

So, I've been doing a bunch of labeling in the background. Or Oh, motor is learning certain people so like, there are people on the call who would be recognized. Oh, but I also don't know everyone so like, I'm not always able to alone recognize everyone's voice. And so if if someone else would Join me for a session and find out names then I think pretty quickly we can we can clarify that and I'm happy to do so. Yes. So if someone is willing to find find an hour or two in the coming weeks we can I think, solve the person 897 issues going backwards easily.

Okay, I will raise my hand and say I'm okay don't necessarily know everybody but at least we can.

We can map it out from there. Yeah.

Really hard after the fact to remember who said what are you recording? All right, record video. So like

I said, video doesn't have names of the recordings. It doesn't always have this view.

Right. Got it. So, Steven, you're on?

Yeah, I just wondered if anyone tried

zoom because zoom

zooms transcription would obviously have that already. It would it would know

from all this

just wondered why otter was being used instead of zoom.

I think the answer is the enterprise has only the outer transcript at this stage for two

Amy in chat is pointing out something about AI surveillance. Amy we're just doing it to prevent you from having to scribe every other call for your own benefits. No, Amy's a fantastic scribe in other standard groups bodies renowned throughout the land.

Okay, so shall we

use quest like training otter to know our voices means what? And that's a question. probably can't answer, but I actually think it's worth actually asking the question.

That's a really good point, but not

going down the rabbit hole right now and we should shift over

to

issues. I think

that's a fantastic point.

Okay, so

everybody open, open up to the, our GitHub repository and issues. Who, yeah, Dan? I Agreed. Agreed. All right. We will come back to this. Possibly on

Hmm. All right.

Carsten just made an offer in chat. That if you're uncomfortable having your voice uploaded, indexed by the AI, you're welcome to type it in chat. And Carsten and others are happy to read it aloud for everybody. Oh,

Carson is one. Okay. All right.

Excellent. So issues

really pull up our, our repository and issues tab. And let's get to categorizing unless there are any other

blocking questions or concerns.

Okay, so first off, we're just gonna go through them in whatever order GitHub gives it to us, which I believe is just least recently opened. And we're going to add add labels, and we're going to create labels as we go. So so far we've got this issue is related to our Layer Architecture. We have a use case label and a this is discussed and ready for PR. So somebody please make a PR. Okay, so issue 55, two or three focal use cases.

Hey, Dmitry. Yeah. Could you share your screen? Sure. Yeah. All of us can kind of see in sync. Yeah. Happy to

Okay. All right, here we go. Let's see.

And if you want oldest to newest, you, you have to filter

out it. Okay. All right, one second. Then

second.

After you get it all working, maybe paste whatever you're using into chat so we can follow along.

Got it? Okay. So, hold on one second.

Now, I'm just gonna go with the default. Okay, so can everybody see my screen?

Yes. Okay, so first off we have and let's

First up, we have two or three focal use cases,

opened by Bumble fudge. So

is that person on the call?

I am the third.

All right. Excellent. So question.

Question to you. So one of the things that happened since

last week's call, for those of you who are not subscribed to notifications from the repository is we've moved our use case document from the Google Docs, where it was originally from during the working groups formation over to over to our repository, so the link for that second is

Anyways, while I pull up, put up the link, one, would you? Would you say that that issue is addressed by the use case document that was added or do you feel some more use cases are needed?

Oh, I would I agree with Ori that at least one more would be good. I'm not I just volunteering to edit and maintain it week to week to sort of add or modify or tweak things if if design decision. I don't know. inform people I need to add details. But yeah, I was just waiting for a little guidance on whether or not Adrian's Hopefully use case to go in, as is or if it had to be tucked down in any way. I didn't want to do it two or three times because I have the wrong initial vision of what to do with it.

Well, we like volunteers, thank you for volunteering to make the RS to the use cases, document, or you've got your hand up.

Yeah. So I mean, I think the thing that I would like to see happen with this particular issue is get a couple different focal use cases described and then see pull requests against the use cases that elaborate on those different focal points. I think one obvious one is the healthcare one that Adrian mentioned, that's linked. So I think we could see a pull request for that. I mentioned that maybe safe deposit box and banking would be another one, but I'm not a bank expert. And so I'm not really ideal to write that one. And if there's other use cases that working group members feel would be helpful, please comment on issue.

All right, excellent. So

particularly good would be like a link to a long a longer version of the use case somewhere else that could be boiled down or user story from out out in the world.

And so, is that as opposed to is that as opposed to the current use case document?

Oh, no, I meant I meant if someone has, if someone said instead of suggestion like, Hey, how about a bill of lading case, a link to a detailed for the bill of lading case that could be boiled down to you know, these terms.

I'm happy to

take take first stab at generating the root documents, but the more source material the better because I don't know that much about anything.

God, thank you.

So labeling wise, that one's super easy, because I'm gonna label it with use cases. Adrian, you're on the queue?

Just a quick comment, I guess this will be discussed as an issue. There's there's two kinds of use cases, those that look more like requirements, you know, like individual issues, and those that have business and legal references to the real world, like the one I submitted, that has a bunch of them, including the E FF comments as a real world thing. And at some point, I hope before one does too much work as the editor that we consider. Which comes first. The focal use case what we're calling the focal use cases, like the one I gave an example of, or the requirements like things are nice to haves like the way The D ID document is done where it puts those up front and I just want to make sure that that doesn't get lost prematurely. In other words, one should defend themselves so that this doesn't come up to to cause a refactoring of the document later.

Thank you. Bless you might make me co presenter so I can manage the queue. Thank you Adrian mana your next Yeah,

just to mention it I don't think we said this at the beginning of the call but the this exercise this this kind of issue, triage exercise is not the last time we're going to go through all this stuff. What we're trying to do is we're trying to do kind of a rough cut at the triage, and then later on, so later on, we will potentially hone the labels that we're putting on here. So like, like Adrian said, you know, their use cases in their requirements, we may find out that we instead of just having a Use Cases label we're going to have a use cases and requirements label that we can we can tag things with. So just saying that out loud in case folks are new to this process. Thank you.

Okay, so

it's 55 is labeled as use case. Moving on. Next up issue 52 replication layer is implicitly required. That is clearly layer related as as the next one. Does anybody have any comments or objections about those 252 and 51? Ori?

So this issue is assigned to Daniel Wagner, but I commented on it recently, and I think in order to address this issue, we need to look at what do we think the base layer storage interfaces, and so there's There is another issue that's related to authorization layers, which I think might also be helpful. But I think this is starts to get very technical and data model oriented. And so I would encourage people to sort of post versions of this that are like concrete to ask this question. Daniel, I don't know if you have any comments, or you've made any traction on this so far?

Um, yeah, I mean, I can certainly say from experience as we like, crawl through the guts of this issue and help stuff. You know, a, I will assert one thing that I do believe we should actually take a point of view on replication and sort of have a strategy, quote, unquote, that we offer as an optional may if you wanted to do replication, separately, the metadata you so kind of has to be baked, because if you don't, you just can't assemble state. So that's, that's my prep. I put it as a debate because I would love people to I don't know, I don't know if that's how we want to do this in this group. If this isn't maybe the greatest way then Let me know, I was kind of hoping we can hash it out or something. That makes sense.

Thank you, Daniel. And I want to put my hand up and get on the queue. But I don't think it actually lets presenters do that. So I agree with you that this is this is very much a key issue. And it's an excellent illustration of what we mentioned on the last call. certain core core decisions, certain core presets that are made toward towards the beginning of this group in this discussion now influence all of the other higher layers.

So given that one of the sort of core requirements is encryption, that has a very strong effect on what kind of replication and synchronization you can do, and it absolutely you're 100% right, Daniel, that Given encryption and synchronization, it has to be baked in at the very low, low level data model, otherwise it won't work. And as I kneel john asked, during the previous call, hey, there's a lot of existing standards for access control, authentication, replication and all that stuff, possibly less. So for replication, that's a slightly darker area. But why can't we use existing ones? And the answer is, because of encryption, because if you don't, because if you don't bake it in at the low data model layer,

then

it's very hard to retrofit encryption after the fact into existing standards. The thing that I want to mention about this issue is there's a slight difference between enabling reps application at the data model layer and replication itself, right? So, for example, a part of the group, I think is making an argument that we definitely want to add the fields that enable synchronization and replication. But have replication cells be at layer two? And then of course, there's arguments to be made that the two are the same thing. Is anyone in the queue? I can't see the hands. Nobody's on the queue that I can see. Go ahead, Daniel.

Yeah, so exactly that point. And I do I do want to create that distinction, right, the actual like business logic of replication, like all the code that would use those primitive values that are inside, the very lowest layers of the envelope stuff in the content, certainly is layers above. I completely agree with that. It's the primitive values like the vector clocks in the back pointing hashes and those things that if you don't have them embedded, and signed over and actually secured in the payload, it's essentially worthless because someone could just pop out, you know, they could change those values and then they could completely change how your stuffs thinks and history. And so they're very security related values, like pointing. So those values are the things that I'm specifically talking about, not necessarily the actual business logic invocation. You don't I mean,

yes, I understood in Preston makes a comment in the chat. And he and I'm not sure if you're saying it in the chat, because you're uncomfortable speaking or if you want to get on the queue. But the comment from me and his encryption does not need to be at the lowest level, which is a fairly controversial statement. So would you be comfortable explaining that? Yeah,

yeah, sure. So

I'm not sure what I'm allowed to say or what I'm not allowed to say in because it's not IPR protected. But if you look at ipfs, they're sort of lowest level data model is called IP LD. Basically, it's just content addressed and including links Merkle links between objects and not encrypted. That's all public. But it is possible and we've done it, you can layer encryption on top of that.

And that works perfectly well.

Thank you. I'm glad you bring that up. And you'll find that ipfs was specifically mentioned in the original encrypted data vault paper, which is one of the two input documents for this spec. We we are definitely aware that ipfs and other systems can do superficial encryption. However, we maintain the paper and I think that's the consensus of this group so far that unless it is baked in at the lowest level, it is extremely difficult to to unusable and then cut and that includes ipfs when the encryption is not encrypted synchronization is not part of the lowest level, it becomes extremely difficult to use, which incidentally, a lot of the threads On ipfs with regards to encryption, all follow the pattern of Yes, you can, you can do it sort of in the client. But nobody's actually or very few applications are actually doing it because it is supremely difficult without first hand. First Class support from the protocol.

Dimitri, there's so I've done exactly that.

Yes. And several, several others in the group. And they're writing the paper like, Jonathan hole. I guess. Yes.

The point I'm getting is if the lowest layer is content addressed, then you can do replication. That doesn't matter.

Right, and I think I think you'll find many people will disagree with that. We but we have a queue. Adrian, your next.

I'm just I think we're having a naming problem. And I don't want to argue the the point because this is a naming In tagging exercise today, but we were talking about layers, and now we're talking about replication and encryption. And it would be I have a very hard time, for instance, understanding Monica's point I know he's next on the queue as to why, you know, he feels that encryption is needs to be done in a particular way. So I assume there's a business reason there or legal reason there that I'm just not following. So I just wanted to call out the fact that our labeling exercise here, which right now we're on layers, has turned into her replication and encryption discussion, which maybe needs to be a different tag, because I'm lost.

Thank you. Thank you, Adrian. Man.

Yeah, without I think Adrian's right we should probably get back to issue triage saying, but this is a good discussion. So I think we've we've identified this as one of the elephants in the room in the group, we need to come to clarity on it. Not today, we need to go into triage issues. But I just wanted to point out that one, for those of you that may be new, the group, this absolutely is an elephant in the room. And there are people that feel very strongly about this on either side of of the discussion. One of the without going deeply into it, one of the strong drivers, I'm taking my editors hat and I'm putting on my digital bizarre hat. Right. So Adrian, the requirement isn't a business requirement. It's a technology requirement. It has to do with appropriate and proper layering of the ecosystem. There have been a number of things that have been said in chat that people should go in read. But fundamentally, there are solutions out there that exist today like ipfs, like Dropbox like Google Drive, that Don't do encryption at rest at the lowest level. And you can always build a solution on top of that, if that's what you want to do.

My

personal opinion is this work is not about those systems. This work is about something that is safe and secure from the ground up. There's encryption at the lowest layer. And that is how it's that's how we've, we've built things that a number of us have. We've we've built encryption systems on top of, you know, other network file systems and backing stores. The You know, there's no reason why you can't use encrypted data vaults with Dropbox or Amazon s3 or ipfs. But But, you know, people should be aware that the people that are implementing this, at least the encrypted data vault part of it, feel very strongly about this layering. So anyway, it's a debate for another day, I just want to make sure that the group's aware of that particular point of contention. That's it.

Thank you mono. I want to call out all these comments in the chat. A reminder to use the queued to keep your responses brief, and to bring the longer responses to the issues themselves

and use the raise hand function because it's cool.

Yes, we are using the raise hand function or if you absolutely lost key plus in the chat, or if you're calling in by phone and then say something out loud.

So

yes, let's move on to the next. next issue. This one being fairly clearly labeled.

Ah,

and I think you bring up a very good point. And as Dave Longley points out in the chat, it's not that We think that encryption should be at the lowest layer. Obviously, raw persistence of bytes is a lower layer than that. It's just that that layer is not in scope of this working group. We are assuming somewhere to store bytes like ipfs or s3. So that that bid is out of out of scope for the working group. Okay, so next up, we have

right issues 5152 labeled as layers.

We have

next up issue 50, which is moved deployments topologies to Section 1.2. Which is I believe the

section 1.2 is the introduction. Let's double check.

I think you skipped 51 venues common issue.

Yes. Sorry. I skipped it in the sense of it's already labeled with layers. But let's,

let's take a look at it in detail you right.

Then do you? Are you on the call? And do you have a comment on the issue?

I don't call.

I mean, I wrote a lot of stuff in the issue itself. Basically, I was trying to suggest a framework for design and deciding layer so that it can be easily

defended.

So I think I already has been commenting on it. And the last comment says something about I should look at something else. I'm going to look at it and comment on it again. At this point, I didn't I haven't looked at the

other comment.

Okay, if anybody has any questions, I can

I can answer but otherwise.

Thank you. Questions or comments on two venues on issue 51.

Exactly how issue review should feel?

Excellent. Okay. Issue 50. Here we go.

And let me pull up the spec to see what

section 1.2 is.

That was just kind of an editorial note that the apologies would make more sense in another place in the spec. I agreed with it, but I didn't see much discussion. So I didn't act on it when I edited these cases or

thoughts comments from the group on whether topologies belong not in the requirements but in the sorry, not in the architecture, but in you ecosystem overview.

The reasoning

for including them in the requirements is just pointing out that those most apologies are one of the requiring layers. Whatever document we end up coming out with whatever specification document needs to support those use cases, single device, cloud to device cloud to cloud and so on. Or,

this is Eric Waltons issue, so it's for him to move it forward. I've added the ready for PR label to it, if anyone feels like they could do the surgery that's described in the issue. That's what I would recommend the action for this be and I think we, unless Eric has any comments, we should, we should move on.

A song called

Alright, thank you. Any objections if I also add a layers label to this?

Go ahead. And let me think that makes sense.

I think Yeah, I don't think I'm gonna understand everything enough to, to take a stab at that PR until after the layers after labor.

Fair enough, fair enough. Okay, next up, we have another issue by Eric.

about sharing. So let's take a look. Let's issue 49.

I'm gonna turn off my camera. So,

right. Secure Data Storage sharing, is that only is that read only or read or write? So what label do we want?

Who could have an authorization label?

ask for permission. From the people who have commented on the issue.

Okay, they've long Li Adrian.

And Eric was not here. Thoughts comments.

Adrian, good. So I don't know whether it's in this thread or another one, but I've introduced a couple of terms. One of them is the requesting party. In other words, sharing implies that there is a requesting party and there's many options for who the requesting party might be. And I've also introduced the idea of access control. So in other words, I suggest if I forget the details of my comment here, that sharing is a is not A useful label that it would be better to be clear about either access control or if we don't like access control, we should discuss what other term relative to requesting parties and their clients we prefer.

Thank you. And terminology is really important and and difficult. So, agent, would you would you be comfortable making a PR to the terminology section of the spec and adding requesting party and then separate br adding either access control or authorization, and we can argue about it in the BR

and I agree with you by the way that sharing by itself is too ambiguous.

Although it is from what I understand being used, sharing the protocol is being done initiated from authorization, lower layer data model. So sharing is if our sharing is more like when you use in Google Docs, and I pull up the UI and share something with you, and that generates a notification. Whereas the authorization, access control is the entry in the database that Google has for which users are allowed to read and which uses to write. So those are two separate layers, and we need good names for both of them.

Well, I do use the policy enforcement point, and the policy, decision point terminology, which I think is very clear and predates all of this stuff that we're doing for the last 10 years. So again, if we want to not invent unnecessary terminology, then I would add A PDP to our vocabulary, because they're perfectly clear in my opinion.

Excellent. Thank you. So please, please limit comments to this issue or open a separate one about adding those, that terminology. Okay.

So it sounds like we're labeling this one.

We're labeling this one as discussion.

And let's move on to the next issue.

All right, this one's for Eric as well. This is clarifying relation of storage to agent and wallet. Does anybody want to comment on this? Let's see. Dave Longley, Adrian

This this already has a ready for PR label. I don't know.

labeled it there.

Ori or any any other comments or shall we move on?

I did. I think this is a request for better diagrams and that's why I labeled it as ready for PR. Got it.

All right, thank you.

Okay, so next up update to the ecosystem diagram. That one seems fairly self explanatory already labeled. Does anybody want to comment on that before we move on? Okay.

Go ahead. I would just say that this is Yeah, perfectly labeled already, because I will. I would love to come back to that one when I know more. like five weeks from now, and I finally get all this stuff.

Sounds good, thank you.

Okay deduplication of Section 1.3 in their use case document. Eric points out that we have a use case document now, since since the last call, and we have a use cases section in the spec and maybe those two should be combined or linked.

thoughts.

thoughts or comments on that?

was one. use cases were never intended to stay in the core document. Add a comment to that effect in the issue.

Thank you so much.

Ah, already do you want to also mark that one as ready for PR?

Yep, I just did. Perfect. Thank you.

Okay, next up issue 45

by Kyle, how does compression interact with the chunking of files?

And I believe that's a fairly straightforward technical. technical question. I'm not sure what sort of label we would want to add to it. Kyle, are you on the call?

Or you go ahead.

So I tried to think what what what is the actionable from this conversation? I think the thing that's actionable is describing the relationship between compression and encryption somewhere in the specification. And I also sort of think that one thing that would be helpful for the group is maybe walking through the worst case scenario for encrypting like a really large object where you would want to Get a lot of compression benefit before you would store it. So I will restate that on the issue. And if that sounds like the kind of thing that you think you could do, I think this is basically ready for a PR.

audit. Okay, thanks. So go ahead and leave a leave a comment and label it.

Here we go. How should the architecture layers be named? So so far, we have three layers, arbitrarily numbered, and pending discussions through the issues on what goes into which layer and are three enough and Kyle was asking, Hey, should we probably give them human understandable variable names? Which is a great question. We're, obviously this is a layers.

Label.

Anybody have any quick thoughts or comments?

Okay, so that one's fairly clearly labeled on.

Ah, this looks like a procedural

issue from Manu about posting the minutes meetings on the CCG mailing list.

So I don't know if we have a procedural label,

but we should do.

I will create one in mark that

is

excellent. Also procedural issue is the next one mono repo for whether for the spec, the test suite and an implementation.

So already, go ahead.

Yep. So I think this is my issue. There's been some discussion on it. My recommendation to the working group is to not split things up until we know Know how to split them up and to put everything in this repo until we feel like it's a good idea to start to move things around. And if there is consensus that we can take that step forward and do that, and then split things up later as the working group desires, I'd love to start to set up that structure so that the people who want to contribute code and don't want to have discussion about spec can start to do that. I will say that on the issue.

So I would like to be added to the queue to ask or to provide a counterpoint.

I understand that we need to have a lot more discussions in order to separate the layers to possibly separate this into two different specs. But as far as something basic as this is packaged as a test suite, and they traditionally live on different in different repos. That seems less ambiguous. Can you speak to maybe on the issue too, I don't want to dive too much into it. What's the benefit of having colons back in the same issue?

So please, please, please read the comments on the issue. Okay, and don't spend any more time discussing it. Got it.

Okay. Clear.

Ah, okay. Next up is issue but I opened, clearly labeled, clearly needing layers label. Which layer does enforce authorization belong in. And that just refers to the fact that in the current layer section, we have two different items. One says enforce authorization and the other one says authorization, and they're in two different layers, which is confusing to people as we brought up

in the last in the last call, so

please comment if you have strong opinions on it. Let's leave that as layer and move on. Okay, here we go. Next up well known new arise and configuration advertisement.

Great question by already.

Already thoughts on label? Uh,

yeah, this is this is one of those technical implementation things. I don't know that it's not it's not a layer. It's not a use case it's technical. high level summary of the ticket is I've used well known your eyes to make encrypted data bolts discoverable from a domain. I'm not sure if that's a thing that we want to consider in the working group. But if that's the thing that you're passionate about, please comment on that issue.

Label implementation.

Yeah, it's, it's potentially Well, it could it could be a spec recommendation because well known your eyes need to be registered. It could be an implementation specific thing, in which case, I would argue it maybe doesn't even belong here. It's just like transmute decides to use Walmart in your eyes for their DVDs.

So I think I think several people have the use case that the config needs to be discoverable. So I think I think it'll definitely be a spec issue. Okay.

But I don't know what label that is.

I don't think it needs a label. And I don't think it's a priority right now. So right. Okay.

Maybe we have a low priority label. Okay.

Interesting enough. The next one is also related to the global configuration. And that is an issue by Dave Longley, saying, the current spec, and Auris issue number 40. mentions server configuration, and they've put in a reminder that we should also talk about discovering and negotiating the client configuration.

What about a configuration label for both of those ones?

Sure.

It seems very specific, but we can always refactor the labels okay. Next up by Johnny crunch, paradigm shift and the age old discussion on whether to use terminology such as server and client. That seems like it definitely needs a discussion label but Johnny crunch Do you have a comment on this?

I know I supposed to do a PR and I haven't I apologize. I will okay with it and I'll get back to my to do list. Great. Okay, so that sounds like it also needs already for PR label.

Ah, okay. Next up, articulate layer zero goals from identity hubs by Daniel. So that seems clearly layers. A Do you have any comment? on it Daniel.

Alright guys,

Not to beat up on Daniel. But the description of generate a PR for this is very hard for anyone else to take a stab at this. So when you open issues, try and make your issue description. Something that you can get feedback and collaboration on because I don't even know what to do with this. Like I can't contribute to this issue. I don't know how I would.

Thank you very.

So

yes, let's put a discussions label on it and ask Daniel to clarify. Next up issue by Adrian, how does one request access?

That's clearly a discussion label in my opinion.

Great. It does seem like a discussion and or a protocol or an API label. If we have one of those

I will add a pro to call label all add boats.

Great.

Yeah, I think we may have lost Daniel, he may have fallen off the call.

Oh, here's everybody's favorite issue, the naming of the speck and software. As a reminder to everybody, we still have the ticking clock of the longer we go without changing the name of the speck in the group, the harder branding and SEO is already

so I think I opened this but I signed manner to it. So I'm sorry. Sorry, man. No. That's why I'm raising my hand to address it. I would really love if we could get more comments on this issue. I'm currently my personal perspective since I opened the issue and get get to share my personal perspective on it. I'd love to see the working group be the secure data storage working group, the specification be the secure data store specification and the implementations being encrypted data bolts. That's my that's my schpeel. Add your comments to the issue. Try and bike shed on GitHub more than in meetings.

Okay, and we are past the top of the hour. Thank you everyone. Please proceed in an orderly line to the issues and argue in there. And we will resume labeling and then going through the actual issues on the next call. Thanks, everyone. Thanks.

It work everyone.

Good work.