Create a Generalizable baseline for interop

[jaxoncreed]

Hair-Brained Scheme for Data Interop

The Problem

• A few different ways to do discovery and access control are proposed
  • By Filesystem organization (.acl)
  • By Shex Shape
  • By Shacl Shape
  • By Tags
  • Even more could be proposed
• Each of these techniques covers a certain use case but doesn't encapsulate every use case
• Therefore, we either
  • Choose a small subset of these solutions, limiting the use cases for discovery and access control that are achievable
  • Decide to implement all of them and more, adding implementation overhead to all resource servers
  • Allow resource servers to choose what kind of system they use for discovery, offloading the complexity on the client
  • Something else :smirk:

Solution Summary

• There should be one general way to define access control and discovery that MUST be implemented by all servers
• All other possible techniques for data discovery and access control should be implementable in this general solution
• The efficiency of UI friendliness of this general solution does not matter.
• Servers can choose to opt in to implement as many additional interop standards (shex, acl, etc) as long as they can be reduced to the general standard.
• If a client uses an interop standard that the server doesn't understand (for example Shex), the client will be able to reduce its request to the general standard as a failsafe.

Implementation Summary

• SPQARQL CONSTRUCT queries can describe almost any kind of access control/discovery standard conceivable.
  • A CONSTRUCT query is a way of building a sub-graph given a graph
  • While it may be verbose and inefficient, you'll be able to translate most concepts for interop into a CONSTRUCT query
  • One drawback: not ALL use cases are satisfied as SPARQL is not a Turing complete query language
    • This may be positive because if it were Turing complete, it would be possible to build malicious queries
• Solid resources should now be considered as Graphs
  • Each triple in Solid should instead be a quad. The graph portion of the quad should be the resource in which a triple is located
  • Containers are also graphs
  • If a graph contains another graph, it is considered a part of the parent graph. So, if queried, results will be the aggregate of all sub-graphs
• Each graph is mapped to associated metadata.
  • Metadata includes (but is not limited to) the access control rules of a certain graph, and a pointer to the parent graph (if any)
  • Access control rules are at least represented by CONSTRUCT queries but may include other information about other access control standards
  • If there is no access control rule, the server will defer to the graph parent.
• Each auth token maps access control rules
  • Access control rules are stored with the token creator (Auth server) and are accessible via an unguessable URL.
  • Access control rules are at least represented by CONSTRUCT queries but may include other information about other access control standards
  • These access control rules restrict what a token holder is allowed to access
• Every request is restricted by the CONSTRUCT queries involved
  • An app requests with its constrained token to a URL (this URL is either a resource or container)
  • The token contains a CONSTRUCT query detailing a set of all triples to which token is allowed to access (represented at A)
  • The server constructs a set of all triples that the user's webid has been granted to as defined by the CONSTRUCT queries in the resource metadata (Represented as R)
    • First, it creates a set of triples of all allowed triples defined by its children's CONSTRUCT queries
    • Then it successively applies the CONSTRUCT queries of its parents
  • The server gathers all triples a request would involve (Represented as T).
  • If A ∪ R ⊄ T, the server rejects, else it executes the query and returns
  • This technique has discover built-in as a server only needs to make a query to a pod root to discover whatever it wants on the pod while still being constrained by its token.

[justinwb]

Thanks @jaxoncreed - can you also provide a use case or two with examples?

[kjetilk]

Actually, I didn't understand the problem. Is it intended as a future generalization of current WAC and Link-based access control and discovery?

If it is, I think I kinda get the high-level idea, but not the details. On a high level, I think the idea of using SPARQL to define subgraphs and access control to those subgraphs are sound. In principle, you can do that now, by having a conventional SPARQL Endpoint with the query encoded in the parameters. You'd probably bump into problems of normalizing the query, since the ACL would only apply to that very URL.

So, certainly worth exploring further.

One note on the details, you write that:

Each triple in Solid should instead be a quad. The graph portion of the quad should be the resource in which a triple is located

and this is an assumption it seems safe to make, it has been done many times and there seems to be consensus around it.

On the call, you mentioned something around constraints around existing data. In that vein, let me point out Boundz, a vocabulary that initially competed with SHACL and SHEX, but that has some other interesting properties in that acceptable data is defined in terms of data that is already in the model. It sounds like it might be relevant to that.

[jaxoncreed]

Here's a simple example of how this might work. Though sorry I hastily wrote this, so there may be a few mistakes in my through process:

