---
tags: Solid
---
# W3C Solid Community Group: Data Interoperability Panel

* Date: 2022-04-05T15: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
- Juliette C
- Eric P
- Stijn T
- e 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

* Quick sai-java update
* [Access Needs for Public Resources](https://github.com/solid/data-interoperability-panel/pull/254)
* Publishing FPWD

## Minutes

### Quick sai-java update

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

* Justin: I have main release, as I explained last week I broke out rdf utils, http utils and authn library. I also have migrated everything from Java URL to URI class. To avoid known issue with lookup.
* ...: I'm going to publish them to maven central. We are going to use them and improve them.
* ...: I still need to work on README
* Laurens: I saw that your authn lib has client credentials. We have alternative use cases for authn in solid-oidc repo. I can add your client credentials support as an example. I see that you fetch access token using client credentials with OP. https://github.com/solid/solid-oidc/blob/main/alternative-flows.md
* Justin: You register client_id and client_secret and use it to get access token. I tested it out and used with keycloak. The library has an abstraction for authorized session, it contains credentials and says what is the social agent id and application id. How do you get those credentials shouldn't really matter. I wanted to make sure to demonstrate two different flows.
* Pavlik: Do you have your keycloak setup documented? How webid gets associated with client credentials.
* Justin: We plan to release solid-oidc support for keycloak.
* ...: For anyone familiar, you can configure mappers, they allow you to inject certain attributes into the token. In keycloak one of the mappers is called *users attributes mapper*. When registering user one can add webid to the user. Than you setup a mapper on the given client that creates a claim.
* ...: In client credentials you just use *client attributes mapper*, it injects webid into the token.
* Pavlik: So currently admin has to configure it, user can't just register client which will be using their webid in tokens issued based on client credentials.
* Justin: We are working on it right now.
* Justin: I welcome any feedback on sai-java and other modules extracted from it
* Laurens: Did you get keycloak to support DPoP?
* Justin: We are collaborating with somebody who has been core keycloak developer for a while. We connected when I saw that he was working on DPoP for keycloak. Now we are collaborating with him to add full solid-oidc support to keycloak.

### Access Needs for Public Resources

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

* Laurens: I have draft PR open for Issue #243
* ...: We still have an open question how to define Access Need and such permissive tree.
* ...: Agent wants to express it's need in public sharing of data instance. We also have case where data owner just wants to share some resource to the public themselves.
* ...: In my PR i propose `interop:publicAcessMode`, we still have issue who would be the grantee here.
* Pavlik: THinking about this a little bit - my approach would be to look at a public grantee (kind of like foaf:agent), and have a way to provide a public grantee. Have a social agent registration associated with that public grantee standardized. Nice part is that the user from the webid could make it discoverable, and you could do that discovery even without authenticating. So would be nice to have a dedicated social agent registration with access / data grants using that public agent as grantee.
* Laurens - so this could be an alternative to public type indexes for discovery
* Pavlik: yes - so applications can do this and no need for alternative path for public data
* Laurens: This solution was motivated by one idea where an application makes resources public. If you bring everything together in this public agent registry than you miss that an agent expressed it in access needs. WHat if you want to revoke something an application did. You might need an additional attribute to express it. ... Nice aspect of the spec is being able to review data grants you've been given and trace.
* Pavlik: I think you should be able to trace it, or possibly have a separate data grant issued. On a consent level you could record something.
* Justin: I like Pavlik's suggestion a lot, we are reusing already established patterns. I think that Laurens brings a good point about tracebility. We could look separately at access that the application has vs access that the public has.
* ...: I need ability to read and write the shape trees. That's the access user would give to the application. But also giving to the public different access. I think about two different access need groups. The public one could be treated as public social agent. We probably can maintain a little bit of history.
* ...: From public grant one shouldn't know why is there (who requested publishing it). But data owner should have a way to trace it.
* Pavlik: Could look at handling this as complementary approach to a delegation chain (e.g. application requests access for the public). I could ask ACME to give some access to Justin, so the grantee and requesting party could be different.
* Laurens: I see what you're getting at - would need to try out some snippets to see what works. Good to think of it like asking for access on behalf of someone else. Good point to keep in mind that public shouldn't know what was asked for it. Will work something out and present it in next week's session.

### Feedback

* Pavlik: can we can feedback on priorities?
* Juliette: I don't think our work needs to influence what you're doing.
* ... working on a POD-powerered "BBC-Together"; allows folks to create watch parties and share links.
* ... want to add privacy-protecting features to that.
* ... joint recommendations based on joint media history
* ... we've developed a simplified way of doing that because we're hoping to publish in the next few months.
* ... after we've done that, we can step back and look at generic tooling based on SAI.
* ... no immediate feedback
* Pavlik: what ShapeTrees and Shapes are you using and how do they fit into data registration and possibly inherited data grants
* Juliette: we're not using ShapeTrees. For Shapes, we have WatchParties and Participants. We're making history timelines.
* ... There will be Messaging, Playlists and Contacts. We have a MasterResource held by the Host. Other folks can subscribe to the MasterResource. Challening to see how folks can access.
* ... Participants can send e.g. name change to the Host.
* ... All docs internal for now. Interesting to see whether we want to publish shapes. We might not want to publish WatchParties but might want to re-use existing Messages.
* Pavlik: I think if you plan to support independently developed application publishing all it would be useful. On the other hand if you aim at more closed environment where only you develop apps it wouldn't bee needec.
* ... The way we're using it, we're not allowing other folks to create WatchParties. We're more interested in the messaging than creating interfaces for other folks to use.

### Publishing FPWD

* Pavlik: we could use bikeshed for SAI Primer and Auth-agent Primer. Justin and Eric may have opinions about ShapeTree docs.
* ... Do we want WAC as a normative ref?
* ... Do we want to inline issues to which we want to draw attention?
* ... We should be able to publish FPWD by mid-April
* Justin: We shouldn't be held up by versioning discussions wrt the main spec.
* ... Each ancillary spec needs independent versioning and evolution.
* ... So we shouldn't be hampered about what to stamp on each version.
* ... +1 to reviewing issues for inlining in spec.
* ... bikeshed's really useful for linking to GitHub issues.
* ... +1 to reviewing normative refs
* ... We needs links to/table of implementations
* ... We should consider and potentially act on breaking the specs up along e.g. auth boundaries or data storage boundaries.
* ... I'm personally not motivated but we should have the dialog and document decisions.
* Pavlik: We consider this a FWPD so I don't think we need implementations, but should be in README.
* ... I think the doc all works together so I think we don't want to split it.
* ... For the next iteration, we should look at deps on e.g. OIDC; instead have an abstract requirement for auth that gives us client ID and app ID.
* ... Solid could compose the specs but these specs shouldn't be tightly coupled.
* Laurens: +1 to loose coupling of spec. Discussed this with Reuben Verborgh; he's convinced that the spec should be split up but I see lots of interconnections. Reuben has a hard time understanding what the spec tries to accomplish; sees 3 or 4 things.
* Pavlik: can we get him to join to discuss how to split the spec up? The spec has very coherent approach tying together discovery based on authorization based on data layout.
* Laurens: +1. He has a [regular] conflicting meeting. We can ask if he can join some time over the next couple weeks.
* Justin: It would be good to propose how we can define boundries and what abstraction has to be introduced. There is a risk of architecting ourselves into obscurity. I've build systems in the past that you get so deep into abstraction that it can be hard to figure out what the system is supposed to be doing.
* ...: SAI provides a cohesive framework to make applications.

ACTION: Pavlik to make PR with inline issues in the spec