Address legal compliance, security, and privacy through Specifications

[coolharsh55]

Hi. An adopter or user of Solid faces the following three questions:

1. How to describe what their implementation and use-case is regarding use of 'Solid' ?
2. How does Solid relate to relevant laws (in my case, GDPR)?
3. What issues or problems are applicable to Solid?

I have answered this through an article titled "Making Sense of Solid for Data Governance and GDPR" https://osf.io/m29hn/ that considers use of Solid as cloud technology which gives different possible governance models (e.g. self-hosted, pod from providers), which enables specific analysis of how Solid specifications in their current state relate to GDPR (because I focus on EU, but the issues are also broadly applicable). I found that there are important gaps and incompatibilities that result in problems and uncertainties for an adopter. These arise from specifications not containing information, processes, diverging in terminologies, etc. I also discuss how Solid is vulnerable to existing problematic practices in centralised models (e.g. see solid/authorization-panel#46 (comment) and article Section.7).

While is it possible that an adopter or end-user is also aware of the above problems, and implements solutions to fix them, IMHO this will eventually create divergence in Solid implementations, and thus challenges for portability and interoperability of data, pods, and apps. If there will be different incompatible approaches to solve common problems, we may end up with new centralised or walled models that use Solid - which would be self-defeating for Solid's goals.

Instead, IMO, Solid specifications should provide a solid (pun intended) framework that assists if not solves these issues related to legal compliance, security, privacy, and data protection, and through this provides a minimum level of trust and commonality in the use of Solid across implementations and use-cases. The article provides some ideas for this (Section.8), and there are other issues that relate to this - solid/vocab#83 (vocab for actors), solid/data-interoperability-panel/issues/282 (separation of Agents), and solid/authorization-panel/issues/46 (trusting an app).

I'm not the first to consider the legal or privacy perspectives of Solid (the article has some good references), and I won't be the last - for example the EU's authorities are looking into Solid as part of the next potential innovative disruption (ref:EDPS). I'm also aware that there have been several discussions within Solid community (e.g. consent, use of policies) - but as there are no visible outputs and Solid is being considered for a W3C WG track, I'm requesting this be considered an important topic and the Solid community should either (1) agree that the above is an issue that needs attention; or (2) make it explicit in the specs or docs that the above is not in scope - and therefore clarify that either implementers should develop their own solutions or the community can do so as an extension or additional specification.

[tomhgmns]

Hi Harsh,

This is indeed an important issue.

With use.id we go with the agile principle: first start with something what is already known and make sure it works. Then, we will move towards something more innovative.

Currently, we have implemented an access request procedure (see https://docs.use.id/docs/sharing-data-with-others-at-my-move). In this procedure, we ask for an policy_uri and/or a tos_uri to which the user should agree before any data is shared. For now, this suffices.

In the future, we intend to improve this screen and underlying terminology, but for now, it works.

This is also how I believe the spec should be improved: let's start with an MVP that standardises the most basic functionality and then think about how to improve it (and thus add complexity).

[coolharsh55]

Hi Tom. Thanks for sharing your use-case. I like it, and I think its a pragmatic approach to take within implementations - though I also note the docs don't provide the vocabulary directly.

My hope is that the structure required to do such implementations is baked within Solid, so tasks like yours get much easier and everyone benefits. To take your specific examples, the policy URLs along with all the important (or rather: necessary) 'metadata' should be a vocabulary defined through Solid specs along with what should be checked for an App to be trusted to even begin the request process e.g. using DPV (as a biased recommendation). Otherwise Apps for Digita's implementation have to do one thing, My implementation another thing, and so on. Leaving it for later would be a detrimental step IMHO.

[tomhgmns]

Indeed, we are eagerly awaiting the standardisation of the functionality of our access request procedure. This involves standardising the requests, adopting a vocabulary to say what app has access to what data, adopting a vocabulary to store legal considerations, ...

I notice that DPV seems to be already pretty mature (just like other vocabularies to capture legal aspects such as ORDL, ...).

Because of this, we are currently directing our efforts to the other parts that I've just mentioned.

Thus, in conclusion, I agree that legal aspects should be taken into account. I think that there are currently more important aspects that need to be standardised than the legal ones. Be that as it may, when we would work on the standardisation of those legal aspects, I assume it will be relatively straightforward because of the work done in the past by people like yourself :-).

[coolharsh55]

Thanks Tom. As the first step to getting there, I'm trying to start the conversation towards eventual consensus (if not standardisation) on using vocabularies to help with legal tasks and implementations. I understand the preference to first standardise technical aspects, but leaving legal/ethical stuff out for 'later' might end up being a PITA later on because implementations might already have divergent approaches or worse. So IMHO even if we don't end up 'standardising' the legal/ethical stuff, it should be part of consideration for the technical stuff being standardised.

[tomhgmns]

Hi Harsh, just as an fyi, with use.id, we are currently looking into DPV. To the best of my knowledge, this seems to be most appropriate and useable one :-).

[coolharsh55]

Thanks Tom. I think it applies itself well to Solid, even if there's some terms and key pieces missing that we can work to add. Let me know how I/we can help. Documentation is sparse, but I'm trying to add examples and guides.