An extension that abstracts away the complexities of permissioning for resource sharing between users and apps.

[Sindhu-Vasireddy]

Pitch

The user will not want to be burdened with having to express their complex access control preferences such as time-limited access and access to specific data segments using reasoning rules. The proposal is to build an extension on the server-side that enables this kind of permissioning by abstracting away the specific reasoning implementation from the user.

This challenge is to answer these 2 questions, mainly:

1. How do we give access to only a selected segment of an RDF resource stored on our pod?

   • Stages in which it works: a) We need to have a pop-up UI that translates the RDF resource in question into a user friendly format and the user can then select what segments(based on the subject and their properties) they want to give access to, b) The selected segment can then probably be translated into preference rules, c) We then mention modes of access on these rules using reasoning(based on this), and d) Our extension-service enforces these policy rules by interfacing with the eye reasoner in the case of reasoning based permissioning.

2. How do we selectively allow an app access to resources put by another app? a) We are logged into app A(fitness app that shows my activity in the past week) using our Webid and we want it to have access to a portion of the data put by app B(the past week's raw location data excluding certain readings that we want to keep private). b) Our extension checks if the app A is already registered in the log by its app ID and if the access to the data, it is currently requesting, has already been granted. If not then the user will be redirected by our extension to the pod where a notification from app A requesting app B's data is waiting to be addressed. c) The user clicks on it and a UI pops up on top of the resources of app B in the pod for the user to select the segments(using the feature described in 1.) they want made visible to app A along with what modes of access they want to enable and the duration for which they want these resources made available. d) The selections made are then translated into our policy preference rules and enforced by our extension. e) The user is then returned to app A and now app A has the access to the data of app B as enabled by the user.

Ideal Policy Rules would:

1. Serve as an event log as well as a rules-based access control specification.
2. Enable access control across users and apps used by a user.

Desired solution

• An extension that can direct the user to a UI on top of the resources on the pod and once they have made their selection of resources that they want to give access to, redirect them back to the app they were using.
• The extension must be able to translate the UI selection to declarative rules that will reside on the pod which it will use to enforce the access control as imposed by the user.

Acceptance criteria

• An extension that the user can download that has been given the authority to work conjointly with the server to manage its resources and handle resource permissioning and sharing.
• A specific use-case would be:
  • App A can request our extension for App B's lat-long data for the last week of the user from the pod.
  • Our extension checks if App A is registered with relevant permissions to access this data.
  • If yes, it is shared based on existing policy preference rules.
  • Else, it prompts the user with requested permissions by App A and redirects them to the pod.
  • User then decides the segment of data and the duration of permission(say, 1 month) to be granted to App A through our UI.
  • Extension then grants the data access to App A, registers it for future requests.
  • Finally, the extension shares the requested data back to App A.

Pointers

The proposal is for the extension to be built on the reasoning-based permissioning enabled by this challenge

The extension can also be used to create a declarative policy log that serves as an events source of past access. For reference:

• https://docs.inrupt.com/ess/latest/security/auditing/

Policies with reasoning:

• https://github.com/phochste/Notation3-By-Example/tree/main/log/blogic/policy
• https://github.com/Dexagod/solid-query-policy-surfaces

Creating location data:

• https://github.com/SolidLabResearch/Challenges/issues/10
• https://github.com/woutslabbinck/SolidEventSourcing

Scenarios

This challenge can be applied to these scenarios:

• https://github.com/SolidLabResearch/Challenges/issues/73
• https://github.com/SolidLabResearch/Challenges/issues/57

[pheyvaer]

I changed this to a scenario, because it requires to tackle different issues such as (temporary) permissions, browser extensions and apps that work with both these things.