# SDS WG - Meeting Notes Thu, May 7, 2020
Notes Doc: https://hackmd.io/Wk_7UInuS8WNMQhsYeTSsw
Fallback Notes Doc (if HackMD can't handle the # of viewers):
* Kaliya Young
* Tobias Looker
* Dmitri Zagidulin
* Ralf Knobloch
* Michael Shea
* Iain Henderson
* Lior Margalit
* Steve Magennis
* Adrian Gropper
* Daniel Buchner
* Orie Steele
* Venue Reddy
* Tony Hall
* Robbie Jones
* Manu Sporny
* Justin Bingham
* Nikos Fotiou
* Eric Welton
* Dave Longley
* Ganesh Annan
* Adam Bradley
* Artem Key
* Iain Henderson
* Dave Longley
* Yancy Ribbens
* rhiaro (scribe)
* John Callahan
* Jack Remey
* Lior Margalit
* Nader Helmy
* Walker Flynn
* Juan Caballero
* Davide Calvi
* Adam Bradley
## Action Items
- Daniel to add Issue for specifying the sync/replication protocol
- Update the spec to include a stub for sync/replication
### 1. IPR Disclaimer and Clarifications
If anyone on the call has not signed the DIF SDS WG IPR Agreement, please contact Balazs at email@example.com
### 2. Scribe Selection?
* Suggestion: Automatically scribed via AI?
### 3. Tools Used
* Voice calls: Zoom
* Queue Management: Zoom Raise Hand
* Notes: HackMD
* After the call, Notes transfered to: [SDS WG Wiki](https://dif.groups.io/g/sds-wg/wiki/18888)
### 4. Meeting Time Discussion
tobias: other groups opt to have rotating timezone meetings. We would like to get some feedback whether they would like to see a multi timezone meeting going forward? Shoudl we be going for a fixed timezone? If so any objectiosn to the current time other than the conflict we're reviewing with DID Resolution?
manu: one preference, I'd like it if we would keep these friendly for NZ and Aus, we've had a number of people state they'd like to attend. Second is ideally let's not rotate the times, I'd prefer us not to do that because it tends to potentially confuse people. There's usually no good way to do it. I'd suggest in place of that any special calls we have we have it at the times other people would like it to happen, eg. something friendlier for european timezones, then maybe it's very late at night for... anyway I'd like us to keep the calls on a regular basis, prefer australia/nz time which works for everyone except the europeans. Special topic calls in times that are better for folks in europe.
dmitri: any strong objections to having a fixed meeting time rather than a rotating one?
kaliya: this time isn't exactly friendly for australia, it's really early; it is for NZ
dmitri: dissenting opinions [in chat]..
kaliya: I'd say we stick with this with the caveat we'd like to de-conflict with DID resolution.
dmitri: the DID Resolution group is also in the process of trying to pick a new time to de-conflict. Put it to a vote? Send doodle polls?
tobias: I think the proposal we should put on now are there any strong objections to changing the time we currently have?
dmitri: we are the larger group than DID Resolution. Proposal to keep this current time until the proposal for DID Resolution new time resolves?
... keep this time until we pick a new fixed time. +1s to that in chat. Resolved.
### 5. Iain Sharing briefly about the MyData Operator Group and End-Points group.
I ran a session at IIW last week on MyData Operators - I'll include the slides and send a link to the paper. https://mydata.org/operators/
MyData has been around for about 5 years, originated in ?? and went to Helsinki, conference based. A lot of the people, there's a good overlap with IIW, Kaliya has spoken there before. About 1000 members in MyData organisation. 25/6 different countries, 200 organisational members. I tend to think of the organisation as its' not quite like the identity community, there's some overlap, tends to be more societal, legal, economic and a sprinkling of technical. I know Adrian is an active particpant, Davide based in London. A fairly hard core of technical people, but all pushing roughly the same direction. Long term, VRM and personal data services have been part of my story for 20 years. What I was speakinga bout last wednesday. For the past 7 or 8 months MyData has been workking towards this white paper about MyData Operators.
It's essientially an org (doesnt' have to be, could be hardware) that acts with a fidicuary duty to an individual to help them manage their data. Certain contents where the operator can be neutral. It can be for the organisation. The white paper sums up where we've got to, 48/9 organisations. A path to interoperability. across the 49 operators there are 49 different ways of doing personal data services. The one positive, that group does not intend to develop any standards, unless it finds there aren't any, very much wants to point out to this group and similar ones for standard development. That's the high level overview.
Here are my slides as discussed at IIW last week https://docs.google.com/presentation/d/1kHgyJYhszhPAsluX1CO9Uoxwg_LfFPHU_DhRM28b8Fg/edit#slide=id.g754ab01e39_2_37
dmitri: a lot of us are aware of the community and would like those who are interested to join this conversation. refreshing to see that the group is not focussing on standards but all other necessary stuff about that, we hope our groups can be complementary.
Iain: anyone in this group is welcome at MyData. A lot of cross fertilisation on digital verified claims, good degree happening already.
dmitri: would you and anyone from that community help us send an invitation?
iain: i'll report back to the slack tomorrow and say we've had this conversation, there's this relevant new group. I've said tothem a few weeks back they want to join this group. I will feed back, you may well see a lot of folks heading your way.
One thing we should do in advance of sending an open invite to MyData would be to include a link to the IPR policy so that people can familiarise in advance of joining up. That would help cut down the number of questions on that.
### 6. [Use Cases Document Review](https://docs.google.com/document/d/18UdEjA2kQRnILnBEnWijNho0YMJ93dbjKntx0NQzapI/edit#)
dmitri: we'd like to go over the use cases document again to see if there remain controversial items so that we can fill it out so it can guide us in further issue reviews. Link is ^
... I don't think we have any clearly marked points of controversy.
michael shea: purely around individual or personal information, it's not around organisational, is that true?
dmitri: the goal here is secure storage of data with an emphasis on client side encryption and it definitely covers organisation.
michael s: IoT or anything?
dmitri: I think a lot of members are interested in IoT use cases, we'll be having a lot of discussiona bout the definitions of actors etc. IoT does fall into it.
orie: i was assigned to this and I'd like to be unassigned. It's a google doc, there are some comments. There's a number of the comments are open ended, I invite members of the community to respond to any open ended questions. i don't see a lot more to do in the document personally. If someone else could take over it'd be awesome.
dmitri: thanks orie.
eric welton: I've had a little itch bothering me about me about biometrics. When you look at sections 2.5 and 2.6 in here, there's this concept of device free, is it opossible to have a ssecure data store that doesn't require the persont o carry around a physical device that they are the custodian of or may cost 6-9 months of wages. One possibility is cloud based systems that you can access using a shared resource, like a computer in a hospital with network access. that's how you could get to your cloud wallet. in those cases you would want to protect your private key material, you'd want to get it from the cloud into the browser to run, the browser would serve as an ad-hoc device but you'd have to use biometicrs to unlock that data. This means that biometrics play a slightly differnt roll relative to edvs and secure data stores than they do with the standard issuer/holder/verifier of biometric data where you're doing an auth of a purchase or something with your fingerprint. this is for unlocking and getting access to thta in lieu of maintaining and carrying around a private key store. I'd love to knwo what the groups feelings are on this and how it relates to 2.5 and 2.6 in there.
dmitri: use case document 2.5 cloud only. That is referring exactly to the scenario that you've described.
eric: there were comments around 2.7 right after that, low power or no device access, those are connected.
jack c: I second eric questions here, at IIW the edv/sds work came up in that context
manu: the encrypted data vault spec specifically is agnostic to those questions so you can deploy edv on a personal device that you carry around, you can deploy it in the cloud, you can deploy a hybrid, you can use biometircics to auth with it, all of these things are possible. I understand which use cases you're talking about and they're very much in scope. I don't want anyone to feel like oh it's cloud only and it'll cost $1000 for the thing and there's no shared infrastructure. the edv specification is at a much lower level and we take all these use cases into account. it's like think about it like storing a picture file, the picture file formats dont' really care if it's store on a floppy disk or a hard drive or an SSD or a cache on a router, on the web. All of those things are possible. Just as those things are possible, using biometircs to authenticate is possible. Not in the core spec, at a higher layer. Running an edv off a mobile phone or a modified usb stick, these are all things that are possible but are higher level protocols.
jack: that was always my impression
eric: the sense I had with the edv/sds spec is you've got to get that key material to engage with it. I'd be interested in seeing made clear in that is exactly that magic where that magic bubble goes where the keys come out of this and go into here. It shouldn't be directly in the spec but the other thought we have when we ttalk about biometrics, it's in the context of having access to a secure data store already. 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 vs having a access to a secure datastore within which i have biometric data.
From Manu: That's Authorization -- and WebKMS
EDVs are Authz agnostic
From John Callahan to Everyone:Agreed - KMS is AuthZ for EDVs
From Dave Longley: For example: generate an ephemeral key pair on a local device, authenticate with a system, that system delegates zcaps to you to access EDV(s) -- then access them.
From Dave Longley to Everyone:authentication can use whatever mechanism you want.
dmitri: another way of putting it is everyone's fave topic, key management. we're going to bump up agains this a lot in this group. it's very important but outside of the scope of the group. we're assuming working key management infrastructure. may include biometrics, wallets, physical, mobile, browser. we will always be talkinga bout key management, but to set expectations, specifically key management and authorization specs are intended to be compatible and pluggable but outside the purview of the group.
adrian: the keys don't necessarily belong to the subject that relates to the storage. What is in scope for the group is that the keys for access could belong to a service provider that is providing services to the subject.
dmitri: in the next call, a future topic is our base documents, our initial source documents that we're merging into a single spec and starting work on that spec: the encrypted data vault spec and the DIF identity hub explainers and specs.
.. we have this starting use case document which hopefully will help with the issues and initial spec. We're keeping it open for issues and comments and at some point we'll put it in our repos.
... we should work on terminology, a glossary document. In the credentials wg, did wg, that community are working on glossary documents. I think we do want to have our own secure data storage terminology as well.
### 7. (if time) Initial [Issues Review](https://github.com/decentralized-identity/secure-data-store/issues)
tobias: thanks orie for going through and labelling some of these. We'd like to see if we can get some resolution on these issues or progress them.
daniel b: [scribe missed]
tobias: we close this?
daniel b: there should be some sort of issue for this new thing that says syncing of all relevent data, configuration and actual data or otherwise. This specific bug I don't care.
tobias: will you create another issue that updates exactly what you would like?
dmitri: everyone agrees that synchronisation is a really important use case, it's in the use case documents, and in the edv deployment topologies. Let's stub out a secton for sync in general.
tobias: that sounds like a resolution. daniel can update and close this issue.
... issue #20, also by daniel.
daniel: related to the old implementation stuff.
tobias: given the current api this list discriminates that kind of aspect, the recommendation I'm seeing in the chat is closing.
dmitri: orie points out to put a note in #21 we're assigning it to daniel.
daniel: issue 19 around how you connect if you use the data store to represent an app. How would you connect the app to its instance ID. THis may come up far down the road but probably not applicable right now.
tobias: the resolution is to close this one as well?
dmitri: i have a feeling this topic will come up down the road. app identification is something the solid community is wrestling with right now, very rich topic.
tobias: [issue 18](https://github.com/decentralized-identity/secure-data-store/issues/18)
daniel: this is about what apis would be used to talk from hub to an app, basically creating apis that make it easier for applications to connect to hubs. i don't think this is relevant right now, this is far future.
tobias: resolve for now?
... account for /messages (17). Any more detail you'd like to add?
daniel: just close it out
tobias: issue 16, add a way for hubs to communicate..
daniel: I don't know if we'll encounter this, seems like it'd be farther out.
tobias: 15 might raise some interesting questions, current language around authorisation. The high level of thi sissue is to discuss the management of access into an edv.
daniel: requesting removeal of permissions specifically, how you'd say I'm authorising x DID to do something. It's good background but I don't think it needs to carry on.
adrian: I mentioned this in another thread. I'm kind of interested in having a name for the triplet that has to do with the credentials of the person who is asking what the scope of data or the data 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 comment on this issue. If it's not then we should discuss it at an appropriate time. Giving this triplet a name.
daniel: defintely a different issue. A detail within something that we build into permissioning in the new thing. This particular issue is probably not actionalbe for now.
tobias: propose closing? any subsequent issue to open?
daniel: there's also the zcap stuff in edv we should have an issue that talks about doling out permissions or specifying encrypted states of data for whitelists of people?
dmitri: we mention in the spec and our use cases that we do expect authz and access control systems. they are menat to be pluggable and out of scope. this is a related topic regardless of the access control system use, how do you request access, should you be able to, is there a standard api to hit the 'request access' button? Out of scope for the moment, I have a feeling it will come up again.
daniel: here's a question - this will absolutely need to exist in the sds spec, something to send a message reuqerst. when we encounter something we know will exist should we just keep this issue even though it has all the gunk from the old stuff or should we close all of them and make fresh ones?
tobias: you would like to suggest the issue you've opened we can mark them all for closing? we'll close if we don't have additional content?
daniel: I'd default towards closing, the extra stuff can be confusing
tobias: 14, close, 12?
daniel: way too specific
daniel: too specific but we might want to look into it.. get rid fo it
get rid of 10 for sure. and 9. and 8 is too specific. and 7, get rid of that. get rid of 6 too. anything talking about the implementation id' get rid of. 5 close. and 4. and 3. and 2. the last one I don't kno wabout. We've talkeda bout MyData on the call
tobias: 1 was opened by adrian. Any further conversation or action?
adrian: no, we can close it. I forgot it was there. Closing the issue that was open by josh mandel without talking to him I think that's, I wouldn't do that without talking to him.
daniel: we can, he's a microsoft employee
tobias: not familiar with this handel, xtianus79?
manu: don't close anything if there's no confirmation on the call. we can say we'll close in 7 days if no objections.
From Eric Welton (Korsimoro):
I'm still struggling with the idea of having a secure personal data store on the cloud that I use to authenticate to my secure data store - i would love to have any help in building out the lexicon to avoid confusion in that discussion.
again - my concern is about connecting the documentation from across projects - it is a terminological and discursive concern - and if anyone has insights, please send me email. ;)
dmitri: issue 3 brings up an interesting.. the official use question. implementations. to put th equestion out to the group here of I think everybody agrees we want a list of implelementations, we do not want in terms of reference implementations but we do want people interested in this to look at libraries. Where do we put that list?
orie: I'm one of those people that plans to help with an implementation. For where we are today with the spec and the ecosystem we're pretty close to wanting to start having some implementation and tests and alignment between spec and implementation so I'm eager to start that work asap. I think the implementation for no wbelongs next to the spec in this repo. I think the tests belong next to th eimplementation. I guess there's been some objection to th eterm reference implementation which irks me. It's not an implementation you should go to production with ever. It's to encourage other implemenations with enhanced performance or other integrations that might be valuable. the referenc implementation's job is to encourage others, not to be the production one, to encourage diversity not to go off to the races with. what we want is a reference implementation that functions liek that. if we can't call it a reference implementation I understand but I want to see that asap.
dmitri: anyone else have comments?
tobias: to be clear orie your proposal is to have something with refernec eimplementation in the spec?
orie: I volunteer to do that
dmitri: I'm not comfortable with that. To list th eimplementations is one thing, but an implementation right with the spec I'm not sure we can get buy in.
adrian: I strongly support the idea of having a reference implementation no matter how minimal it is becuase overall the SSI work is just so complicated for anybody that comes in from outside that are avoiding having reference implementations in the variosu groups that link to each other is just making adoption work for us as a whole. I'm not insisting, just saying whether it's here or in DIDs this is a big problem from my perspective.
orie: the web assembly spec has a reference implementation in ocaml that sits in the same repo. it's been hugely impactful for interop. the work that happens there is exemplary.
manu: -1 on calling it refernec implementation, double -1 for putting it in the same repo as the spec. there's a resaon there's a referenc eimplementation for web assembly and there isn't one for a browser. I think this path is fraught with all kinds of bad things if we say reference implementation and start putting stuff in the spec. But if we have basic/simple/example implementation in another repo hosted at DIF is fine. One of the bad thing sis people go off and copy them thinking they can copy it and put it in a different language and go right into productoin with it and it blows up in their faces. there are a lot of good reasons for not doing this and I'm really concerned about that suggestion. But there's a way to make everyone happy, just be aware that there are dragons and be careful about how we do this.
dmitri: astoundingly we managed to go through all the issues.. we'll be sending a doodle poll to select our next regular time.
kaliya: next week's meeting is at this time