---
# System prepended metadata

title: Solid Application Interoperability

---

# Solid Application Interoperability

May 4th, 2021

## Present

- Justin B
- Hannes R
- Eric P
- elf Pavlik
- Ben G
- Jamie F


## Agenda

- Announcements
- Issues
    - [#99 - Why requirements on resource names](https://github.com/solid/data-interoperability-panel/issues/99)
    - [#105 - Consider adding organization as an Actor](https://github.com/solid/data-interoperability-panel/issues/105)
    - [#100 - Access Grants should support limited control scenarios](https://github.com/solid/data-interoperability-panel/issues/100)
    - Suggestions for TS implementation. For example priority of features.

## Minutes

### [#99 - Why requirements on resource names](https://github.com/solid/data-interoperability-panel/issues/99)

JB: Rationale - don't want people to have to pick names themselves. don't want interoperating applications to collide with each other. don't want to leak semantics of the resource. maybe just need to provide requirements instead of saying explicitly it must be UUID.

EP: +1 providing requirements might be fine

PAVLIK: document the reasoning, can remove the must on UUID and include requirements

EP: Say that system doesn't depend on this name. We will use UUIDs in our examples, but not required as long as it meets reqs.

JB: +1 - Action item - respond to KK in ticket / adjust language in the spec.

### [#105 - Consider adding organization as an Actor](https://github.com/solid/data-interoperability-panel/issues/105)

JB: Nice simplicity in having Agents and Applications, but there is likely to be value in having Organizations as something distinct.

PAVLIK: 

EP: If we invent an Organization that subclasses Agent, maybe we should come up with some name for non-org Agents so we don't have the same PITA in LDP where there's no way to say something is a non-Container Resource

EP: Needs use cases / reqs

Action item: include use cases

### #100 - Access Grants should support limited control scenarios

PAVLIK: Which authorization agent should be used when someone with limited control shares with someone else? 

EP: Should be able to use yours

PAVLIK: +1

PAVLIK: Someone with limited control would be sharing from their remote data registry. Need workflow for that.

JB: Yes +1. That will need to be added as part of the resolution for this issue.

PAVLIK: Maybe they don't have to write directly to the Access Grant Registry. Could potentially send a notification as well? (e.g. send an Access Receipt)
- JB: This is a really nice approach, because it doesn't require any direct writes to access grants from non-trusted agents. This may be the way to go.

EP: Probably worth annotating what we can and cannot be confident of in terms of expectations and places where you have to look out for non-conformance.

ACTION ITEM: JB to document receipt delivery in the ticket, and update in the spec.


