Skip to content

Latest commit

 

History

History
216 lines (166 loc) · 12.5 KB

wac-acp-diff-story.md

File metadata and controls

216 lines (166 loc) · 12.5 KB
Raw

ACP Compared to Web Access Control

This document is intended to reflect the following semi-authoritative (strongly suggestive) definitions:

Audience: those familiar with WAC or those who learn from comparisons

Access control is fundamentally about stating who can do what to what resource. This matches very precisely the WAC ontology.

ShEx for WAC:

Systems implementing Web Access Control (WAC) use a simple schema to make those assertions directly in RDF:

PREFIX acl: <http://www.w3.org/ns/auth/acl#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>

<AclShape> {
  # who
  (  acl:agentClass [foaf:Agent acl:AuthenticatedAgent]
    | acl:agentGroup @<GroupShape> OR IRI # likely in another resource
    | acl:agent IRI
    | acl:origin IRI
  )+ ;

  # can do what
  acl:mode [acl:Read acl:Write acl:Append acl:Control] + ;

  # to what resource
  (   acl:accessTo IRI
    | acl:accessToClass [foaf:Document] OR @<AclRegexShape> # TODO: remove Regexp, add auth user
  ) ;

  ^acl:trustedOrigin IRI ?
}

<GroupShape> { foaf:member IRI + }
<AclRegexShape> { acl:regex LITERAL }

(try it)

For example, if Jezebel decides to let Bartholomew copy her physics assignment, she could write:

_:bart-copies-assignment-1
  acl:agent <http://solid.example/users/bart#id> ;
  acl:mode acl:Read ;
  acl:accessTo </courses/8.04/assignment-1> .

In Solid, this access document would appear in the same Container as assignment-1.

In principle, WAC lets her grant access to all assignments under /courses/8.04/ —

_:bart-copies-my-assignments
  acl:agent <http://solid.example/users/bart#id> ;
  acl:mode acl:Read ;
  acl:accessToClass [ acl:regex ".*/courses/8.04/assignment-.*" ] .

— but Solid doesn't implement that feature, instead applying access to everything in a Container, e.g. —

_:bart-reads-8.04
  acl:agent <http://solid.example/users/bart#id> ;
  acl:mode acl:Read ;
  acl:accessTo </courses/8.04/> .

ShEx for ACP

ACP maintains separate metadata associating resources to access control statements.

PREFIX acp: <http://www.w3.org/ns/solid/acp#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

# who
<RuleShape> {
  a [acp:Rule] ? ;
  acp:agent IRI ;
}

# can do what
<PolicyShape> {
  a [acp:Policy] ? ;
  acp:allow [acp:Write acp:Read acp:Append] + ;
  acp:allOf @<RuleShape> ;
}

# to what -- AccessControl doc linked to ACL'd resource with:
#   Link: <https://alice.pod/resume?ext=acp>; rel="http://www.w3.org/ns/solid/acp#accessControl"
<AccessControlShape> {
  a [acp:AccessControl] ? ;
  (
      acp:apply @<PolicyShape>
    |
      ( acp:applyConstant @<PolicyShape> ;
        acp:applyMembersConstant @<PolicyShape> ;
      )
  )
}

(try it)

As above, Jezebel can let Bartholomew copy her homework by editing the ACL document associated with </courses/8.04/assignment-1> by the acp:accessControl link header (e.g., </courses/8.04/assignment-1?access>):

_:bart-copies-assignment-1
  a acp:AccessControl ;
  acp:apply [
    a acp:Policy ;
    acp:allow acp:Read ;
    acp:allOf [
      acp:agent <http://solid.example/users/bart#id>
    ]
  ] .

She could instead move that policy someplace independent from the existence of </courses/8.04/assignment-1>, e.g., </myAccessPolicies>, so it won't disappear if she deletes or renames assignment-1:

<#bart-copies-my-homework>
  a acp:Policy ;
  acp:allow acp:Read ;
  acp:allOf [
    acp:agent <http://solid.example/users/bart#id>
  ] .

Now she can apply it to multiple homework documents or all of her 8.04 documents with individual access controls like:

_:bart-copies-assignment-2
  a acp:AccessControl ;
  acp:apply </myAccessPolicies#bart-copies-my-homework> .

Minimal Extension to WAC enabling the same features

Another way of getting the same effect as ACP is to extend WAC with an :authorizes relation defined as —

acl:accessTo owl:inverseOf [
        owl:propertyChainAxiom ( acl:accessControl :authorizes )
      ] .

(We leave the namespace for :authorizes open for the moment as it could be in the wac, the acp, or another namespace).

This would allow one to place rules in different resources without needing to specify the wac:accessTo relation as in ACP. For example, the access control resource associated with Tim Berners-Lee's WebID Profile could contain —

<> :authorizes _:a1, <personal#Rule1> .
_:a1 a acl:Authorization;
   acl:agentClass foaf:Agent ;
   acl:mode acl:Read .

Note that the acl:accessTo relation is missing here, but it can easily be inferred. Any agent — be it a client or the server Guard — following the Link: <card.acl>;rel="http://www.w3.org/ns/auth/acl#accessControl" header from the original resource <card>, can then follow the :authorizes links and so deduce the following 2 statements (see the illustration below):

  1. for the bnode _:a1

    _:a1 acl:accessTo <card> .

    Here, deduction means, quite simply: to create a new graph with the above triple added to it. Once that is done, the same AclShape written up above holds for that graph.

  2. for the <personal#Rule1>

    As above after dereferencing the <personal#Rule1> the same principle applies. If the document <personal> contains the following triples —

    <#Rule1> acl:agent <card#i>;
    acl:mode acl:Read, acl:Write .

    — then the client, having followed the Link: <card.acl>;rel="...#accessControl" header from <card> and followed the :authorizes link to <personal>, would be able to deduce the triple —

    <#Rule1> acl:accessTo <card> .

    — so that AclShape would still be valid.

We thus get the same effect of allowing rules to be written and referred to, without those rules needing to specify in advance all the resources for which it is valid.

The above layout is illustrated in the following diagram. Double lines represent Link relation headers; the solid lines represent relations explicitly written out; and the dotted lines represent inferred relations.

Illustration of :authorizes

We seem to have two AclShapes that are compatible.

  1. The current AclShape, as defined above, would allow clients working with the inferred graph to continue working even on WAC deployed as above. They would find the acl:accessTo relation in the inferred graph.

  2. Newer Clients could use a different Shape, taking into account the following of the right Link header. This Shex would be —

    PREFIX acl: <http://www.w3.org/ns/auth/acl#>

<WacLinkHeaderShape> {
   # Link header shape
   (acl:accessControl <WacAuthzShape> )
}

<WacAuthzShape> {
   ( :authorizes <AclShape2> )
}

    — where <AclShape2> is <AclShape> minus the acl:accessTo and acl:accessToClass relations.

As we see, though, this does not mean that these two relations need to be removed from the ACL ontology. They are the first step to understanding access control, and will very likely be useful for applications such as Linked Data Notifications, and can easily be inferred.