Draft idea: granular access scopes with RequestSet

michielbdejong commented 5 years ago

I remember seeing conversations in the past about using OAuth2, but I couldn't find them now, so creating this issue about it now (but please feel free to mark this as a duplicate of an older issue if it exists).

As an alternative to our current webid-oidc flow, maybe we could use OAuth2 similar to how remoteStorage does it. But in a more follow-your-nose kind of way, because we don't want to specify which container names people should put in the root of their storage, and also sometimes the data you want to access with your WebID is not actually on your storage, but somewhere else, for instance on the pod of another Solid user.

An easy case is where the app wants to access a single resource, they can just request an OAuth scope made up of the resource URL followed by : and an r, w, a, and/or c, depending on whether they want read, write, append, and/or control access.

An app could also include a list of such scopes, as long as that list doesn't become too long. The user could then grant/disallow each of those scopes individually in the consent dialog.

The above would be the base mechanism. An extra mechanism on top of this would be to request a scope like https://example.com/#:s (s for set), which means retrieve https://example.com/ and find triples like:

@prefix acl: <https://www.w3.org/ns/auth/acl>.

<https://example.com/#>
  a acl:RequestSet;
  acl:RequestSetContains <https://example.com/#1>.

<https://example.com/#1>
  acl:accessTo <https://storage.com/foo/bar>;
  acl:mode [ acl:Read acl:Append ].

So that would be an RDF document describing a set of access requests. A resource could be included with different access modes in different access request sets. The hope would be that a user could have an access request set like 'chat conversations', and chat apps that create new chats would also add those new documents in there, a bit like the private type index, but linked to access scoping considerations, rather than to RDF type considerations.

Footnote about the relation between write and append access: write access implies append access, so when requesting write access it's useless to also request append access.

michielbdejong commented 5 years ago

@jaxoncreed I think acl:RequestSet is the same as what you call an Authorisation Tag, right?

jaxoncreed commented 5 years ago

No, it's not the same thing. An authorization tag is some metadata for a file to help keep track of how important data is. For example, you might want to have extra warnings if an app requests your medical data, so it would be tagged as sensitive

jaxoncreed commented 5 years ago

Here are some of my ideas: https://docs.google.com/document/d/1Qx5Qs0hOKjsl5kbd0i7XNr6NG3pHY3NjubN6SrPJZZQ/edit?usp=sharing

kjetilk commented 5 years ago

Although I have a bunch of hard use cases in my head, there are mainly an architectural constraint that is on my mind, as a general thought:

Since the WAC happens for every request, and it is a relatively costly operation, it must be carefully designed for performance. As long as the ACL can be cached trivially, it can be close to the checker, and we should be fine, but I would be concerned about any mechanism that makes data hard to cache, either by it being too hard to predict what resources are needed, it being too voluminous, they change too often (possibly for other reasons than the WAC-relevant parts), it requires a lot of computation to find the right resource, it depends critically on the client (i.e. all clients require different ACLs), etc.

So, just as a general comment, please consider how resources can be cached when designing the system.

RubenVerborgh commented 5 years ago

Just want to mention here that the most general case is proof-carrying authorization (as in the diagram). The client there then proves that they have the right to perform the action.

Everything we do is to be seen as a special case of this. For example:

The current system is an identity-based proof: "I am X, and X is on the ACL, so give me access"
I have the rights to perform this RequestSet.
I can make modifications of this shape.

At some point, we might want to start approaching it from the top down (= proofs) as opposed to from the bottom up (= various solutions). That said, I strongly believe in shapes also for this use case.

But as usual, let's start with requirements engineering before starting from solutions. What is it exactly that we want to do?

jaxoncreed commented 5 years ago

@RubenVerborgh I guess my initial requirements wish list would be, a solution must:

Be flexible enough to accommodate a wide array of UI implementations (because this is a UX problem and we shouldn't constrain the world to one)
All read, write, append, delete operations should be quick and work with cached data, however, operations around .acl modifications can be a bit slower
Allow new data to automatically have access control configured based on something having to do with past history or rules set
Provide a standard for third parties to communicate the kind of data they want with the pod

michielbdejong commented 5 years ago

Another idea @dmitrizagidulin and @jaxoncreed just discussed:

in ACL docs, add acl:scope triples, for instance <#authorization> acl:scope scopes:chat, meaning that if an app has access to the chat scope, it can access the resource, regardless of its origin.
when adding a trustedApps to your profile, include not only acl:mode but also acl:accessToScope triples, for instance <#app> acl:accessToScope scopes:chat.
maybe have a special way to give a trusted app access to all scopes, to keep the current trustedApp system behaviour.

So then there will be three ways to access a resource from a web app:

have your origin mentioned with acl:origin in the ACL
be a trustedApp with access to all scopes
be a trustedApp with access to a scope that is mentioned in the ACL.

namedgraph commented 5 years ago

Once again, please do not use acl: namespace for terms that do not belong in the W3C ACL ontology. That includes terms acl:trustedApp, acl:RequestSet, acl:scope, acl:accessToScope etc. Please use a different namespace and namespace prefix.

michielbdejong commented 5 years ago

Sure we can move around the namespaces if we think that's useful, but then we would first need to define what you mean by 'belong'. :) Should we have one namespace for describing access modes, one for scopes, one for human agents, one for software agents, and one for web apps that humans use? Or would you put them in two groups? Or would it be simpler if we just put all access control related terms into one namespace, to avoid splintering and duplication?

namedgraph commented 5 years ago

http://www.w3.org/ns/auth/acl# is the one and only W3C ACL namespace, and you can look up what terms it provides. They include established and widely used terms such as Authorization, access(ToClass), agent(Class) etc. That is fine and should not change.

What you are discussing above are Solid-specific and not widely agreed-upon terms (e.g. RequestSet). The way to go is to put into a Solid-specific ACL ontology (e.g. under https://solid.inrupt.com/ns/acl#) which then owl:imports <http://www.w3.org/ns/auth/acl#>.

RubenVerborgh commented 5 years ago

http://www.w3.org/ns/auth/acl# is the one and only W3C ACL namespace

It has no official W3C standing whatsoever; see note at https://www.w3.org/wiki/WebAccessControl. As far as I know, it's not more official than Tim's personal documents like https://www.w3.org/ns/ui and https://www.w3.org/ns/footprints.

The way to go is to put into a Solid-specific ACL ontology

Not necessarily, but I understand the concern.

First point would be identifying the current status and maintainers of http://www.w3.org/ns/auth/acl#

solid / solid-spec

Draft idea: granular access scopes with RequestSet #176