authorization-panel icon indicating copy to clipboard operation
authorization-panel copied to clipboard

input from Jackson

Open michielbdejong opened this issue 5 years ago • 2 comments

https://docs.google.com/document/d/1Gi23auEvq2g35D9yED4KABtiufBHLyBElzShnRJFKLU/edit

michielbdejong avatar Aug 01 '19 15:08 michielbdejong

Application Authorization Panel

This document outlines the scope for a panel to be formed around application authorization. Problem

Currently, web access control requires a user to manually set access to each file. There should be a method for third party applications to inform pod owners how what data they would like to access even if the contents of the pod are unknown to the third party application.

Problem Example

Alice has multiple chats on her pod already, and hears about an awesome new chat app that she thinks will greatly improve her chatting experience at https://coolchat.example. She wishes for all her chats to be shared with the app, but does not want any of her other data to be shared.

Currently to do this, she must either manually go through each file and set the acl:origin permissions for just the chat/message files (A task that cannot be expected of a normal user) or grant access to all files (An insecure action).

Scope

The standards defined by this panel should encompass a comprehensive solution for the following use cases while keeping in mind the possibility of using the systems designed for other use cases (ie interoperability):

  • A web application with an origin requests access to the app user’s data
  • An app without an origin (ex mobile app) requests access
  • An autonomous application with a webId requests access
  • An autonomous application without a webId requests access

Once this standard is implemented all third party applications should be able to communicate their desired data so that they can get access to the data they need without data leakage.

Deliverables

The panel will deliver a new spec of a standard tentatively called “Solid Application Authorization.” The main question it will answer is “How do applications communicate the data and access it wants/needs to function without first having access to the Pod?” There may also be modifications to other spec / additional specs created if features required for Application Authorization are usable outside this domain. The spec should answer the following questions (though these questions are subject to change at any time):

  • What level of flexibility is apt for UI implementations?
  • How do third parties communicate the kind of data they want to a pod without allowing it to see data on the pod?
  • Are additional access control tools required beyond .acl?
  • Should access control be more fine grained than just files (ex. Shape ACL)
  • What implementation will maintain the speed of the operations (Read, write, delete, etc.) while providing many of the new desired features. What level of performance hit is acceptable?
  • How is new data that does not already have access control rules automatically labeled if at all?
  • What is the data model to keep track of registered apps?

jaxoncreed avatar Aug 01 '19 15:08 jaxoncreed

A web application with an origin requests access to the app user’s data

does this cover access to data in any Resource Server to which the user could have access (or perhaps just data for which the user might have acl:Control permission with some other app or maintenance UI), or specifically to data in the user's Pod? and for the latter case, while WAC doesn't have a notion of "owner", i think a Pod should definitely have the notion of an owner (especially so that the owner can't permanently lock herself out of her own data).

i think that if the scope of the problem is constrained to "the user wants to grant and control access for apps to the user's data on the user's Pod, where the user owns the Pod vs just an acl:Control situation", the problem becomes significantly more tractable.

An app without an origin (ex mobile app) requests access

for OIDC at least and some of the auth+app-id proposals that have been made, it's possible for a non-browser app to have an app id of some sort.

An autonomous application with a webId requests access

is this the same or different from "some other user with a webid using some app requests access"?

An autonomous application without a webId requests access

is this the same or different from "a non-authenticated user (foaf:Agent) wants access, using some app or even just curl"?

zenomt avatar Aug 03 '19 22:08 zenomt