### Solid Interoperability

## Agenda

* Recap of progress (spec / api / primer)
* [Add creatorAccessMode PR#167](https://github.com/solid/data-interoperability-panel/pull/167)
* Agent Registry and Data Consent / Access Grant / Data Grants

## Present

* Hannes
* Eric P
* Barath
* Justin B
* Angel A
* elf Pavlik

## Minutes

### Recap of progress (spec / api / primer)

Justin: Over last few months we got to consensus on a lot of things we want to change in the spec. In big part driven by TS implementation - sai-js.
We are getting close to get optimized and consumable specification. Working on it as https://github.com/solid/data-interoperability-panel/projects/1
We have separated operations from the main spec. Probably 50% of initial spec were operations.
If you look at current operations, they will still be reduced in next iterations.
We have added discovery of Authorization Agent (from user's WebID Document) via property `interop:hasAuthorizationAgent`.
We extracted snippets from the spec, the way primer is doing it. Now snippets are included from separate files rather than put inline in the spec. It will also allow us to validate snippets, or include in other workflows as it's done in the primer (sai-js uses those snippets as text fixtures).
We have replaced Registry Sets with a single Registry Set resource. Now a given agent has a registry set. It is non public document which links to all the registries. We agreed that all registries are singular with exception of Data Registries.
We used to include shape and shape tree definitions in line, which was redundant to table with property listing.
Now the document is much more consumable. And now we are getting to steps which will remove some of the sections.
Next steps will involve replacing ApplicationRegistry with AgentRegistry. I anticipate similar amount of changes in upcoming week as we had in last week.

Pavlik: I will start new bikeshed entry point for a primer targeted at audience developing libraries for applcations.

### [Add creatorAccessMode PR#167](https://github.com/solid/data-interoperability-panel/pull/167)

Justin: Let's say I've got Data Registry with Data Registration for Projects. I could give Pavlik access to create new projects in that data registration. For example I allow him to read only other projects, but on the projects he creates he can read-write.
It may be more typical for comments. In a blog I may update my comment but not comments created by others.
Pavlik: I would imagine that we can have `accessMode` to apply always and `creatorAccessMode` would be additive.
Justin: I will adjust PR accordingly

### Agent Registry and Data Consent / Access Grant / Data Grants

#### [ Create Agent Registry #157 ](https://github.com/solid/data-interoperability-panel/issues/157)

Justin: We will replace Application Registry with Agent Registry, it will have registrations for both applications and agents.

Pavlik: I see issue with terminology of having Agent and Application but no 'Social Agent'. Similar to LDP Resource and Container but no 'Non-Container Resource'.

Justin: I actually was stumbling upon it. We should probably address it, I remember we had issue for it.

Pavlik: https://github.com/solid/data-interoperability-panel/issues/80

Justin: To sum it up. How do we tell difference between Applications and People / Organizations. Pavlik calls them 'Social Agents'. Currently spec tends to call them just Agent, which technically also includes Application.

Hannes: It would be interesting to consider when this relation between data and it's owner is being made.

Justin: If you are a bot, it would be operated be someone. In Application case we have property who developed it. It may be useful to capture which 'Social Agent' is operating / responsible for social agent.

Hannes: What again we are needing it to solve?

Justin: Instead of Application Registry, were user is granting access to applications. We will use the same mechanism for Social Agents. So I can have registration for you and store grants there which I created for you, I can point you to them. Similarly if you share something with me I can also 'put' it in there.

Pavlik: Since we any agent that shared data with us, we can discover the agent registration created for us. Now we pretty much just need tracking list of agents for who we want to keep track on data they shared with us.

Justin: We should discuss workflows, Alice granting access to Bob and Alice granting access to an Application.
* Alice grants access to Bob on Project 1
* She will store Access Grant and its Data Grant(s) in Agent Registration she creates to Bob
* Alice send to Bob an Access Receipt which Bob stores in Agent Registration he created for Alice

Pavlik: I would just call it Access Notification which doesn't need to be stored (other than resource created in inbox).

Justin: I think the only difference is what we imagine being stored to record existence of that registration created for us.

Pavlik: I think Agent Registration that..

Justin: To reiterate,
* Alice shares data with Bob and send Access Notification which only has link to Agent Registration Alice created for Bob.
* Bob Authorization Agent would ask bob if they want to track that contact, if yes link to that Agent Registration is being added to Agent Registration Bob created for Alice.

Pavlik: ...

Justin: So later Bob wants to authorize application to work with that data

## Actions

Justin: to add 'Social Agent' class