Why should I trust an app? about authorization-panel HOT 6 OPEN

Hi. I agree that there are two forms of "trust" here - one related to security which relate to certificate, etc. and the other about humans which relate to how and why the app is using their data. For the second one, I am of the strong opinion that users should be able to express their own policies (or reuse from community) about how they want to let others use their data, and that such policies should be used to assist them in making decisions and reducing the ability of apps/companies to manipulate and take advantage of people.

For example, certain things that such (machine-readable) policies can help flag or provide additional contextual information when apps request access to make a better informed decision:

1. Use of sensitive data categories
2. Sharing with an absurdly large number of other third parties
3. Asking access for too much data at once
4. Explanations for why data needed as being vague
5. Having to read stupidly large "privacy policies" and "terms and conditions" without actually understanding anything
6. Not understanding the request and how it will impact them
7. Not understanding who is the entity or company behind the app
8. Identifying when the community has identified an app or an app provider being malicious
9. Ensuring the "consent" is appropriate to context, for example, not allowing one click to give access to all of data at once
10. Having an indication of a 'risk score' associated with the request - e.g. access to contacts for address books is low risk, access to medical records from a non-health entity is extremely high risk.

In order to enable this, both the app request and the user/community preference or guides need to be in machine-readable forms so that the agent can interpret and use them. Otherwise there is a strong likelihood to continue the current malpractices where users get a notice that only provides a link to a website T&C that they either don't read or don't fully understand, and end up giving access to do something with their data they had not anticipated or intended.

from authorization-panel.

Yes, but that is still just the technical aspect. A random user would not have much to go on to formulate those policies. Dedicated Authorization Servers could serve as a centralization point. I think we need to be much more elaborate in involving the social fabric of the ecosystem, the humans, not the machines.

from authorization-panel.

Having to read stupidly large "privacy policies" and "terms and conditions" without actually understanding anything

IMO we should collaborate with community-driven services like https://tosdr.org/ to address this specific problem.

from authorization-panel.

Currently, at use.id we're using the OIDC Dynamic Client Registration metadata values policy_uri (policies) and tos_uri (terms of service) to provide users with links to those documents. Towards the future, we aim to implement something like the ODRL vocabulary, combined with DPV or gConsent (like described #55). This legal consent information could possibly be embedded within SAI Data Grants (like described here). There already exists a specification combining ODRL with DPV specifically for Solid. In the end, this should enable both the user and the application to express legal conditions that are also machine-readable, and which can therefore be displayed in a structure manner, and even programatically compared.

from authorization-panel.

Hi. I have written up an article titled "Making Sense of Solid for Data Governance and GDPR" https://osf.io/m29hn/ that analyses how Solid in its current state relates to GDPR's requirements, what are some of the possible governance models (for Pods and Apps), and some issues that are known to be problematic also apply to Solid. The aim is to emphasise the necessity and importance of answering (through developments) the question this issue has raised. The article also explores some specific ideas for improving things (Section 8).

from authorization-panel.

Both user and resource associated Authorization Servers #43 could let users configure some kind of 'trust policies'. For example app that have specific certifications, published by specific entities etc.
This would affect Consent Screen when user gives app authorizations. It would show if app meets or doesn't meet those polices. IMO even stronger case to have dedicated Authorization Servers which would take all the responsibilities related to authorizing apps, revoking authorizations #24 etc.

from authorization-panel.