W3C Solid Community Group: Data Interoperability Panel

# W3C Solid Community Group: Data Interoperability Panel * Date: 2022-03-08T15: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 - Angel A - Laurens D - Wouter T - elf Pavlik - Eric P ## 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 * Check-in on outstanding specification tasks * Responsibilities of Authorization Server * sai-js dependencies (from Angel) ### Minutes ### Check-in on outstanding specification tasks #### Update Access Consents to Access Authorizations and Data Authorizations * Justin: Last we decided on renaming Access Consent and Data Consent. I should get it done by next session. I'm also updating sai-java code as I do it. #### [dataOwner in scope:All]( https://github.com/solid/data-interoperability-panel/issues/248) * Justin: We have incorrect snippet with dataOwner on All scope. It is super minor I can get it done unless someone else will get to it first. #### [Finalize design for trusted consents and trusted grants](https://github.com/solid/data-interoperability-panel/issues/187) * Justin: We need to make PR to the spec. It should represent consent given to trusted agents and applications. This would apply to Authorization Agent or Social Agent you delegated administrative access to. For example admin of an organization. * Wouter: What exactly do we understand under trusted agents in that sense? * Justin: Trusted agent could be a Social Agent or an Application. There have been given essentially administrative power and capability over the data owner's registry. Could apply to Access Registry, the Agent Registry or Data Registry. * Wouter: How does that align with earlier advise not to have more than one Authorization Agent? * Justin: Authorization Agent is a trusted agent but not all trusted agents are AAs. * Wouter: Okay, so there will be different tiers of permissions within trusted grants? * Pavlik: at the moment we've just discussed full admin tier, but we may want to be more granular. should work over use cases. Also did we capture more generic data access (e.g. data browser) * Justin: That discussion I put it under next header, proposal for publicly accessible data. #### Generic data grants * Pavlik: mostly applies to data registries, e.g. in pod browser case where something should have access to more than a specific shape tree * Justin: Few use case would be a good place to start. * Pavlik: In the spirit of discussion with Jeff last week, look at how solidOS and other apps can more readily adopt interop patterns #### Proposal for publicly accessible data [Issue#243](https://github.com/solid/data-interoperability-panel/issues/243) * Justin: We need to build on what Laurens put in that issue. * Laurens: I can propose something there based on what's in the spec #### [Incorporate profile requirements from solid-oidc](https://github.com/solid/data-interoperability-panel/issues/210) * Justin: I actually think we have any blockers left here. In sai-java i have it implemented. This is a matter of reflecting it in the spec. We have now JSON-LD context for the spec itself and patter for how those contexts can be combined. * Pavlik: I think we should consider again whether we want to mandate that context because we don't guarantee on solid that the compacted version is preserved and it becomes more complicated to store it. I think it's problematic that it couldn't be reliably stored in solid storage. * Justin: That requirement is imposed in solid-oidc document. In sai-java the code takes content type for read and write. It's not really burden on the client. The rational of not having to deal with with RDF on the OP? * Pavlik: Yes i think the rationale is for OPs that aren't RDF aware it's easier for them just to parse JSON. Generally believe that it's better for consumer to provide context they rely on for compaction and framing. #### [Determine how to dynamically authorize access to reference lists on inherited instances](https://github.com/solid/data-interoperability-panel/issues/174) * Justin: There is an open question on weather we want to go into in the interop spec. Or is it more about tooling in companion specs like shape trees. * ...: The problem to solve is related to `Inherited` Data Grants. For example you have project you get access to `project-1` and based on the shape tree reference you get access to related issues and milestones. This is one of the real powers that we have based on shape trees and shape tree references. We model it with `Inherited` grant scope, access to issues is inherited based on access to the project. * ...: Not all tasks in data registration belong to `project-1`, semantically it is pretty straight forward. Given project will have a graph link to issues that are part of it. Our access control systems don't provide mechanism to give access based on the presence of some graph relationship. I think they should but they don't at this moment. * ...: We actually have use cases in authorization panel. In long term it would be good to get access control system supporting it. Meanwhile we can have notifications and for example AA setting access based on those relations. * Pavlik: or AS * Justin: Let's say I have shape tree for a health record, they have references to prescriptions, conditions, appointments etc. For example I want to give app to prescriptions but not other related resources. If you have those references in main health record, how do you prevent app to change references to other resources than prescriptions? In some databases you would have `prescription-list` which is a separate resource. The app would have only access to prescriptions and that prescriptions-list resource. For me it's a really good place to start the next round on the spec. I'm open to thoughts and opinions. * Eric: It seems that we try to gaze in the future and see if we don't paint ourselves in the corner. * Justin: I think it is a lot easier to work on problems like this when you have working implementations. ### Responsibilities of Authorization Server https://github.com/solid/data-interoperability-panel/issues/250 ### sai-js exported module type https://github.com/LinkedSoftwareDependencies/Components.js/issues/83 * Angel: For AA impl that we use component.js I run into a problem that component js loads all the modules through common.js sai-js only exports es modules. * ...: Component js sees it straight forward but doesn't have it in near roadmap. I think we can modify sai-js to export common-js. * Wouter: Maybe we can contribute to componentsjs? * Pavlik: If Wouter can evaluate contributing to componenetjs I will look into temporary common.js exports to sai-js. * Angel: I don't know if we have any other dependency that is node only. * Eric: Does mean that every constructor that needs fetch is getting fetch argument. * Pavlik: In sai-js factory keeps reference to fetch and it prevents you from needing to pass it around as developer.