---
# System prepended metadata

title: Solid Interoperability Panel

---

# Solid Interoperability Panel
June 15, 2020

## Attendees

* Justin B
* Josh C
* e Pavlik
* Eric P

## Agenda
1. Issue Review:
    * [#50](https://github.com/solid/data-interoperability-panel/issues/50) - Align on terminology re: attended / unattended, etc.
    * [#48](https://github.com/solid/data-interoperability-panel/issues/48) - Align on encoding scheme for Application registry container
    * [#45](https://github.com/solid/data-interoperability-panel/issues/45) - Update on Solid Ecosystem vocabulary progress and usage of Type hierarcy (See https://github.com/solid/data-interoperability-panel/tree/ecosystem-rdf-types)
1. ShapeTrees.js update from Eric

## Minutes

[#50](https://github.com/solid/data-interoperability-panel/issues/50) - Align on terminology re: attended / unattended, etc.

JB: @pavlik - is a use case something like a traditional web-app (like php) where user is logged into it and application is accessing pod directly?

EP: Yes that is correct

JB: In ecosystem proposal client identification section we talk about strongly identifiable and weakly identifiable clients, but in later places we may use user-piloted as though they are all weakly-identifiable, so its true we need to fix those points.

EP: Not convinced that applications should authenticate as themselves, but instead use a more traditional oauth2 delegation model.

EP: Consider "who" the user is ultimately sharing their data with

JB: If the scope was only "organization" but an organization had two very different services they operated it could lead to users sharing broadly across those services

EP: Lets get use cases added

JB: Agree on use cases. I think it doesn't have to be one or the other.

### [#48](https://github.com/solid/data-interoperability-panel/issues/48) - Align on encoding scheme for Application registry container

 - Justin: Main point of the encoding is to have reasonable resource names that can be autogenerated based on the application id. It is a nice benefit in using the hash to make them harder to enumerate without effort, but you have to assume someone will maintain a fast hash lookup somewhere at some point. 
 - Pavlik: I would find it useful to add note that it only serves esthetic purpose for nicer URIs and doesn't try to act as security measure.
 - Justin: Good feedback - will point that out in the text

### [#49](https://github.com/solid/data-interoperability-panel/issues/49) - Rely on client's public key rather than hashed client's url

- Justin points out that this use case is only related to the resource controller providing the applications they use with a place to store data. 
- Pavlik - was conflating the use case with broader data authorization - will close out ticket.

### [#45] - (https://github.com/solid/data-interoperability-panel/issues/45) RDF Types for ecosystem registries

- Justin provides a quick tour through work in progress to address feedback at https://github.com/solid/data-interoperability-panel/tree/ecosystem-rdf-types, including ecosystem vocabulary and how it's being applied to existing data
- Will be completed ahead of next week's session. Pull request coming soon.

