=Paper=
{{Paper
|id=Vol-2636/09paper
|storemode=property
|title=Pattern-based access control in a decentralised collaboration environment
|pdfUrl=https://ceur-ws.org/Vol-2636/09paper.pdf
|volume=Vol-2636
|authors=Jeroen Werbrouck,Ruben Taelman,Ruben Verborgh,Pieter Pauwels,Jakob Beetz,Erik Mannens
|dblpUrl=https://dblp.org/rec/conf/ldac/WerbrouckTVPBM20
}}
==Pattern-based access control in a decentralised collaboration environment==
https://ceur-ws.org/Vol-2636/09paper.pdf
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
Pattern-based access control in a decentralised
collaboration environment
Jeroen Werbrouck1,2 , Ruben Taelman3 , Ruben Verborgh3 , Pieter Pauwels4 ,
Jakob Beetz2 , and Erik Mannens3
1
Department of Architecture and Urban Planning, Ghent University
2
Department of Design Computation, RWTH Aachen University, Aachen, Germany
3
Department of Electronics and Information Systems, Ghent University – imec
4
Department of the Built Environment, TU Eindhoven
Abstract. As the building industry is rapidly catching up with digital
advancements, and Web technologies grow in both maturity and secu-
rity, a data- and Web-based construction practice comes within reach. In
such an environment, private project information and open online data
can be combined to allow cross-domain interoperability at data level,
using Semantic Web technologies. As construction projects often feature
complex and temporary networks of stakeholder firms and their employ-
ees, a property-based access control mechanism is necessary to enable a
flexible and automated management of distributed building projects. In
this article, we propose a method to facilitate such mechanism using ex-
isting Web technologies: RDF, SHACL, WebIDs, nanopublications and
the Linked Data Platform. The proposed method will be illustrated with
an extension of a custom nodeJS Solid server. The potential of the Solid
ecosystem has been put forward earlier as a basis for a Linked Data-based
Common Data Environment: its decentralised setup, connection of both
RDF and non-RDF resources and fine-grained access control mechanisms
are considered an apt foundation to manage distributed building data.
Keywords: Web Access Control · Decentralisation · Linked Building
Data · Common Data Environment · Nanopublications
1 Introduction
When envisaging a decentralised management of construction projects through-
out their life cycle, one of the main hurdles is to organise access to restricted
data, considering the complex network of contractors, subcontractors, companies
and employees. Each one of them has different roles and responsibilities, and may
be actively involved in multiple construction projects at the same time. As in-
dicated in [12], a decentralised environment for hosting building data requires
either a Role-Based Access Control (RBAC) mechanism or a property-based one
(also called Attribute-Based Access Control (ABAC)). To express more complex
patterns, other contextual information might be taken into account, such as the
content of the requested resource itself or assertions made by multiple parties.
Copyright © LDAC2020 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
118
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
In this case a Context-Based Access Control (CBAC) mechanism is used [7].
A recurring analogy to describe such context- or property-based approach in a
general sense is that one might not be able to name firefighters or paramedics
beforehand, but they can be given access if they are able to prove their function,
e.g. with valid certificates. In context of the construction industry, this could be
a (partial) delegation of access rights from contractors to subcontractors. Or,
before getting access to a certain resource, a client should prove she is involved
in the project as a ‘leading architect’ and at the same time demonstrate her
membership of a recognised association of architects. Such flexibility is offered
by existing Semantic Web technologies.
One of the main features of the Semantic Web is that it provides an enormous
flexibility to express knowledge of varying complexity. Recent developments have
added to the already existing technology stack the ability to validate such state-
ments against a certain set of conditions, also called ‘shapes’. Consequently,
using a Property-Based Access Control, where Anyone can say Anything about
Anything (the famous AAA paradigm of the Web), an assertion can be validated
to contain specific information, and its author can be checked. The result of the
validation determines access to specific data. Although this concept generally
does not depend on any existing platform, a starting point for implementation
could be the Solid platform [11,17,3], initiated by Tim Berners-Lee and actively
developed by Inrupt, Inc.5 . Solid provides an infrastructure where data and ap-
plications that use this data are separated, allowing the owners of the data to
give and revoke access to it at any given time and ensuring maximal reusability of
information. As indicated in [19], it has some properties that make it a promising
candidate to provide the basis for a construction-oriented platform, i.e. a decen-
tralised Common Data Environment (CDE) [6]. In this scenario, project data is
stored in ‘pods’ (Personal Online Data storage) per stakeholder: semantic data is
stored in graph files using RDF ontologies, other data (geometry, imagery etc.)
can be file-based, according to the Linked Data Platform (LDP)6 specifications.
A ‘pod’ is connected to a WebID, i.e. a HTTP URI referring to a particular
Agent (Person, Organisation etc.)7 .
In the search for technologies that support decentralised management of
building data, there is no need to reinvent the wheel; a few well-chosen adjust-
ments to the basic infrastructure could already answer many questions about
how a decentralised CDE could look like. In other words, because the initial use
case of Solid was to provide a decentralised alternative to social networks, its
‘vanilla’ server implementation is suited, but not yet optimised for use in the
construction industry. For example, the emulation of role-based access patterns
by setting up lists with WebIDs, corresponding to certain roles, is probably suf-
ficient for many (smaller) construction projects. However, an extension might be
necessary for managing larger project consortiums. Secondly, the performance
of the directory-based approach of the LDP specification versus the fully data-
5
https://inrupt.com/
6
https://www.w3.org/TR/ldp/
7
https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
119
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
based approach of triple stores needs to be benchmarked. Thirdly, a distinc-
tion in pod organisation might be useful: other requirements can be present for
stakeholder companies, their employees and ‘project pods’ containing basic in-
formation about the project that cannot be linked to one individual stakeholder
(e.g. containing project planning or exchange requirements). This publication
will only assess the first requirement.
In this paper, we propose a framework to allow property- and context-based
access control in a decentralised system. This relies on existing web-standards
and practices and is thus independent from existing platforms or ecosystems.
However, since the Solid ecosystem already offers a quite extensive implementa-
tion of standards such as LDP, it will be used as an implementation use case. As
the proposed method will rely on shape patterns, it will be called ‘pattern-based’
for the remainder of the text. After an overview of existing technologies upon
which we rely is given in Section 2, Section 3 discusses the basic properties such
a framework needs to incorporate. Section 4 then illustrates these properties
with an implementation based on the node-solid-server8 and an example request
featuring the proposed method. A conclusion and future ambitions are the main
topic of Section 5.
The paper forms part of the conSolid project, which aims to build an interop-
erable platform based on the Solid specifications, where specialised, ‘tailormade’
applications can use distributed building data throughout the building’s life cy-
cle; whether for design or simulation purposes, to manage inhabitant comfort
preferences or link to historical datasets.
2 Related Work
2.1 Web-based building data
Over the last decade, the Architecture, Engineering, Construction and Opera-
tions (AECO) industry has been adopting digital techniques at an unseen rate;
after a long digital dormancy, the sector is finally catching up with technological
innovations that have long boosted productivity in virtually all other economic
sectors. This new technological hausse is largely due to the emergence of Build-
ing Information Modelling (BIM), combined with rapid developments in the field
of cloud services for management of building projects: advanced digital systems
are set up to streamline project organisation and information exchange between
stakeholders, guaranteeing a long-time preservation of data that may be of use in
future phases of the building life cycle (BLC). Such environments are commonly
referred to as Common Data Environments (CDEs).
Oftentimes, the providers of CDEs are the same companies that develop BIM
authoring tools. This enables the setup of a highly integrated software suite and
results in an optimised project management. However, it may also result in a
vendor lock-in, making it more difficult to use software that is not included in
the ecosystem. Since many building projects are only temporary collaborations
8
https://github.com/solid/node-solid-server
120
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
between stakeholder offices, this scenario occurs quite frequently: every office has
its own software stack, depending on their workflow, area of expertise and bud-
get. To still be able to facilitate communication between software packages that
internally use different (proprietary) file formats and data models, most BIM
tools facilitate export and import of the Industry Foundation Classes (IFC)
(ISO 16739), maintained by BuildingSMART International9 . Closely related to
this is the more recent OpenCDE10 initiative, also covered by BuildingSMART,
in which multiple CDE developing companies collaborate to establish an inter-
operable REST (Representational State Transfer) specification that will allow
CDEs from different vendors to exchange project information more easily.
Current BIM authoring tools and CDEs have a strong focus on information
exchange via documents [6], however, a data-based approach based on Semantic
Web technologies is getting more and more attention. These technologies in-
clude, amongst others, the Resource Description Framework11 (RDF), the Web
Ontology Language12 (OWL), the SPARQL query language13 and the Shapes
Constraint Language14 (SHACL), all relying on the atomic building blocks of
the world wide Web, namely URIs15 . There is a growing consensus that the
application of Semantic Web technologies can reduce information loss, improve
interoperability and cross-domain collaboration, and enable automated checking
of rules and regulations [1,14].
A considerable research community is currently involved with establishing
and enhancing the foundations for a Web of building data. Probably the most
well-known open source solution that is not fundamentally based on Semantic
Web technologies is TNO’s BIMserver [2]. IFC files form the main input for
a BIMserver, a central repository from which data can be used by multiple
microservices or ‘BIM bots’16 . In the realm of Linked Data, apart from ontologies
for the built environment such as ifcOWL [13], the Building Topology Ontology
(BOT) [16], the Building Product Ontology (BPO) [18] and the Ontology for
Property Management (OPM) [15], projects such as the DRUMBEAT platform
[5] and the LBDserver17 focus on providing the infrastructure specifically for
management of linked building data. As mentioned in Section 1, a more general
approach is taken by the Solid initiative, which is completely independent from
the AECO industry, but shows intriguing overlaps with ambitions for a web-
based building collaboration environment.
9
https://www.buildingsmart.org/
10
https://github.com/buildingSMART/OpenCDE-API
11
https://www.w3.org/TR/rdf11-primer/
12
https://www.w3.org/TR/2012/REC-owl2-primer-20121211/
13
https://www.w3.org/TR/sparql11-query/
14
https://www.w3.org/TR/shacl/
15
https://www.w3.org/wiki/URI
16
https://www.youtube.com/watch?v=lyDSpTV6NQI
17
https://github.com/JWerbrouck/lbdserver project
121
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
2.2 The Solid Ecosystem
The advocates of Solid envisage a new way of using personal data in Web en-
vironments: by splitting up data and applications, people are put in charge of
who has access to their personal data, and they can revoke these access rights at
any given time. A use case only gaining relevance, given late concerns regarding
the use of personal information by social network enterprises, and the recent
legal response to these practices (e.g. the General Data Protection Regulation
(GDPR) enacted by the EU). The core of Solid consists of a set of Web standards
and practices, which can support a plethora of use cases in different domains.
A combination of these standards with recent developments of modular vocab-
ularies in the field of architecture and construction (Section 2.1), and networks
of specialised services for specific tasks in the BLC, looks a promising strategy
towards a data- and Web-driven construction project collaboration. A scenario
can be sketched where multiple stakeholders of a construction project have their
own Solid pods, where they manage their information about the project. The
infrastructure offered by the Solid ecosystem then acts as a decentralised CDE,
the semantic glue for interpreting this distributed information as a linked-data
based digital twin, where typical BIM data produced by different stakeholders
is connected to sensor data, geospatial data, historical data etc.
2.3 Access Control patterns in AECO
Multiple strategies currently co-exist on the Web to grant access to specific
information, among which Discretionary Access Control Lists (DAC) and Role-
Based Access Control (RBAC) are the most known ones. Where a DAC links
a list of actors to a piece of information, RBAC allows, for example, groups of
people with the same role to access the data. Both strategies are supported in
Solid. However, as indicated in section 1, relationships within a building project
often are more complex than this: a project involves a network of contractor
and subcontractor companies, each one of them might have multiple roles and
responsibilities, and access rights might differ internally between their respec-
tive employees as well. Some criteria are identified by [12], among which the
possibility to express arbitrary access rules, such as:
– All employees of company X working in project Y;
– Inhabitants of the respective building;
– The facility manager of Project Z.
[12] mentions that for this kind of access rules, a Role- or Property-based
Access Control mechanism is required. Since in the end, file content, company
structure and other contextual information might also play a role, we extend
this to Context-Based Access Control. Since one of the end goals of the conSolid
project is to set up a useful ecosystem for construction professionals, establish-
ing reusable patterns is one of the key priorities. Explicit references to certain
individuals can already be expressed using the default ACL implementation in
122
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
Solid; implicit references form the main use case of the framework proposed in
this paper. I.e. ‘all employees of company X’ may be expressed using ACL agent
groups; ‘all employees of the company that is responsible for architectural design
of the project this resource belongs to’ could be a reusable, property-based pat-
tern that may be expressed using the method explained in Section 3. For such
scenario to happen, at least two warrants may be needed: one stating that the
employee works for company X (signed by company X or one of its ‘full’ dele-
gates) and another one indicating that company X is indeed involved in Project
Y (signed by one of the authorised project delegates). Although it would prob-
ably be possible to express these patterns in the default ACL implementation
in Solid (e.g. by hardcoding the WebIDs of these people into ‘agent-groups’),
complex patterns that pose multiple requirements to visitors will be expressed
and verified with more ease using a pattern-based approach.
3 Pattern-Based Access Control
This section describes the foundations of the pattern-based ACL framework.
Namespaces and assigned prefixes that are used in the remainder of the paper
are indicated in Listing 3.1. The framework is meant to extend beyond typical
use cases of the AECO industry and be generally applicable, although regulating
access to information within construction projects remains the primary target.
In this paper, we define a new vocabulary for Pattern-based Access Control
(PBAC). The ConSolid (CS) vocabulary, which will be used to indicate profes-
sional relationships in a construction project, is also part of the conSolid project,
but has not been published at the time of writing.
# ontologies:
@prefix pbac:
@prefix cs: .
@prefix np: .
@prefix sh: .
@prefix rdfs: .
@prefix acl: .
# the document itself:
@prefix : <#>.
# example webIDs:
@prefix alice: .
@prefix bob: .
@prefix proj: .
Listing 3.1. Namespaces used throughout this publication
3.1 Trusting statements on the Web
By default, the Web is an open framework, where people can express anything
they want, from the brightest theories to the purest nonsense. To take every-
thing on the Web as truth would be very naive indeed. For a pattern-based
access control to function properly, a mechanism to prove the statements thus
needs to exist: how to know the assigned properties are valid? At the moment,
123
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
probably the closest we can get to verification of assertions is to use a system
of provenance, similar to the system used in TLS certificates, ultimately leading
to a trusted ‘root authority’. Therefore, a provenance-sensitive way of express-
ing statements is necessary. Such provenance-based system is provided by the
Nanopublications concept. Nanopublications [4,9] are ‘a community-driven ap-
proach to representing structured data along with its provenance into a single
publishable and citable entity’18 , and are mainly used in the field of bioinformat-
ics and life sciences. As the name indicates, they represent very small assertions,
along with provenance and metadata. A common format for expressing nanop-
ublications is the TriG19 format, an extension of the Turtle notation20 to include
multiple named graphs in one single document. A nanopublication thus essen-
tially is a set of RDF quads, following a fixed template that consists of four
tightly interconnected named graphs:
– A ‘Head’ graph, linking the different parts of the nanopublication to the
nanopublication document itself.
– An ‘Assertion’ graph, containing the actual assertion.
– A ‘Provenance’ graph, indicating where a certain statement comes from. De-
pending on the case, this could be calculation input, an authority approving
the statement etc.
– A ‘Publication Info’ graph, stating the metadata about the publication itself:
authorship, publication date, signature etc.
To keep nanopublications immutable and verifyable, they can be integrated
with a combination of digital signatures, using RSA key pairs, and ‘Trusty URIs’
[10]. The author of the nanopublication can digitally sign the document and then
‘freeze’ it using Trusty URIs: the content of the graph is hashed and embedded
in the URI by which the document refers to itself21 . A Java implementation to
sign nanopublications and make them trusty at once is described in [8]. A local
server implementation to sign these publications with one’s WebID is discussed
in Section 4.1.
Digitally signed, ‘trusty’ nanopublications play a major role in the proposed
framework for pattern-based Access Control: if signed by a trusted authority,
the assertion can be checked against a certain SHACL shape, which may or may
not grant access to the requested resource, depending on the validation outcome.
SHACL is a recent W3C standard designed to validate graphs against a given set
of conditions. Unlike OWL, SHACL uses a closed-world paradigm, meaning that
if something is not explicitly present, it is deemed false. This renders it an apt
method for regulating access to online resources. To avoid confusion with other
existing types of nanopublications, nanopublications which specifically relate
properties to certain agents will be called ‘nanocredentials’ for the remainder of
the paper.
18
http://nanopub.org/guidelines/working draft/
19
https://www.w3.org/TR/trig/
20
https://www.w3.org/TR/turtle/
21
Note that this does not need to match a URL where the document can be found.
124
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
A final requirement is that the authors of the assertion expressed in the
nanocredential are actually trusted. An assertion may match the SHACL shape
that grants access to the requested resource, but if anyone can write down this
assertion, the framework is not very powerful. Therefore, a server implementing
the framework must know which authors can be trusted for expressions matching
the SHACL shape. This trust may be established in a general way or within a
limited scope. A general way would mean these people are ‘blindly trusted’ for
their expressions; a limited scope of trust could be indicated by linking their
WebID to specific statements (e.g. in the form of SHACL shapes refered to in
a pattern-based access rule (Section 3.2). The development of a framework to
strike a balance between these two extremes is outside the scope of this paper,
but may base itself upon the PBAC vocabulary.
To summarise, three main components are identified for a minimal pattern-
based Access Control framework:
– Trusty and digitally signed nanopublications for relating properties to the
requesting agent (‘nanocredentials’);
– SHACL shapes indicating the requirements that are needed to get access to
the resource;
– ‘Trusted authorities’ that can be expressed both in a very specific way and
in a general sense.
In Section 3.2, these components will be combined into a method for express-
ing pattern-based access rules for distributed building data.
3.2 Method
The WAC22 ontology forms the basis of the framework. If the requirements set by
a pattern-based rule are met, ACL modes (Read, Write, Append, Control) will
be allowed for a given visitor. Along with SHACL shapes and trusted authorities,
a dynamic rule (pbac:DynamicRule) thus contains information about the ACL
modes it grants. The connection to one or multiple (local or remote) SHACL
shapes is established by the property pbac:hasShape. The difference between an
‘inclusive’ rule (a visitor needs to conform to only one of the mentioned shapes),
or an ‘exclusive’ one (all shapes need to be met before the visitor is granted
access), may be established by linking pbac:hasShape to a locally defined shape,
which may combine different (possibly remote) shapes through various Boolean
operators (sh:and or sh:or) (Example: Listing 4.2).
Section 3.1 mentions the necessity for trusted authorities to be indicated,
either in a very specific way or generally. The most fine-grained way for indi-
cating trusted authorities is to directly link shapes and trusted authorities. In
this case, a local triple could be added to the document linking the shape to
a pbac:TrustedAuthority. Another indication of a rule’s trusted authorities is
to embed them as a property of the pbac:DynamicRule, which can be done via
22
https://github.com/solid/web-access-control-spec
125
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
pbac:hasTrustedAuthority (Example: Listing 4.2). In both scenarios, their
authority is limited to the pbac:DynamicRule of interest, and a well-defined
boundary is determined for trusting their statements. However, in certain cases
(and for a more easy setup of rule frameworks) one might want to express au-
thorities in a broader sense, for example within the scope of an entire directory,
and then cascading down to its specific subdirectories and resources. For exam-
ple, in the case of a distributed building project, we can imagine that there is a
project pod containing the basic specifications of the project [19]. A stakeholder
of the project may indicate at the top-level folder where their project data re-
side, that all nanopublications signed by the project pod WebID may be trusted.
This authority then ‘boils down’ to the resources (graphs, geometry, imagery ...)
stored in this folder.
When requesting access to a resource on a remote conSolid server, a client
then informs the server about the nanocredentials it wishes to present. However,
not all of them can be made public; and the same holds for shapes protecting
a resource or the authorities that are trusted within a certain scope. Secondly,
an agent may have lots of nanocredentials: to prevent a waste of precious band-
width and server resources it is undesirable to present them all along with the
request. Many use cases may therefore impose some negotiation steps [7]. Differ-
ent strategies may be used here, depending on the level of trust between visitor
and owner of the resource. An ‘open strategy’ is to refer to a public shape, a
more controlled one could be a step-by-step release of requirements. Relating
this to construction projects, such step-by-step approach may balance the need
to keep (access) information internal to the project and the need to explain to
stakeholders why they cannot access certain information, and who they should
contact if this is to be changed. After a first requirement is met (‘the visitor
is stakeholder in the project ...’), the server could choose to ‘release’ the other
shapes, thereby providing specific information about any other conditions that
need to be fulfilled (‘... with the task of performing a structural analysis’). As
the SHACL specification includes the possibility to generate detailed validation
reports, textual as well as machine-readable explanations may be sent to a stake-
holder whose request just got rejected, which is one of the challenges mentioned
in [7].
An elaborate discussion of possible negotiation strategies extends beyond the
scope of this publication. Briefly, they may rely on the exposure of a visitor’s
nanocredentials via a restricted service (e.g. a SPARQL endpoint) and facilitate
information exchange between the conSolid server hosting the resource of interest
and the endpoint owned by the agent requesting access. Depending on the degree
of publicness of the nanocredentials on the endpoint’s side and the SHACL
shapes on the conSolid server side, a series of HTTP requests may be performed
back-and-forth before the final validation takes place. A schematic example of
such negotiation is given in Figure 1.
During the validation step, SHACL shapes in each relevant rule are vali-
dated against the collection of present nanocredentials. A rule is relevant when
it yields an ACL mode that has not been granted already (e.g. because the re-
126
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
Fig. 1. Example negotiation: requesting multiple signed nanocredentials from different
agents; the SHACL shapes protecting the resource are public.
quester is already mentioned explicitly in the ACL graph for the requested ACL
mode). Since the identity of all possible visitors cannot be implemented directly
in the shape (as this would totally undermine the purpose of the framework), the
sh:TargetNode (i.e. the nodes against which the shape constraints are checked)
of the SHACL shape relates to a dedicated resource, namely pbac:visitor.
This implies that, at runtime, the pbac:visitor is changed to the WebID of
the requesting agent. If the validation passes, the resulting ACL mode(s) are
added to the array of allowed ACL modes, and the the visitor may proceed.
4 Implementation
4.1 ConSolid server
The framework outlined in Section 3.2 has been partly implemented in an adap-
tation of the node-solid-server. The resulting conSolid server is available on
Github23 . Up and running, the server can be tested using both browser requests
and dedicated software such as Postman. Code for signing nanopublications us-
ing Solid credentials and ‘freezing’ them with trusty URIs is under development,
a testing version is available at Github24 , relying on the code developed in [8]. To
enable validation of the nanopublication, the corresponding public key needs to
be present in the WebID graph of the signer. Section 4.2 illustrates the workflow
defined in Section 3.2 using the abovementioned server implementation.
23
https://github.com/JWerbrouck/consolid-server
24
https://github.com/JWerbrouck/validator-bot
127
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
4.2 Example
As a summarising example, consider the following situation: the engineer of a
construction project, Alice, needs information about the building’s topology,
which is mentioned in the project repository of Bob, the architect, his pod as
‘topology.ttl’. Apart from the project engineer, project architects have access to
this information, too (Listing 4.2). Alice sends a nanocredential, signed by the
project pod (proj:me), along with her request, as a confirmation that she is
involved in this project as a cs:LeadingEngineer (Listing 4.1). Before valida-
tion takes place, an inference engine could infer implicit statements, increasing
the chances of success (e.g. a cs:LeadingEngineer is an rdfs:subClassOf a
cs:Engineer, so if the Dynamic Rule allows instances of cs:Engineer to read
the resource, instances of cs:LeadingEngineer should also be allowed access).
# asserted in the nanocredential
proj:me cs:hasLeadingEngineer alice:me .
# inferred triples (before validation)
proj:me cs:employs alice:me ;
cs:hasEngineer alice:me .
alice:me a cs:LeadingEngineer, cs:Engineer ;
cs:leadingEngineerOf proj:me ;
cs:engineerOf proj:me ;
cs:isEmployedBy proj:me .
Listing 4.1. Assertion graph in Nanocredential 1
The graph ‘topology.ttl’ is regulated by a dedicated ACL file, ‘topology.ttl.acl’.
Apart from some standard ACL access rules, the ACL defines a Dynamic Rule
(Listing 4.2). Other rules with different requirements could be present in the
ACL document as well. The pbac:hasTrustedAuthority declaration is imple-
mented directly in the shape, although this could also be mentioned at a higher
level or linked to the each of the individual shapes, as indicated in Section 3.2.
:ReadRule a pbac:DynamicRule;
rdfs:comment "Allows project engineers and architects to READ the given resource.";
pbac:hasShape :superShape_1;
pbac:hasTrustedAuthority ;
acl:accessTo ;
acl:mode acl:Read.
:superShape_1 a sh:NodeShape ;
sh:targetNode pbac:visitor;
sh:or (
) .
Listing 4.2. Example ACL file enhanced with a PBAC rule
Only one SHACL shape needs to be valid in this example in order to complete
the validation: both people conforming to the engineer shape and the architect
shape are allowed to read the resource. Shapes needs to be dereferenceable and
accessible for the validation engine, but can be located anywhere on the Web
(e.g. in the agent’s Pod, the project Pod or in a public repository, available
128
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
for reuse). Furthermore, if combined with a sh:or statement, they should be
oriented towards the same targetNode, which might impose strict agreements
on the shapes to use.
proj:EngineerShape
a sh:NodeShape ;
sh:targetNode pbac:visitor;
sh:property [
sh:path cs:isEngineerOf;
sh:hasValue proj:me;
] .
Listing 4.3. Shape graph of the PBAC rule in Listing 4.2
For this example, the SHACL validation report does not contain any er-
rors, so Alice can proceed her request to read the resources in the ‘topology.ttl’
graph, and use it within a linked building data web service, potentially in combi-
nation with other data that was retrieved in the same way, using a subset of her
nanocredentials and those applying to her office. The full nanocredential exam-
ple used in this publication can be found at https://github.com/JWerbrouck/
validator-bot/blob/master/example np consolid.trig
4.3 Future work
In this section, an experimental implementation of the framework was applied to
an adaptation of the node-solid-server. Based on this framework, an example was
then discussed where one stakeholder of a certain building project proved her
involvement and role in the project to another stakeholder, by sending one of her
nanocredentials. After verification of the nanocredential, and validation against
the shape mentioned in the PBAC rule ‘protecting’ the requested resource, read
permissions were granted.
It may be clear that the approach taken in this paper only scratches the
surface of this topic, and that additional work in several fields is required. In the
short term, a clear approach for delegating access will be devised. Especially in
construction, stakeholders will be mainly offices employing individuals. Although
SHACL shapes might reflect this by integrating the delegation pattern directly,
this would only solve the problem partly. Furthermore, use of web tokens may
significantly improve performance: after a valid check, a token is issued allowing
access for a limited timeframe, thereby omitting cumbersome checks and allowing
to access real-time data with less latency. In the longer term, questions need to
be answered about establishing chains of trustful assertions with more than 2 or
3 actors: if someone can only prove his right to access a resource by presenting
a bundle of nanopublications, which only provide the right pattern if combined,
some of those assertions owned by different actors and potentially not public,
how does this network of servers negotiate about (delegated) view rights, how
does one propagate through a network in which only a ‘root trusted authority’ is
known but not the way how to reach this authority, and how can client and server
privacy be balanced so that the amount of relevant information is proportional
to the validation time and resources? Lastly, the question remains if shapes
129
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
should be based on nanocredential templates or the other way around; although
a certain degree of reasoning is feasible, it is to be expected that shapes and
nanocredential assertions should not differ too much in content.
5 Conclusion
In this paper, we illustrated a basic method for pattern-based access control
scenarios. Although multiple technologies already exist to perform ID- or role-
based access control, and for many use cases these technologies satisfy the re-
quirements, pattern- (or context-)based access control has been identified as one
of the more powerful ways of regulating access within complex, decentralised
(building) projects. Based on existing standards such as RDF and SHACL, the
Solid ecosystem and the nanopublication guidelines, a workflow was initiated in
which not the identity of the client determines access to certain resources, but
rather their properties as confirmed by trusted third parties. To a certain de-
gree, such patterns can already be expressed using the default ACL schemes of
Solid, with hard-coded user groups corresponding to certain roles. However, as
the intention of this framework is to be extendible beyond AECO implementa-
tions, and to allow more complex patterns to be validated without hard-coding
WebIDs, we believe this research can provide a basis for future work in this field.
6 Acknowledgements
This research is funded by the Research Foundation Flanders (FWO) in the form
of a personal Strategic Basic (SB) Research grant (grant no. 1S99020N).
References
1. Beetz, J., Leeuwen, van, J., Vries, de, B.: An Ontology Web Language Notation of
the Industry Foundation Classes. In: Scherer, R., Katranuschkov, P., Sconfke, S.E.
(eds.) Proceedings of the 22nd CIB W78 Conference on Information Technology
in Construction. pp. 193–198. Technische Universität Dresden (2005)
2. Beetz, J., van Berlo, L., de Laat, R., van den Helm, P.: Bimserver. org–an open
source ifc model server. In: Proceedings of the CIP W78 conference. p. 8 (2010)
3. Buyle, R., Taelman, R., Mostaert, K., Joris, G., Mannens, E., Verborgh, R.,
Berners-Lee, T.: Streamlining governmental processes by putting citizens in con-
trol of their personal data. In: International Conference on Electronic Governance
and Open Society: Challenges in Eurasia. pp. 346–359. Springer (2019)
4. Groth, P., Gibson, A., Velterop, J.: The anatomy of a nanopublication. Information
Services & Use 30(1-2), 51–56 (2010)
5. Hoang, N.V., Törmä, S.: Drumbeat platform—a web of building data implementa-
tion with backlinking. In: eWork and eBusiness in Architecture, Engineering and
Construction: ECPPM 2016: Proceedings of the 11th European Conference on
Product and Process Modelling (ECPPM 2016), Limassol, Cyprus, 7-9 September
2016. p. 155. CRC Press (2017)
130
Proceedings of the 8th Linked Data in Architecture and Construction Workshop - LDAC2020
6. ISO, B.: 19650-1: 2018. BSI Standards Publication Organization and digitization
of information about buildings and civil engineering works, including building in-
formation modelling (BIM)-Information management using building information
modelling (2018)
7. Kirrane, S., Mileo, A., Decker, S.: Access control and the resource description
framework: A survey. Semantic Web 8(2), 311–352 (2017)
8. Kuhn, T.: nanopub-java: A java library for nanopublications. arXiv preprint
arXiv:1508.04977 (2015)
9. Kuhn, T., Barbano, P.E., Nagy, M.L., Krauthammer, M.: Broadening the scope of
nanopublications. In: Extended Semantic Web Conference. pp. 487–501. Springer
(2013)
10. Kuhn, T., Dumontier, M.: Trusty uris: Verifiable, immutable, and permanent dig-
ital artifacts for linked data. In: European semantic web conference. pp. 395–410.
Springer (2014)
11. Mansour, E., Sambra, A.V., Hawke, S., Zereba, M., Capadisli, S., Ghanem, A.,
Aboulnaga, A., Berners-Lee, T.: A demonstration of the solid platform for social
web applications. In: Proceedings of the 25th International Conference Companion
on World Wide Web. pp. 223–226 (2016)
12. Oraskari, J., Törmä, S.: Access control for web of building data: Challenges and
directions. In: eWork and eBusiness in Architecture, Engineering and Construc-
tion: ECPPM 2016: Proceedings of the 11th European Conference on Product and
Process Modelling (ECPPM 2016), Limassol, Cyprus, 7-9 September 2016. p. 45.
CRC Press (2016)
13. Pauwels, P., Terkaj, W.: EXPRESS to OWL for Construction Industry: Towards
a Recommendable and Usable ifcOWL Ontology. Automation in Construction 63,
100—-133 (2016). https://doi.org/10.1016/j.autcon.2015.12.003
14. Pauwels, P., Zhang, S., Lee, Y.C.: Semantic Web Technologies in AEC indus-
try: A Literature Overview. Automation in Construction 73, 145—-165 (2017).
https://doi.org/10.1016/j.autcon.2016.10.003
15. Rasmussen, M., Lefrançois, M., Bonduel, M., Hviid, C.A., Karlshøj, J.: Opm: An
ontology for describing properties that evolve over time. In: 6th Linked Data in
Architecture and Construction Workshop (LDAC), CEUR Workshop Proceedings.
vol. 2159, pp. 24–33 (2018), http://ceur-ws.org/Vol-2159/03paper.pdf
16. Rasmussen, M.H., Pauwels, P., Lefrançois, M., Schneider, G.F., Hviid, C.A.,
Karlshøj, J.: Recent changes in the Building Topology Ontology. In: 5th Linked
Data in Architecture and Construction Workshop (LDAC). Dijon, France (2017),
https://hal-emse.ccsd.cnrs.fr/emse-01638305
17. Sambra, A.V., Mansour, E., Hawke, S., Zereba, M., Greco, N., Ghanem, A., Za-
gidulin, D., Aboulnaga, A., Berners-Lee, T.: Solid: a platform for decentralized
social applications based on linked data. Tech. rep., Technical report, MIT CSAIL
& Qatar Computing Research Institute (2016)
18. Wagner, A., Rüppel, U.: BPO: the building product ontology for assembled prod-
ucts. In: 7th Linked Data in Architecture and Construction Workshop (LDAC),
CEUR Workshop Proceedings. pp. 106–119 (2019), http://ceur-ws.org/Vol-
2389/08paper.pdf
19. Werbrouck, J., Pauwels, P., Beetz, J., van Berlo, L.: Towards a decentralised com-
mon data environment using linked building data and the solid ecosystem. In:
36th CIB W78 2019 Conference. pp. 113–123 (2019), https://biblio.ugent.be/
publication/8633673
131