To illustrate this concept, we will use the following hypothetical dataset:

|-root
|| .meta
||-chats
||| .meta
||| chat1.ttl
||| chat1.ttl.meta
||| chat2.ttl
||| chat2.ttl.meta

root/chat1.ttl

@prefix : <#>.
@prefix mee: <http://www.w3.org/ns/pim/meeting#>.
@prefix ic: <http://www.w3.org/2002/12/cal/ical#>.
@prefix XML: <http://www.w3.org/2001/XMLSchema#>.
@prefix flow: <http://www.w3.org/2005/01/wf/flow#>.
@prefix c: </profile/card#>.
@prefix ui: <http://www.w3.org/ns/ui#>.
@prefix n0: <http://purl.org/dc/elements/1.1/>.

:participation
    ic:dtstart "2020-01-07T01:16:43Z"^^XML:dateTime;
    flow:participant c:me;
    ui:backgroundColor "#e1c6c7".
:this
    a mee:LongChat;
    n0:author c:me;
    n0:created "2020-01-07T01:16:41Z"^^XML:dateTime;
    n0:title "Chat channel";
    flow:participation :id1578359803324;
    ui:sharedPreferences :SharedPreferences.

root/chat2.ttl

Resource Based Access Control

• Resource based access control entails rules the are defined the the Resource owner to restrict access to certain webids.
• Resource based access control rules can be defined in meta documents linked to the original document (aka graph)

The following metadata would grant public read access to chat1.ttl

chat1.ttl.meta

@prefix : <#>.
@prefix n0: <http://www.w3.org/ns/auth/acl#>.
@prefix solid: <https://solidproject.org/ont>

:Read
    a n0:Authorization;
    n0:accessTo <./>:;
    n0:agentClass faof:Agent;
    n0:mode n0:Read.
    solid:constructQuery: "
        CONSTRUCT { ?s ?p ?o } WHERE {
            GRAPH <https://example.com/chats/chat1.ttl>
            { ?s ?p ?o }
        }
    "

Notice that this is very close to an acl. You do not need to define acls anymore, but you can choose to if this server supports and understands acls. This could allow the server to apply queries more efficiently.

However, the only things that MUST be provided are the access mode, the construct query, and the agent class. You can consider this construct query identical to the acl rule's accessTo predicate.

[elf-pavlik]

However, the only things that MUST be provided are the access mode, the construct query, and the agent class. You can consider this construct query identical to the acl rule's accessTo predicate.

In your example I still see :Read n0:accessTo <./> . not sure if you left it in there by accident.

In general it doesn't look to me like current WAC would 'translate' to something else, it looks like extending WAC with solid:constructQuery to write more specific rules.

@ericprud how similar / different do you see it from SHACL https://www.w3.org/TR/shacl/#sparql-constraints?

One more thing we might want to search for in our use cases. Some example which has statement(s) using predicate in reverse direction. Maybe we could even pick up an example from ShEx primer where we have relation between a user and an issue https://shex.io/shex-primer/#inverse-properties or in chat1.ttl we would find statement like c:me ex:moderates :this . so the chat channel appears in the object position. Chat channel moderators could have write access to that channel for example.

In https://github.com/solid/authorization-and-access-control-panel/issues/51#issuecomment-570874556 we can find an example of shape based rule. I think we could take something like that and compare how such property based rule would work based on

• shapes
• owl restrictions
• sparql queries

[jaxoncreed]

In your example I still see :Read n0:accessTo <./> . not sure if you left it in there by accident.

That was left in on purpose. All rules must have a solid:constructQuery but they could optionally have implementation-specific triples as well, like accessTo

[kjetilk]

There is a simple form of SPARQL CONSTRUCT, BTW.

[RubenVerborgh]

I've been trying to jump into the discussion, as this issue seems very relevant, but I find its current text quite impenetrable.

The above consists of a list of things, which when combined, provide a solution to what specifically?

Note that the current problem section is a listing of techniques, not a problem statement. It's fine to point to other issues to describe it, I just need to understand first exactly what is being solved before I can wrap my head around any potential solution.

[kjetilk]

@RubenVerborgh we're on a call about it right now, please jump in

[RubenVerborgh]

On my way.

[bblfish]

I think it may be worth looking into whether one cannot just extend the current wACL by enlarging the classes of agents as related by the wac:agentClass to groups of agents as defined by an OWL class restriction. That is actually what I proposed to do in my second year report a year ago.