Secure Data Storage - WG
8:07PM May 7, 2020
Everyone this meeting is being recorded How do people feel about using automatic scribing?
Like how have you found the quality been so far of
service pretty good sometimes names are get matched up or like company names or project names gets messed up, but it can be edited afterwards and I'm happy to do I will post Just give me a second one from the last call I will post the link how it looks. Got it.
Shall we have a backup elected a backup scribe for today just well we review the quality given as Amy points out the use of jargon and whatnot may make the notes
Yeah, yeah, my no one already said it's good. So we haven't been using it since the second call. And
but all those calls also had notes. Like I think there's a role for
I don't know. I mean,
we didn't stop taking notes because we na I listening, right?
So we are taking notes because might not everyone have the ability to hear what we are seeking. So it can be read and we can capture everything, but the capturing is for the recording. So it's more for people who might have some problems. Primarily, it's what I read on the CCG. Right, yeah.
We can because scribing I mean, this decision can be made later. I think we should then
Yeah, yep. Sounds good. So any, any scribe volunteers? Amy's volunteering, Amy, thank you. You're a saint. As always. Please go ahead and scribe and reminder, we're going to try and Use the zoom raise hand mechanic for keeping track of queue. Those of you who have been at ITW last week should be old hands on this by now. For those who are unfamiliar with how to raise the hand, you want to open the participants pane. And if you don't see the raise hand button, click participants again. You should see chat above it the list of participants and sort of on the center right, raise hand button.
If all else fails, if you can't figure out the raised button, you can type q plus in in the chat of the zoom and we'll sort it out.
so next up we want to talk about Briefly, we've already sort of mentioned it but we want to reiterate the tools we'll be using this working group Buckley D or Tobias doing Take this.
Yeah, so so we've elected as I'm interested, we've elected to, to use for our notes rolling hecking day and zoom in. To reduce the queue management, we're going to use this zoom raise hand feature within the working group. I mean, we'll have the notes reflected on the wiki. One of the one of the outstanding questions we had for the group today as obviously around meeting time. So we'd like to get some feedback from the working group, about other working groups elite to have multi timezone rotating timezone meetings. And obviously, we have this meeting time now and it conflicts with dead resolution. And so we would Like to get some feedback from everyone whether they would like to see a multi timezone meeting going forward or whether or not we should be going for a fixed time zone and if so, are there any objections to the current time other than the conflict that we're reviewing with the resolution?
Yeah, just I just one preference, right. So I'd like it if we would keep these friendly for New Zealand, New Zealand, Australia time because we've had a number of people state that they would like to attend. Not just from New Zealand, of course, but Australia as well. So that's the first request and then second one is ideally let's not rotate the the times. I prefer us not do that, because it tends to potentially it just confuses people right there there is is usually no good way to do it. But what I what I would suggest in in place of that is that any special polls that we have we have it in at the times that you know other people would like it that like it to happen like for example, you know something that's friendlier for European time zones. And then maybe it's you know, very late at night for But anyway, so So, I'd like us to keep the calls on a fairly regular basis. Prefer Australia New Zealand time because that seems to work for just about everyone except for the Europeans unfortunately. And then special topic calls. Put them on on in on time center, better for folks in Europe. That's it.
Thank you mono. Are there any strong objections to having a fixed meeting time rather than a rotating one like the did working group does
prior to viewed as mentioning that rotating does make it more fair. And
this time isn't exactly friendly for Australia. It's really, really early there. It is friendly for New Zealand.
Right. So we kind of figured we will have dissenting opinions. dissenting opinions on whether or not to have fixed time or rotating.
see, it's workable for the EU and New Zealand can make it so I, um I mean, if I was meeting the room, I'd say we stick with this with the caveat that we would like to deconflict with did resolution so was part of our thinking. So how how many? Well, it's hard because if the meeting conflicts all the people who would be here are over at that meeting, right.
Right. And the did resolution group is also in the process of sending out doodle polls and picking a new time to deconflict. So we'll, we'll both be sort of picking at the same time, unfortunately, but that's fine. Alright, so we can either call it based on the feedback in chat, or we can put it to a, we can put it to a vote on fixed versus rotating. And in either case, we'll be sending out doodle polls for what time?
You Yeah. So I think I think the
I think the proposal we should put on now is are there any strong objections to changing the time we currently have given that we are in the process of deconstructing with the resolution?
Or he makes a funny but kind of true point that larger ships get right away. We do. We both very much want the people in the did resolution group participating, we are a larger group tend to be
So do we want to wants to make a proposal. Keep this current time until the doodle poll for new time resolves, stick to fixed.
Okay, it sounds the results are still rolling in, but it sounds like the eyes habit and we're going to keep this time until we pick a new fixed time with you topologies to basically everybody from every time zone.
Alright, so that's resolved.
Next actually seeing any minus ones, so resolved Okay, so next up, do we want to give him the floor? Tell us a little bit about the my data operator group.
Yeah, sure. Hi, folks. The Yeah, I'm gonna post some slides that I ran a session that I ate up last week on my data operators, so I'll include the slides that I used for that one, there's a lot of them. And I'll send a link to the white paper. But the short story is, I don't know. I will assume that not everyone knows about my data organization. But essentially, it's an organization it's been around for about five years or so. originated in Canada, Finland, Helsinki, mainly kind of conference based.
I think a lot of people on certainly on
a good offer. lot with ay ay ay ay who Kalia? Hasn't you've spoken at that conference before? Yeah. Yeah.
So there's about 1000 people, 1000 members in my organization, those hubs in about 25 to six different countries. Mm hmm. And about 200 organizational members. And I tend to I tend to think of the organization as it's not quite the identity community. There's some overlap, but it tends to be more kind of societal about a legal of economic under sprinkling of technical submit on underway, Adrian, I think you're on Nikolay dunia. Adrian's an active participant and my data. So my dahveed was one of my colleagues. He's based in London. So there's a fairly hardcore of technical people. But I think we're all pushing in roughly the same direction and certainly from my perspective, long term participant in Project VRM, II W, all of that kind of stuff. So, personal data services has been part of my story for probably almost 20 years. So what I was speaking about last Wednesday, and the links Oettinger, for the past seven or eight months, the organization, my data organization has been working towards this white paper about what it called my data operators. So mainly to operate it as essentially an organization. Although it doesn't have to be an organization, it could be a piece of hardware, for example, that acts as a fiduciary duty to an individual to help them manage their data. The there are certain contexts where the operator can be neutral, so it doesn't have to be fiduciary to the individual.
but it can't be for the organization. So the white paper essentially sums up where we've been Got two things at 1414 organizations have said, Yes, we want to be one of these operators. And what that means is is essentially a path to interoperability. Because basically across the 14 operators at the moment, you've got 14 different ways of doing data services. As you can imagine,
positive a lot of positive things, but I think the one that reassured Kalia was that that group does not intend to develop any standards. Unless it happens to find it. There are no standards for the kind of things so very much wants to point out to this group and other similar groups for standards development, so that's that's the kind of high level overview does that make any sense or any major revisions?
Very much makes sense. And then I think a lot of us are definitely aware of the my data community and would really like those of you that are interested to join this conversation. Yeah, it's it's refreshing to see See that? The group is focusing not specifically on technical standards, but all on all the other necessary stuff around that. And we definitely hope our two groups can be complimentary.
Yeah, I think the I think it was both ways when obviously anyone in this group is more than welcome over my data. And I've certainly noticed recently through the COVID-19 side of things, there's a lot cross fertilization between other folk working on digital verify claims, typically. So there's a good degree of cross fertilization happening already.
Fantastic. So would, would you and then the other ones from that community, help us
send an invitation to everybody. And
I'll just report back to the to the whole slack thing tomorrow and just say we've had this conversation. Here's this new group, very relevant. I've already told the there's already a group as Kelly mentioned, working on what we call common endpoints which essentially As I can a personal data service API's, and I've said to them a few weeks back, you probably want to join this group and therefore become more than just the four geysers and the Indians. Yeah. Oh, right. Well, so I will feed back. So you may well see quite a lot of folks getting your way.
That sounds great. Yeah.
Thank you. Cool.
Yeah. What's next?
Alright, so next up.
The last thing that we were discussing before the official formation of the group and the election of the chairs was our use cases document. So we'd like to go over it again to one refresh everybody's memory and to see if there remain controversial items so that we can feel Without so that he can guide us in further issue reviews. So the link to the use cases document is whoops, sent up to the wrong person. link is right here in the chat as well as at the top of or rather linked from, from our notes document.
So everybody, please take take a look.
Alright, so how do we want to do this? I don't think we have any clearly marked
points of conflict or controversy.
So we have a cue my call and then we're
Just a quick question and it's just that the this the the constraint or one of the the state this is purely around individual or personal information. It's not covering organizations or things. Is that a true statement?
Mind if I, if I handle that? So, no. The goal here is secure storage of data with an emphasis on client side encryption, and it definitely
covers organizations. Yes. Okay. So not necessarily thing so
good IoT or anything of that sort of Oh,
okay. So I do think a lot of the members of the groups are interested in IoT use cases. I think we'll we'll be having a lot of discussions about the definitions of actors and agents and things like that. But I think everybody would agree that IoT does fall into the problem. Okay. All right. Just wanted to ask the question, just make sure you're interested. Thank you. Well, yeah.
Are you still muted if you're talking? Sorry,
was I called? Oh, yeah. You had your hand raised?
Yeah. So I think I was initially assigned to this and then volunteering to be on assigned from it. It's a Google Doc. There are some comments in here. I think. There's a number of the comments are open ended. And so I invite members of the community to respond to any open ended questions. But I don't see a lot more to do in the document personally, so if someone else could take over, that'd be awesome.
Fantastic, and thank you. Thank you all you did a really great job. With this document so far.
Hi there. Yeah, I've, uh, I've had a little itch, bothering me about SDS and biometrics for a little while. So I wanted to bring that up. When you look at sections 2.5 and 2.7 in here, so, or 2.5 and 2.2 point six. I raised this, there's this kind of concept of device free or is it possible to have an ATV or secure data store that doesn't require the person to carry around a physical device that they garden or the custodian of or that may cost six to nine months worth of wages. And one possibility for that is to have cloud based systems that you can access using shared resource like you go to a hospital and That hospital has a computer. And that computer has network access, but it's a shared resource. So that's how you could get to your your cloud wallet. And in those cases, you would want to protect your keys, your private key material, you'd want to get it from the cloud into the browser to run as the browser would serve as an ad hoc device, you know, kind of on demand device, but you'd have to use biometrics to unlock that data. So this this means that biometrics play a slightly different role relative to EBS and secure data stores. Then, they do with the standard issuer holder and verifier biometric dance where you know, you're doing an authorization of a purchase or something like that using your fingerprint. This is actually for unlocking and getting access to that in lieu of maintaining and carrying around some kind of private key store. So this, I'd love to know how that kind of what the group's feelings are on this and how this fits in relates to 2.5 and 2.7 in there.
Okay, thank you so much, Eric. Before inviting guru commentary, I just want to say so 2.5 is referring to
use case documents section 2.5 is cloud only?
So I think that that's exactly a cloud only is referring exactly to the use case that to the usage scenario that you have described. Right.
Yeah. And there were some comments around 2.7 right after that as well. On in the comment stream, kind of low power, or no device access and those are kind of connected. So
yeah, unless as jack
I second Eric's
questions here at the key fob. The session that I had that Kiva had, I don't know if cam is on this group, but the the EBD edtv, SDS word came up. And in that context
I think we have mana next on the queue.
I think you're muted if you're speaking.
Oh, thank you. I was, um, so the encrypted data vault spec specifically, is agnostic to those questions. So you can deploy an EDP on a personal device that you carry around with you. You can deploy it in the cloud, you can deploy a hybrid, you can use biometrics, authenticate with it, all of these things are possible. So I want to make sure that you know, I think I understand which use cases you're talking about Eric, and those are very much scope. So so I don't want anyone to feel like, Oh, it's cloud only. And it's going to cost you know, $1,000 you know, for the thing and there's no shared, you know, infrastructure or anything like that. The specification, at least the ETV specification is at a much lower level. And we take all this use cases into account. It's like, think about it, like, you know, storing some storing a picture file. The picture file formats don't really care all that much if it's stored on a floppy disk or a hard drive or an SSD or you know, some other in a cache on a router, you know, on the web. All of those things are possible. So, just as all those things are possible, you know, using biometrics to authenticate with an EDP is possible. It's not in the core spec. It's at a way higher layer. You know, running an ATV off of a mobile phone that you're carrying around or running and running an ATV off of a modified USB stick that you carry around. These are all things that are possible. But our higher level protocols, I don't know if that answered your question.
That was always my impression manner. Thank you for confirming that.
Excellent. Do you have another question?
I wanted to just follow up on that just to clarify, because I think the the sense that I had with the EDP or the SDS back is is that Yeah, you've got to somehow get that key material to to to open or unlock to engage in it. So So I guess what, what I would just what I'd be interested in seeing made clear in that is, is just exactly that, that that magic. Where that magic bubble goes where where the keys come out of this and go into here? So I mean, it's Yeah, I think you're right about it's not it shouldn't be directly in the spec. But the the the other thought that we have when we talk about using when I'm sorting through other documentation, like in areas and places like that, that are talking about biometrics, it's in the context of having access to a secure data store already. So this is what I'm trying to make sure is that I don't I can talk clearly to those cases, and talk about ways to access a secure data store. Using biometrics versus having access to a secure data store, within which I have biometric data. I don't know if that makes
it makes sense. I think another way of putting that is everyone's favorite topic, key management. And I think we're gonna bumping up against key management a lot in this group has as Manu and Dave and chat are pointing out that is a very important to us, but slightly outside of the scope of the group. We are assuming working key management infrastructure, which may include biometrics, which may include wallets, either mobile browser or physically printed out, etc. So, we will always be talking about key management, but I just want to set expectations for everybody that specifically, key management and authorizations backs are intended to be compatible and pluggable with secure data storage, but are are outside the purview of the group. Does anybody before we go to the queue? Adrian's on the queue? Does anybody have questions about that?
Go ahead, Adrian.
So I think it's important to keep in mind That the keys don't necessarily be belong to the subject. That is that relates to the storage, what's being stored in the storage. So what is in scope for the group is that the keys for access could belong to a service provider, for example, that is providing services to the subject.
Thank you, Adrian, that that's a very good point.
And this this discussion brings up a future topic that we may be able to get to either in the next call or after we transition to discussing issues, which is our base documents, our initial source documents, which were some concatenating, or otherwise merging into a single spec and then starting work. On that spec, which are the encrypted data vault PE, paper and spec, and the Microsoft slash diff, identity hub,
explainers and specifications
Alright, so let's
let's go on to our next topic which is issue review. To summarize we have this
we have the starting use case document, which hopefully will help focus and organize our issue discussion or spec writing. already did a fantastic job with this iteration of it. We're going to keep it open for suggestions and comments. And probably sometime around next call, we can transition it into markdown and into into our repos. The other thing that I would like to propose for for next calls and us starting to work on is of course, terminology or glossary document, which on the one hand slightly overlaps with the glossary initiative over in the credentials community group and then did Working Group. I know Drummond's and a lot of that community are are working on an excellent glossary document. We do, I think wants to, while referring to that have have our own secure data storage specific glossary document just so that we can help clarify arguments about definitions. Okay, so let's let's take a look at the existing issues in the scale of secure data storage repo under diff. Please keep in mind that this is in a sort of raw and unorganized state right now.
And demand summit. I just want to jump in and Amy's just asked for a reminder, I've just dropped the link and again, can we please have people who have not already done so add themselves to the present list? Thank you. And also, should I share my screens? So we can interactively go through these? Yeah,
yeah, that sounds great. Please do.
Can everyone see my screen? Yes.
Okay, great. So, thanks to Ori for going through and labeling some of these issues with pending close. We thought we should just go through these that have this these labels first and see if not, we can get some resolution on these outstanding issues or progress them
Okay, so this was opened by Daniel. Are you Is there any additional commentary to this? Daniel, it sounds like there was kind of a resolution proposed on this issue last year.
mean, I think that, you know, the synchronization piece was explored, and we have documents that are the output of that. And this is something that should be obviously taken into account in this new body of work. Potentially output resources.
Okay, so as your Proposed resolution that we closed us at the stage, or would you like to,
would you like to,
I mean, I don't know, I guess I would suppose that there should be some sort of, there should be some sort of issue that's created for this new thing that says like sinking of all You know, relevant data, both configuration and actual data and otherwise, the new thing, right, so we do that task. But yeah, this specific bug, I don't I don't care what happens to it as long as we do the work on the newest stuff.
Okay, are you are you happy to maybe take take an action item to create another issue that updates exactly what you would like? No, this, what the implications are. Okay.
Let me jump in for a second. And thank you, Daniel. I think
everybody agrees that synchronization is a really important use case. It's mentioned in our use case and requirements document. Specifically, the both in the first section and in the deployment topologies the the needs to sing Connect between multiple devices is mentioned several times. So
I think that's definitely part of the working group. And
go ahead and open a tracking issue for that. And let's add if it's not there already a initial blank section for synchronization to the jar and progress back in this recall.
Okay, great. That sounds like a resolution to add just general language and stubbed out a section for synchronization in general. So if you could perhaps update their Daniel
in clauses issue that would be great
or maximum section
So, where to store references and source files? This is also opened by you, Daniel, I think Adam might be some.
Yeah, this is totally related to this is totally related to the old implementation stuff. So
yeah, given given the current API, I guess
sort of lis discriminates against that kind of esbit. As the reflect the recommendation is closing I'm saying in the chair, so we happy to close this session. Yeah.
And it's or points out, let's make sure to put in a note, I am at 21 that we're assigning it to Daniel.
Yeah, I have assigned 21 to Daniel
So this was round. How would you connect? If you use the data store to represent an app? Because we're saying that this could be any entity, you know, could be a person, it could be whatever, right? How would you connect the app to its instance ID, and this is mostly how app platforms work. So I don't think that this, this may come up in utilizations of sts stuff far down the road, but it probably not applicable right now.
Okay, so the
the resolution here is to close this one as well.
I have a feeling that this topic will come up down the road in this group. And in fact, app identification is something that for example, the solid community is wrestling with right now. So, very rich topic. But yeah, let's close it for the moment.
So issue 18.
And this was about what API's you know, would be used to talk from, you know, hub hub to nap, like, basically creating API's that make it easy for applications to connect to hubs, I believe. I don't think this is relevant right now. For future.
Okay, so recommendation is to resolve this one for now as well. Yeah.
count for messages.
Zero, is there any more detail you'd like to add to this one? And Daniel
now? I think we should just close it out. I think obviously permissions need to, you know, cover all areas. So okay
underway for hubs to Communications at payment for service provision.
I think this is probably I don't know for encounter this or if this is something that people care about, but it seems like it'd be a little farther out. Okay.
So I think this, this issue might raise some interesting questions and to sit down with some of the language we have in the current input spec around authorization. This is about mixing is this simply the high level of this issues to discuss the kind of management of access into an encrypted data vault?
Yeah, basically like assessing. This is just a request and removal permission specifically. So how you would say, I'm authorizing you know, x di D to do something. It's good background, but I don't think it needs to carry on. That's an issue that's
Is there any commentary anyone?
Adrian, so I,
I mentioned this in in another thread. I'm kind of interested in having a name for this. triplet that has to do with the credentials of the person who's asking what the scope of data or what the data is they're asking for, and what they intend to do with it. When they come to the data vault, if that is a reasonable thing to name, tell me and I will either raise it as an issue or make it a comment to this issue, or I will do the right thing. If it's not, then we should sort of discuss it at an appropriate time.
So this triplets giving this triplet a name.
I think that would definitely be a different different issue. This one's very, very high level. I think that's what you mentioned might be a detail within something that we build into permissioning and then you think I just feel like this this particular issues, probably Not actionable for.
Okay, so as the as the I don't know, you would like to propose closing it. And is there any subsequent issue you'd like to open around this or not at this stage?
You know, because, you know, there's also a dizzy k, z cap stuff in gdb. I would assume that we probably should have an issue that talks about, you know, doling out permissions or specifying encrypted states of data for whitelist people, but I don't know exactly. You know, what, what does many other people have thoughts maybe
I'd like to jump in and add. So
we've mentioned in the back end, in our use cases that we do expect authorization systems and access control systems to be relevant to this discussion. They are meant to be pluggable and out of scope. This is A related topic, actually, regardless of the access control system used, how do you request access? Well, should you be able to? And then is there a specific standard API to do it do the equivalent of in Google Docs, hit request access button?
it's, I think, as I've been mentioned, it's out of scope for the moment. I'm feeling it will come up again.
Yeah, so here's the overarching question like this will absolutely exist in the SDS spec, like something that says, here's what you craft to, like, send a message request or something. I'm just curious when we encounter something we know will exist. Should we just keep this issue even though it has all this gunk from like old stuff, or should we just close all the ones in the fresh ones that might help us go through this quicker, I guess I'm trying to say.
So you would like to suggest the issues that you've closed, we can go through and mark them all for closing, the ones that have been labeled. So we'll we'll close this one reflective if we don't have a
any additional commentary?
Yeah, I think by default, I would almost tend towards closing most of them because it seems like they're loaded up with stuff that could confuse the current.
So obviously as the author so specify, actually phase one of the mini supportive hub face interpose protocol, but we just close it. Yeah. Because
why don't we just go down this list and I can just probably eyeball it and be like, Okay, this is just not gonna.
Okay, but we'll use it. So consider moving destroying from rest your path requested.
Yeah, that's way too specific. I think for where we're at now.
This is our signature hash requirements object rappers.
That's probably too specific at this point. Okay, but you might want to look into it. It's very lightly traffic, I would just get rid of it. Yeah.
And that for sure.
definitely get rid of that.
And I get jobs that's Yeah, it's too specific. Anything that's, that's that specific.
Go. So number, right.
request object. That's
Yeah. The gods. Yeah, get rid of that. Get rid of that to anything that's like talking about the particular implementation of the past things just an input I would just get rid of.
Right fine. Jason O'Day. With how permissions is confusing. Specify, use an Asian face to signal the admin data.
Yeah, it's probably Yeah, I'll close it. I closed the next one too. I would. Yeah, get rid of that. Get rid of the next one after that. Get rid of I don't. Yeah, the last one I don't know about. I mean, we kind of talked about these things in the call. That's my data. We just
this one Adrian was opened by you.
Do you have any further conversation on this or action associated to this issue?
No, we can close it and I don't think anybody I forgot it was there and it's okay to close it. It'll, it's fine. I do have one comment though. Closing the issue that was opened by Josh Mendell without talking to him, I think that that's
for session number six.
Yeah, I Josh Ray. Yeah, I wouldn't do that without talking.
Hey, come and talk to him. I mean, Josh is a Microsoft employee. But yeah, sure.
No, I'm just, I'm just wearing as well as I'm not familiar with this handle executives that are they on the call?
I probably just warn don't close anything. If you if you don't get a confirmation from them on the call, we can just say, Hey, we're going to close in seven days if there are no objections.
That sounds good. Issue number three there brings up an interesting
the initial use question
brings up the question of implementations just want to To put the question out to the group here, of I think everybody agrees with, it was mentioned on earlier calls that we want a list of implementations. We do not want to term it in terms of reference implementations. But we do want people interested in this to be able to look at libraries. So my question is specifically, where do we put that list of implementations in the readme in the spec itself in a separate document? What do people think?
Or is on the queue?
So I'm one of those people that plans to help with an implementation. I think it for where we are today with the spec. And with kind of the ecosystem, we're actually are pretty close to wanting to start having some implementation some tasks Some alignment between spec and implementation. And so I'm eager to start that work as soon as possible. I think the implementation for now belongs next to the spec in this repo. I think the tests belong next to the implementation. And I guess, you know, there's been some objection to the term reference implementation, which I just, it kind of irks me, a reference implementation is not an implementation that you should go to production with almost ever, it's usually meant to encourage other implementations that will have enhanced performance or other kinds of vendor integrations that might be valuable, or that might be proprietary. And the reference implementations job is to encourage other independent implementations and not to be the production implementation. So it's meant to just to encourage diversity. And it's not meant to sort of like go off, you know, off to the races with. And I think what we really want is actually a reference implementation that functions like that. If we can't call it a reference implementation for political reasons, I understand that, but that's the thing that I really want to see happen as quickly as possible.
Thank you, Laurie. Does anybody else have
comments about the terminology reference implementation?
If not, I'd like to
I'm sorry. So So just to be clear, or your proposal is to have a mono repo format with regards to the spec where reference implementation would exist in the same repository?
Yep. I'm volunteering to do all the setup if that's okay with everybody.
I'm not quite sure that I for one would be comfortable with that. I think it's one thing to, to list implementations and to indicate that this is the most complete one, possibly having either rubrics or test suite columns, but an implementation right along with a spec. I'm not sure.
I'm not sure we can
get buy in from the community.
Let's see. If assuming that zoom orders the order in which you raised hands, Adrian, you're next.
So I strongly support the idea of having a reference implementation no matter how minimal it is. Because overall, the SSI work is just so complicated for anybody that comes in from outside that are avoiding having reference implementations in the various groups. That at least to each other is just making adoption work for for us as a whole. I know that this is not necessarily in scope and within the rules, and I'm certainly not insisting, but I'm just saying, whether it's here or in the IDs. This is this is a big problem. From my perspective.
Kalia it sounds like
I see the order, I guess so orys next.
So I just want to point out that the web assembly specification has a reference implementation in Oh, camel that sits in the same repo. And web assembly is one of those things that's been hugely impactful for operability. And I look at the work that's happened there is really exemplary of what I what I wish my standards participation could be like. So I'm not I'm not just coming up with the idea to put a reference implementation next to the special Without good good evidence I'm basing it off of what I've seen is very been very successful with webassembly. Thank you.
I know we're almost running out of time, man.
Yeah, let's, in general I minus one for for calling anything a reference implementation, double minus one for putting it right inside the spec. I'm fine with us having a separate repo that says basic implementation, and then pointing to it in a non normative way. There are all kinds of bad things that happen when you have reference implementations for things that are not as straightforward as a programming language. Right. So web assembly, there's a reason there's a reference implementation for web assembly and there isn't one for example for a browser, basic browser. So So I think this this path is fraught With all kinds of bad things if we save reference implementation, and we start putting stuff, you know, into the spec, but if we just have basic implementations implement implementation example implementation, and put it as just another repo that's hosted that diff, I think that's fine. That one of the really bad things I've seen happen when you do these types of implementations is that people go off and copy them thinking that they can just copy it and put it in a different language and then go right into production with it, and it blows up in their faces. So again, there are there are a lot of good reasons for not doing this. And I'm really concerned about, you know, a suggestion along the lines of what what he's presenting, but but I think there's a way to make everyone happy. Let's just be very aware that there are dragons here. And let's be careful about how we do this.
That's a great wine.
All right, so it sounds like we're out of time.
astoundingly managed to go through all of the issues. And closing everything is a always a valid strategy. And okay, so we will be sending out a doodle poll, selecting our next regular meeting time and see everyone in the call. Oh, one one quick question. I think for for Balaji. That is a mailing list.
Do we want to just say next week's meeting is at this time?
So just because it's on the cat like, yeah, yeah. And it is talking to
the other group and agreed. Yeah, yeah.
Okay, great. Perfect.
Yeah, now I'll bring up the topic of the list. The next call.
Okay, it type you're protected. And I just copied in. And thanks, everyone for the call.
Question four. Is the hacking thing. A good place to link to the note? Is that going to be a stable link for the notes? No Good question.
We're going to the stable link to the notes is going to be the wiki page. And at the end of each meeting, we're gonna create a wiki page for the notes for that meeting. So no, the hack MD is temporary. This wiki link that I just pasted in chat is the permanent one.
Okay, as I'm sending it to Josh, I just wanted to not confuse.
Thanks, Adrian. Thank you.
All right. Cheers, everyone. Here's mine.
Thank you. Bye bye.