# W3C Solid Community Group: Data Interoperability Panel

* Date: 2021-11-23T14: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
- e Pavlik
- Eric P
- Angel A
- Jamie F
- Barath

---

## 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

- Pavlik
- Justin

## Agenda

### Action Items from Last Week

PRs - JB - Complete #190, #213, #217

* Justin: #217 was small but related to discussion about unifying Client ID Document from Solid-OIDC.
* ...: I updated spec to have access needs in external document and only reference them from application profile.
* ...: #190 was about retaining historic consents, because they are immutable i generate new access consent when i want to update existing one. Now the new one can link to the previous one, the one that gets superseded.
* ...: #213 renamed some properties related to grants and consents. It is now more intuitive when you read examples (turtle).
* ...: We only have few things left on [the project board](https://github.com/solid/data-interoperability-panel/projects/1), one of them is about references list which we can dive into today.

### Sai-js update

* Pavlik: PR for authorization agent - https://github.com/janeirodigital/sai-js/pull/25

* Pavlik: Hopefully people can look it over this week and ideally have it merged by end of the week.

* Justin: I started going through that PR and I'm working on Java implementation.
* ...: In the scenario where you have application that is a bot running on behalf or organization. The user has given consent to that application but the application has many users, since it works as service. The way that implementation class for application is written, it gets instantiated with WebID of the agent that is the current user. This was just eyeballing, I was trying to thing though scenario above. Weather this class needs to change or service needs to keep some state in context. When it wants to go and access data that it wants to access, than is in a state where it uses the application class as per user basis.
* ...: I started thinking about how authN and authZ infrastructure looks like, with strongly identifiable authentication and the token that it provides to the Resource Server. And the different Authorization Services that are in the mix.

* Pavlik: Great use case - haven't given it a ton of thought yet. From a resource standpoint we always expect to get the social agent and the client (application). Need to be careful how we expect those pairings to get pulled together. The scenario presented there are two cases:
- Server-side service used as an application by the user (e.g. user logs in and the user's webid is leveraged, and app needs to keep some state to know which to send for which user). Would be a different instance of fetch per user
- Less explored - if the user is giving access to the organization the runs the application and the application is running "headless", when requests are made to the storage, the "organization" would appear as the social agent with the client identifier. Need to clarify who is being authorization - organization vs. user, and whose webid is presented.

* Justin: I agree with how you laid out the two scenarios. It would be probably fine and appropriate to maintain the pairing as organization as social agent and application, when it operates in this 'headless' way. In the past the we were using same uri for webid and client_id. In application profile we already identify the responsible social agent as author.
* ...: We have to detail out a little bit what the moving parts look on the authorization part on Solid-OIDC. Actually that's the first use case I need to demonstrate with Java library. I can take action item to dig into this one.

* Pavlik: if you could focus on the consent screen presented to the user, do they have an application registration, or is it a social agent registration? Possibly there will be cases for both. Possibly approach it in both ways.
* Justin: My gut says that you would want to have Application Registration, but they could be case where we want to have Social Agent registration for the organization. I may want to authorize social agent services one by one.

* Eric: If there is pairing between

* Pavlik: When saying the user wants to authorize certain services, we could use access need groups for that. Services could be expressed that way. For different services there could be different access need groups.

* Justin: I think there is good reason to have both available. Organization could use access need groups under application umbrella. It's nice to have that flexibility

###

* Eric: We can extend grant in the future that if grant has delegation privilege they can pass it further. As proof-carrying delegation. It's dynamic access control, owner doesn't maintain list of who has access.

* Pavlik: Lines up with where i"m hoping to head with delegated / trusted grants. Already have setup for delegated grants between owner and application they use. Can use the same pattern in a chain. Also need to have an upstream notification of delegation. Omni gives Alice access. Alice delegates that access to Bob. Alice needs to let Omni know so it can update its records. Will share a link to authz panel.

* Discussion: https://github.com/solid/authorization-panel/discussions/271

* Eric: One strategy is proxying - where Alice never needs to know that Acme delegated. Could say that anyone can submit to me a proof chain and I'll just check it, and no one needs to be notified of those delegations.

* Pavlik: In this scenario, the grantee shouldn't have knowledge of what was granted, the delegation should be narrow. Upstream party should know, downstream shouldn't.

* Justin: I find delegation chain approach elegant and clean. Keeping the upstream informed would need to be addressed. At least telling them where to go to get informed.

* Pavlik: To complete the trusted grants we probably need to solve this. Don't need the weirdness of control access.

### [Dynamic authorization by reference list](https://github.com/solid/data-interoperability-panel/issues/174)

* Justin: https://hackmd.io/@hAlm_W2-T-q16baquNyRXg/HyS6Xuqdt
* ...: It gets the concept across, I used health scenario since we deal with it a lot.
* ...: You have Data Registry and Data Registration for medical records. Medical record is composed of prescriptions and appointments and conditions. Medical record is more of a meta object which just links to all those other things.
* ...: If I want to share the whole medical record with someone who helps taking care of me, I can share the whole medical record with them. To give partial access, in that case Alice wants to use Prescripto application. She wants it to access prescriptions but not conditions, appointments etc. Prescripto needs to see all the prescriptions and also if it adds new one it needs to link it to medical record. For prescripto to know it needs to be able to see those links. If Medical Record contains links to everything (conditions, appointments, prescriptions). Even that Prescripto can't follow those links, it still leaks data by knowing how many conditions and appointments there are linked. Which on itself is not acceptable.
* ...: We either need to say that Prescrito gets partial access to medical record, which would require something like shapemasks or tripple based authorization. Or we need to maintain those links in stand alone resources. This term of reference lists comes from that. We could say that Prescripto has access to prescriptions reference list but not to reference lists of conditions and appointments. It seems like the most straight forward approach. We would need to ensure that shape paths can follow external resources.

* Pavlik: Ties into what's the parent shape tree and the target shape tree (e.g. child). Needs to be a way in the medical record to say what the reference lists are for the children. With that information we'd be able to discover what the right links are.
* Justin: I think the first place to investigate would be in shape tree definition. Shape trees are designed to provide that navigation of multi resource hierarchy. We already have the ground work for that. I can see where this notion of reference lists typo of a model could fit in.
* Eric: I think we could do it with shape masks.
* Justin: I think shape masks are elegant long term.
* Eric: When you want to PUT you need to know which part of the graph.
* Pavlik: Might be useful to talk to GraphMetrix about triple level access control approach. Would be good to get some feedback from their implementation.
* Justin: I believe that shape masks are so complementary to the rest of the stuff you need to do as application. It may be because we use shape trees in interop.
* ...: I plan on expanding this use case a little bit more. I could try to design a shape tree that tries to map this.
* Pavlik: What's important is to keep the reference list as a detail of the reference itself and not make some separate reference to it.
* Justin: So - Encode the external reference (to the list) into the existing shape tree reference between medical record and prescription (Pavlik: ACK)

### Misc

* Justin: On Wednesdays at 3:30ET we have implementation focused sessions, everyone is welcomed to join. Just hit us up on gitter.

### PRs and Issues