TODO: make a list of points on which this spec is unclear
michielbdejong opened this issue · 11 comments
As part of the transition process to the 1.0 format, let's make a list of issues on which the spec is currently not saying anything, but we feel it should say something.
To start off, I'm aware of the following ones:
Added this to the agenda for this week's call.
Defining who controls what data. Examples of where confusion may occur include:
- derivative data such as recommendations generated as a result of combining data produced while using an app with external data lists e.g. my playlist with playlists of others
- data generated by an employee using an app at work e.g. documentation written by an employee for a project proposal of a company
- groups without a formal legal structure who want to do different things with the data collected. For example, a group of footballers who collect data on training times, half of which want to take the data to a fitness app, the other half do not - who has the final word on data control decisions?
- data of a baby or a child who is below the age of consent. In particular when the child wants to join an app that the parent is not wanting the child to join
- data of the deceased. (What if the next of kin have differing opinions?)
IMHO those are all very good questions, but way too high-level for this spec to answer. We could add a note in the introduction that this spec doesn't currently solve those high-level issues. I moved them into a separate discussion issue ^
I think of the 5 issues mentioned, only #167 is still undecided, and I'm not aware of any other points on which the spec is currently unclear. So as soon as we make a decision on websockets-pubsub auth tickets, @RubenVerborgh et al. can start their proposed project "[t]o combine information from the solid-spec, web-access-control-spec, and the webid-oidc-spec into the specification repository using the W3C specification template to create Solid specification v0.8."
Status update:
- webid-oidc client_id's -> @jaxoncreed I reviewed your PR, can you have a look?
- WAC-Allow headers -> I requested a review from @dmitrizagidulin
- WebSockets-pubsubs access control -> I requested a review from @acoburn and @Vinnl
- deleting non-empty containers -> @fabiancook and I still disagree on this one
- trailing slashes in ACL docs -> improved to mentioning exact URLs, and merged.
New ones (these are all pretty small):
- clarify status of trustedApps system
- clarify status of other WAC spec versions
- recursiveness of websockets-pubsub subscriptions -> I requested input from @acoburn and @Vinnl
- support for relative URLs in websockets-pubsub
subandpubmessages -> I requested a review from @acoburn and @Vinnl - webid-oidc link header discovery
- clarify meaning of container write permissions
We still have disagreement from @fabiancook and @RubenVerborgh on container-deletion (first about recursiveness, second about required ACL mode)
During today's meeting, as I was explaining the clarification project, it occurred to me that probably what Solid app developers rely on is not so much this spec's text, or even the intentions that the Solid protocol authors had at the time, but mostly getting their app to work with real-world pod servers. And both big pod providers run NSS, so I think in almost all cases we should just write down what NSS does.
This means I'm also changing my stance on the deletion ACL question, and will agree with Ruben that the spec should state that creating or deleting a resource requires write permissions on both that resource's URL and on its immediate container. Updating an existing resource without deleting it requires write permissions only on that resource itself (not on its immediate container). But I'll stick to 'deleting a non-empty container should fail', since that's very clearly what NSS implements now.
@fabiancook you weren't in the weekly call just now (this week was the Asia-Europe time); shall we chat about this more in the solid/solid-spec gitter channel?
The spec, afaik, does not currently take into account other facets including but not limited to;
- Verifiable Claims / Credentials
- DLTs
formative works imho incorporate http://dig.csail.mit.edu/2010/Papers/IAB-privacy/httpa.pdf | https://news.mit.edu/2014/whos-using-your-data-httpa-0613 whereby the provenance of facts, as required for what i'd call a 'reality machine' (as apposed to a 'reality distortion' machine) requires the means to deal with 'append' functions, incorporating support for 'permissive commons' (meaning, a judge may be privy to all the facts of a matter, whereas a github issues ticket and the SEO functions of it, may not) that in-turn support various important societal functions that a simple 'delete' or 'modify' ACL notation; may not act, to serve; in a social web environment.
The title of this ticket is unclear and seemingly unexacting. perhaps better specification may improve rationale towards a meaningful resolution...?
I think therein; the utility of non-native HTTP protocol solutions, as part of the solid ecosystem (ie: inclusive to WebDav, WebDHT, Web-Ledger, etc.) is important in considering a resolution that'll aid with 'digital identity' integration sub-considerations.
@michielbdejong - Lets transfer this list over to https://github.com/solid/specification/issues for the 1.0 prep?
@dmitrizagidulin sure, go ahead! It will definitely be a useful checklist for things that the 1.0 spec should clarify unambiguously.
Personally, I use inrupt/pod-server#15 as the authoritative up to date reference for what I mean when I talk about the "roughly 0.8 spec".