---
tags:
- Solid
---
# Implementer Feedback Session

## Justin Introduction

- Extremely tight on time, this will be tightly moderated, important to get as much feedback as possible
- Only those on the agenda will be queued to speak, and only during the allotted time. Editors may ask for clarification after each block. Clarifying questions should be queued for efficiency, and may be taken offline due to time constraints.
- Primary role of the editors today is to listen to you, and learn which features or issues are important.
- Consequently, having a good record is paramount. Scribes will do our best to keep up, but we'll also ask that the implementers help us to review the minutes afterwards and make sure they are an accurate reflection of what was reported.
- Also we're learning the best way to structure sessions like this, so we'd really love to know what you thought of this format, or how we could optimize it moving forward.

## JD Topics

### Justin

- Quick summary - our software integrates existing applications and services with solid pods, so that data can flow freely without requiring them to change anything in their stack. We're not exclusive to healthcare, but we've spent a lot of time focusing in that vertical. We've demonstrated the use of pods with real patients at the NHS, and are currently working with them on subsequent, larger-scale phases.

- Limitations of access control
- Lack of app authorization, despite solid-oidc providing client identifiers. Origin-based is a non-starter.
- Deficiency in WAC inheritance - giving Sue access to Photos/photo1 breaks Bob's access granted to Photos/*
- Inability to factor in graph relationships - grant Sue access to photo1 because it's referenced by a shared vacation album}
- Granularity of access modes
- Authorization by verifiable credentials - especially to be able to provide membership in a given group

- Focused attention on real-world interoperability problems
- Consent patterns that maintain principle of least privilege (e.g. application interoperability specification). Hard requirements for us.
- Lack of attention to server-side data validation

- Standard pattern for data integrity (distinct from data quality)
- Verifiable credentials as auxiliary resources

### JAMIE

- Support for notifications on data change. Knowing when specific data changes rather than polling for it is essential to a number of workflows and patterns.

- Pagination is going to become more and more important as data (Container size) scales up.

- When updating multiple "related resources", failing in the middle can provide inconsistent state. Patterns to provide even simple or crude forms of transaction are becoming important.

- Support for DID (at least did:web) - Functionally equivalent to WebID - DIDs are coming up often in the field from customers. Despite the hangups in W3C recommendation, it seems the masses are already starting to vote with their feet.

- Standard interface for pod provisioning. We support two servers at the moment (ESS, community-server). We have to provide custom code for pod provisioning for each server implementation.