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