# W3C Solid Community Group: Data Interoperability Panel

* Date: 2022-02-01T15:00:00Z
* Call: https://meet.jit.si/solid-data-interoperability
* Chat: https://gitter.im/solid/data-interoperability-panel
* Repository: https://github.com/solid/data-interoperability-panel

## Present

- Justin B
- Tom H
- Stijn
- Barath
- elf Pavlik

## Regrets
*

---

## Announcements

### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Use panel chat and repository. Queue in call to talk.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md)
* If this is your first time, welcome! please introduce yourself.

### Scribe Selection

* JB
* Pavlik

## Agenda

### Consider data protection panel

URL: https://github.com/solid/authorization-panel/issues/286

* Pavlik: Discussed in authorization panel about ways to describe policies (e.g. ODRL). Once you have access to data what can you do with it? Keeping in mind once you access the data we can't prevent you on what you can do with that data.

* Tom: Often there are misunderstandings about access control and consent. When talking to customers many times they're confused because in GDPR consent is a legal basis on how you can process data. There's a distinction between act of making data available vs. reason or justification recipient has to process the data they received. The reason you can process data is decoupled from access control.

* Pavlik: One of the intuitions relates to data grants that whenever we give someone access to data we give them access to access grants / data grants. This would be a good way to communicate those policies. Often the person getting access wouldn't even see the access control resources. Data grants provide the context they need - would be a natural place to attach those policies.

* Justin: Data Grants were designed with such features in mind. I don't know if there will be one way to model it. It may depend no locality. It would be great to start with one.

* Pavlik: Beatrice is working on ODRL in Solid. Would be good to be able to reflect in a grant that resharing is not allowed and then authorization agent could warn her when she's trying to share (and break policy).

* Justin: I think sharing use case will be pretty common. Does anoyone talk about using [GConsent](https://openscience.adaptcentre.ie/ontologies/GConsent/docs/ontology)

* Tom: I don't think we should recommend standards to model data on the pod.

* Pavlik: I think there is a middle way. For example for AA to present clear UI to the user we may want to define some common features.

* Justin: I didn't work with ODRL, just a little bit with GConsent. If we pick use case it would be good to try it out.

* Pavlik: Do we see it fit for this panel?

* Justin: I think it could send this panel on the tangent. I see work of this panel to incorporate such policies. I think this panel should stop after showing few examples.

* Tom: I think we put a lot of effort into settin policies before user sets access. We still need to keep in mind that for example in GDPR we have something called 'legitimate interest'. You could use data with different purpose than person who granted access to it. Eg. if you gave contact information to bank for purpose of a loan, bank could still send you the postcard. Efforts could be more directed to after the consent was given. User could be updated with information after data sharing.*

* Pavlik: Good points - ... - current interop work is more focused on policies that have been applied and granted. Don't think we've done any work on purpose of use / misuse.

* Tom: we tried to implement that we a data browser called inox, then demonstrate what it would look like if we could report on purposes of how data was used. felt like it was essential / missing.

* Pavlik: key would be to decide who is interested in working on this. for me it would be to continue to work on the delegation pattern and how this could be shared.

* Tom: Also will look into it

* Justin: It would be worth while to talk about trusted consents and trusted grants. Angel raised some questions about consent and grant model. Eg. is there application registration for authorization agent and how consent and grants for it would look like.
* ...: There is also similar question related to multiple authorization agents. Or is it more about agents which have elevated priviledges - trusted agents.
* Tom: I could explain the use case. We have a customer who want to provide process orchestration for complex data use cases. For example someone buys a house and they need to have complex data flow between notary, insurance and infolved parties. Each party will have a WebID. Every data sharing instance will be a new data sharing instance. If you buy a house notary will require to share data from insurance agent. You haven't made connection with insurance agent before so it is a new connection. It may not be good user experience if every time you need to go to another app (AA) to authorize the access.
* Justin: Who is the first organization that the user is interfacing with? Is it the real estate agency.
* ...: Let's imagine world where everyone has WebID and user has pod with some data. If that service provisions the pod and WebID they would probably also provide their Authorization Agent.
* Tom: We are setting up WebID and pod service. Process orchestration application is someone else's service. We don't want make it harder for that service to always have user pass through user AA.
* Justin: Process orchestration service could ask for everything at once.
* Tom: You don't know notary up front, this application can show list of notaries and user could choose it from there.
* Pavlik: would be really good to document this use case - should also look at where delegation can help us. Also we often look at service but could also be delegating the social agent behind the server (not limited to one service/application). would be really good to describe what we know so far. Could use delegation so their app could generate another source grant themselves.
* Tom: Is there a reason not to allow more than one authorization agent?
* Pavlik: At this moment Authz Agent has unrestricted access to your data, want to limit how many you give this out to
* Tom: Want to be flexible to users to allow them to use different authorization agents.
* Justin: Current pattern would allow user to change authorization agent at any time.The difference from email client is that AA is someting that other parties interact with. One can have multiple OpenID Providers so it seems ok there. Determining which AA you choose is one case.
* ...: I think trusted grants and consents, or delegation could be used in discussed use case.
* Tom: I was hasitant at first. Discussed app can be used for any user journey. This seems like a good oportunity to onboard people on solid. As pod service provider we could audit it and make an example of it.
* Justin: We sould write down this use case and all the open questions.
* Eric: The big question is wheater or not this workflow enging has scope access or complete access. If it is not AA than it has scoped access. Just for first use case I see how this could work as scoped access. If this service does this and all kind of other things it may be attractive to give unscoped access.
* Tom: Multiple AA was just one way we toguth of solving this problem.
* Eric: If we have multiple ones, if one used by this service would be unscoped?
* Tom: Depending how we can scope it. I'm all for not providing access to everything.
* Pavlik: We should keep in mind what user needs to explicitly opt in.
* Tom: Honestly what keeps me awake at night is what authentication you require when you access different types of data.
* Justin: You can always restrict issuers especially early on. People may not love that but it may help ecosystem.
* Tom: In the end is always balance between UX and data protection requirements.
* Justin: I think writing down those use cases will be the best way to move them forward.