# W3C Solid Community Group: Data Interoperability Panel

* Date: 2022-03-29T15: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
- Jackson Morgan
- Angel Araya
- Laurens Debackere
- Stijn Taelemans
- Jasmine L

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

* Jasmine - PodPro
* Quick sai-java update
* Interop spec as CG Draft

### Minutes

### PodPro Demo - Jasmine L

* JL: Aims to bring existing solid developer tools together with pod data. Includes tree hierarchy / navigation and a code editor to see data. Bottom panel includes information about headers / link headers. Can click and follow links as needed. Interface is read-write (ability to save modified resources). Can add containers and resources within them. Can also connect to multiple pods at the same time. Includes authentication modal with details on current credentials in use. That's all the functionality as it currently stands. Interested in suggestions on how to make it more useful.
* JB: I really like the interface, it feels like browser developer tools. I started think about how this can be extended to support SAI spec.
* JL: Code editor was based on browser code editors so it was intention to simulate those familiar experiences. I think there's a lot of potential to add functionality to help with interop stuff. Stack is built in elixir with phoenix web framework.
* AA: Can it be used with a pod on localhost.
* JL: You would need to expose it on public ip/domain
* JB: Do you plan to open source it or make a premium developer tool.
* JL: I would like to open source the elixir solid library. Not sure about the whole app.
* JB: We obviously love open source but the notion of some premium well maintained dev tools is also attractive. Myself I use some paid premium tools and I find them worth the cost.
* JL: It's just a question of doing it in sustainable way.
* JB: I don't have much experience in elixir. Getting support on more stacks for SAI is something we always support and stay active with. Currently we work on open source implementation in Java and TypeScript.
* JL: We could add some useful features build on top of javascript.
* JB: We are at the point where we have most of the tooling done and start building something with it. We want to make Dev experience as smooth as possible.
* Pavlik: Wanted to bring up that there's a separate meeting for implementation today specifically (one hour after this)
* JB: I'm looking forward to use app you are working on in my day to day workflow.

### sai-java

https://github.com/janeirodigital/sai-java

* JB: There have been some notable developments. Now it is functionally complete. In latest PR I'm doing final fit and polish for the first release. As part of it I've broken out some stand alone libraries.
* JB: RDF utils for anyone working with Jena: https://github.com/janeirodigital/sai-rdf-utils-java
* JB: HTTP utils for anyone working with OKhttp: https://github.com/janeirodigital/sai-http-utils-java
* JB: Both have full test coverage and JavaDoc documentations. README still needs to be updated for both.
* JB: AuthN now is broken on its own: https://github.com/janeirodigital/sai-authentication-java
* JB: It provides Solid-OIDC compliant client?
* JB: Final draft of sai-jave will be done this weekend. We will migrate from URL to URI classs
* eP: Solid-OIDC it's just client or any server code?
* JB: Just client, I may need to check latest Solid-OIDC.
* LD: Very excited about sai-authentication-java. We are almost at the point where we need Solid-OIDC for Java.

### Interop (SAI) spec as CG Draft

* JB: We can just throw some ideas and have more focused talk next week.
* Pavlik: I tihnk we can sync it with the project board - and once we see it's mostly done - call it community draft and keep iterating. Mostly at the time where we add it as CG draft.
* JB: What items or issues don't need to be settled? We discussed various issues like Public Access Needs, Trusted Agents. I would like to make sure that we have as full coverage as possible.
* Pavlik: CG draft doesn't have a high bar for FPWD. It's not equivalent to CR so we can still make breaking changes. Approach for Solid-OIDC was to make sure that known issues are added inline in the spec. This way we can clearly advertise there are known issues. Anyone that reads the spec can follow-up. Should look to see if there's anything quick to solve and add missing issues inline.
* JB: It's probably worth consider if spec should move to it's own repo. I know that Solid-OIDC, notifications etc. were broken out in it's own repo.
* Pavlik: In notification it was easier because it was done from beginning. Not panel is just UCR and minutes. Git history is in new repo. With Solid-OIDC there were external editors on draft then it was submitted to panel repo, then it was moved to its own. For interop, i'm not sure if that's best because we have all the git history here. Not worth it to lost all the history. Different could be to decide if other work items on the panel. Might be worth renaming panel to sai.
* JB: I'm happy to keep things the way they are now.

### Access Needs for Public Resources

https://github.com/solid/data-interoperability-panel/pull/254

* LD: Next week we can discuss it once I have some snippets added to that Draft PR.

### Delegated Data Grants

* Pavlik: Need to start looking at longer delegations chains, or where delegated data grant could be issues as a VC, and then pushed as a claim (e.g. with UMA claims pushing) to authorization server. Can have both defined, and then one or the other could be used depending on the scenario. We're still missing the part of how the authorization server gets the client constraints - but there aren't existing authorization servers that can do that yet.
* JB: We can design / architect it but it would be great to have some crude working implementation.
* Pavlik: There's a workstream for CSS to support latest Solid-OIDC to support the latest authorization panel. We also need to pickup the slack on the authorization panel. During the last meeting Matthieu imagines that the ACP engine would run on the authorization server and not the resource server. CSS is combining a lot of those components. https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1154
* LD: Interesting to note - i've been working for the past couple of weeks for CSS that support an UMA authorization service. Planning to open source the repo - modules for CSS need some code coverage here. It's an empty authorization service at this point - no API for communication with authz agent or acp matcher, but could be interesting as a testbed.
* JB: Are you collaborating with anyone dong work on Solid-OIDC support in CSS?
* LD: We discussed issues with Joachim and Ruben. CSS uses op-provider library which is not open to adding UMA support to it. I was looking into it and I decide to modify authorizer instead. The will need to rewrite the IDP component to support UMA. My code base was a first attempt which could point them in the right direction.
* JB: I recall it is https://github.com/panva/node-oidc-provider are the authors are not open to the UMA support or the way it is written?
* LD: It doesn't seem that there are extension points here. It is very focused on OIDC. I know that Joachim is vofking on it.
* Pavlik: I think on Mondays we have less workload so if you're willing to bring updates on Solid-OIDC and can join monday authn panel those would be welcome
* LD: will check into joining - might be handy to have Ruben/Joachim. can present modules i've developed around mainline as demonstration of how it could be integrated.

### Open Business

* Jackson: Good to hear there are implementations under way for this spec. Was talking with Ruben and he mentioned there should be a process to simplify the spec first.
* JB: We've spend a year doing a ton of refactoring. We reduced the size of the spec by around 60%. We no have two full coverage implementation Java and TypeScript.
* JB: Big percentage of the spec is meant for Authorization Agent or other Trusted Agent which is meant to help user with authorization decisions. Other parties don't need to implement that. I was showing Ruben some boiler plate code for what applications need to implement.
* JB: We don't expect developers to write interop libraries, we expect them to write apps using existing libraries.
* eP: We also work on open-source AuthZ Agent implementation which uses the sai-js library: https://github.com/janeirodigital/sai-impl-service/
* Jackson: I'm working on closing gaps on dev tools to build modern applications.
* eP: We will need webhooks implementation for AuthZ Agent
* Jackson: I'm working on this notification subscription type.