# Solid Interoperability Panel
July 6th, 2020

## Present

- Justin B
- Josh C
- Jackson M
- e Pavlik
- Eric P

## Agenda

- [Ecosystem Proposal - Application Registration](https://solid.github.io/data-interoperability-panel/ecosystem/#appreg)
- [Ecosystem Proposal - Data Registration](https://github.com/solid/data-interoperability-panel/tree/data-registration/proposals/ecosystem)

## Minutes

### [Ecosystem Proposal - Data Registration](https://github.com/solid/data-interoperability-panel/tree/data-registration/proposals/ecosystem)

- Justin: Data registration defines how you organize data in the pod. Specifically data which you will use in applications. Authorization determines what access is needed to that data.
- Pavlik: I see that those two stay codependent
- Justin: Interop allows applications to communicate what kind of data they work with. To make it intitive, how one organizes data is key.
- Jackson: I remembevr in previous indexes they could include types of data which don't have instances yet.
- Justin: Data Registry could also do that, it would just include shapetree.
- Justin: We have a case here of intersecting shape trees, at the data registration you have point where ecosystem infrasturcture ends and dynamic data starts. You also need container to contain instances of tree that one have registered.
- ...: Shapetrees allow asigning multiple shapes to a resource. This allows ...
- Pavlik: Does instances have to stay contained in registry?
- Justin: You can have multiple registries but within one registry all instances should be contained in it.
- ...: Instance of a notebook can point to things in other places.
- Eric: it indexes data that is on your pod.
- Pavlik: I think one would create multiple registires for a single pod.
- Justin: It has no need, one can assign different permissions within one registry.
- Pavlik: What if you want to manage access per set of data instances.
- Justin: We don't want to make different registrations for the same type of data. I see couple of issues with WAC. For example not being able to do tagging.
- Pavlik: If each instance of data can delegate access rules to specifc access rules set, it would provide access based grouping for instances.
- Justin: I think we need one additional dimension of flexibility.
- ...: Regardles how you store the data, one should be able to get different representations. But if one makes authrization decisions based on that, it should give consistent responses.
- Justin: In WAC we already can group agents. What we don't have are data groupings. If we have both we could combine them.
- Josh: Do we have preference if we need some kind of tag based approach or instances should be independently currated. For example case of taking few instances from registration and applying access rules to them.
- Jackson: So there would be some mapping between tag and ACL
- Justin: I think we need to be careful that changing tag would not create security hole.
- Jackson: I think this idea can be applied to entire WAC system. Currently it depends on container structure. By default resource acl can point to the parent container but we could change it to point to something else.
- Justin: It sounds like what Dmitri proposes with `wac:dependentOn`.
- ...: What would stop me from changing permissions ..., if you have control on resource you can set whatever you want. Currently as soon as you set specific permision for resource, it doesn't inherit access rules any more.
- ...: If I say that Pavlik has write access to all instances to notebooks which I registered. If I have 3 specific instances and say that Jackson and Josh have access to those three, I would expect that Pavlik still has access to those 3 specific instances.
- ...: Because WAC doesn't allow reusing parent permissions, we would need to add those rules to all the 3 specific instances.
- Pavlik: I would prefer to always have explicit rules, something like `wec:dependentOn` would help with keeping default WAC inheritance behavior without having it implied. We also may need a way to rely on group of agents, group of data instances, group of access rules.
- ...: Do you have still notion of remote data registrations?
- Justin: I was trying remove things which I haven't document properly yet. Collaborative use is 3 stage of working on this draft. If I open my notebooks application, it should show me 'shared with me' notebooks.
- ...: When Alice shares access with Bob, he should not only be notfied but also able to record having that shared access in some clear way.
- Pavlik: I think at some level any user should have entry point from which it can crawl all the data they can access.
- Justin: While one registry set can have multiple registries, we still don't determine what would go in which registry. Remote registries and discoverable via registrar. I see the Registrar pattern as starting point.
- Justin: If solidproject had group storage. We all as controllers could have data registry in our registrar. So current pattern should work as long as you have controll access.
- ...: As we originally discussed it we thought to have data separate from registry but linked to it.
- Pavlik: I would find it an interesting excercise to consider case where user has dedicated solid storage just for their registrar and all the data stays remote in other sotrages (personal and group).