As the building industry is rapidly catching up with digital advancements, and Web technologies grow in both maturity and security, 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 rms and their employees, a property-based access control mechanism is necessary to enable a exible and automated management of distributed building projects. In this article, we propose a method to facilitate such mechanism using existing 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 ne-grained access control mechanisms are considered an apt foundation to manage distributed building data.
When envisaging a decentralised management of construction projects
throughout 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 di erent roles and responsibilities, and may
be actively involved in multiple construction projects at the same time. As
indicated in [
One of the main features of the Semantic Web is that it provides an enormous
exibility to express knowledge of varying complexity. Recent developments have
added to the already existing technology stack the ability to validate such
statements 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 speci c information, and its author can be checked. The result of the
validation determines access to speci c data. Although this concept generally
does not depend on any existing platform, a starting point for implementation
could be the Solid platform [
In the search for technologies that support decentralised management of building data, there is no need to reinvent the wheel; a few well-chosen adjustments 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 sufcient 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 speci cation versus the fully data
based approach of triple stores needs to be benchmarked. Thirdly, a distinction in pod organisation might be useful: other requirements can be present for stakeholder companies, their employees and `project pods' containing basic information 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 rst 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 o ers a quite extensive implementation 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 interoperable platform based on the Solid speci cations, where specialised, `tailormade' applications can use distributed building data throughout the building's life cycle; whether for design or simulation purposes, to manage inhabitant comfort preferences or link to historical datasets. 2 2.1
Over the last decade, the Architecture, Engineering, Construction and Operations (AECO) industry has been adopting digital techniques at an unseen rate; after a long digital dormancy, the sector is nally 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 Building Information Modelling (BIM), combined with rapid developments in the eld 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 di cult to use software that is not included in the ecosystem. Since many building projects are only temporary collaborations
between stakeholder o ces, this scenario occurs quite frequently: every o ce has its own software stack, depending on their work ow, area of expertise and budget. To still be able to facilitate communication between software packages that internally use di erent (proprietary) le 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 interoperable REST (Representational State Transfer) speci cation that will allow CDEs from di erent vendors to exchange project information more easily.
Current BIM authoring tools and CDEs have a strong focus on information
exchange via documents [
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 [
The advocates of Solid envisage a new way of using personal data in Web environments: 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 di erent domains. A combination of these standards with recent developments of modular vocabularies in the eld of architecture and construction (Section 2.1), and networks of specialised services for speci c 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 o ered 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 di erent stakeholders is connected to sensor data, geospatial data, historical data etc. 2.3
Multiple strategies currently co-exist on the Web to grant access to speci c
information, among which Discretionary Access Control Lists (DAC) and
RoleBased 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 di er internally between their
respective employees as well. Some criteria are identi ed by [
[
This section describes the foundations of the pattern-based ACL framework. Namespaces and assigned pre xes 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 de ne a new vocabulary for Pattern-based Access Control (PBAC). The ConSolid (CS) vocabulary, which will be used to indicate professional 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: <https://jwerbrouck.inrupt.net/public/PBAC/PBAC-ontology.ttl> @prefix cs: <http://www.consolid.org/ontology/cs#> . @prefix np: <http://www.nanopub.org/nschema#> . @prefix sh: <http://www.w3.org/ns/shacl#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix acl: <http://www.w3.org/ns/auth/acl#>. # the document itself:
@prefix : <#>. # example webIDs: @prefix alice: <https://alice.engineers.com/profile/card#> . @prefix bob: <https://bob.architects.com/profile/card#> . @prefix proj: <https://exampleproject.consolid.org/profile/card#> .
Listing 3.1. Namespaces used throughout this publication 3.1
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
everything 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,
probably the closest we can get to veri cation of assertions is to use a system
of provenance, similar to the system used in TLS certi cates, ultimately leading
to a trusted `root authority'. Therefore, a provenance-sensitive way of
expressing statements is necessary. Such provenance-based system is provided by the
Nanopublications concept. Nanopublications [
To keep nanopublications immutable and verifyable, they can be integrated
with a combination of digital signatures, using RSA key pairs, and `Trusty URIs'
[
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 speci cally 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.
A nal 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 speci c 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 identi ed for a minimal patternbased 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 speci c way and in a general sense.
In Section 3.2, these components will be combined into a method for expressing pattern-based access rules for distributed building data. 3.2
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 di erence 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 de ned shape, which may combine di erent (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 speci c way or generally. The most ne-grained way for
indicating 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
pbac:hasTrustedAuthority (Example: Listing 4.2). In both scenarios, their
authority is limited to the pbac:DynamicRule of interest, and a well-de ned
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
authorities in a broader sense, for example within the scope of an entire directory,
and then cascading down to its speci c subdirectories and resources. For
example, in the case of a distributed building project, we can imagine that there is a
project pod containing the basic speci cations of the project [
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
bandwidth and server resources it is undesirable to present them all along with the
request. Many use cases may therefore impose some negotiation steps [
An elaborate discussion of possible negotiation strategies extends beyond the scope of this publication. Brie y, 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 nal 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 validated 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 requester 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.1
The framework outlined in Section 3.2 has been partly implemented in an
adaptation 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
using Solid credentials and `freezing' them with trusty URIs is under development,
a testing version is available at Github24, relying on the code developed in [
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 con rmation that she is involved in this project as a cs:LeadingEngineer (Listing 4.1). Before validation 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 le, `topology.ttl.acl'. Apart from some standard ACL access rules, the ACL de nes a Dynamic Rule (Listing 4.2). Other rules with di erent requirements could be present in the ACL document as well. The pbac:hasTrustedAuthority declaration is implemented 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 <https://consolidproject1.inrupt.net/profile/card#me>; acl:accessTo <topology.ttl>; acl:mode acl:Read. :superShape_1 a sh:NodeShape ; sh:targetNode pbac:visitor; sh:or ( <https://bob.architects.com/projects/BuildingProject1/EngineerShape.ttl> <https://shapes.consolidproject.be/shapes/ArchitectShape.ttl>
Listing 4.2. Example ACL le 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 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 errors, 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 combination with other data that was retrieved in the same way, using a subset of her nanocredentials and those applying to her o ce. The full nanocredential example used in this publication can be found at https://github:com/JWerbrouck/ validator-bot/blob/master/example np consolid:trig 4.3
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 veri cation 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 elds is required. In the short term, a clear approach for delegating access will be devised. Especially in construction, stakeholders will be mainly o ces employing individuals. Although SHACL shapes might re ect this by integrating the delegation pattern directly, this would only solve the problem partly. Furthermore, use of web tokens may signi cantly 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 di erent 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 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 di er too much in content. 5
In this paper, we illustrated a basic method for pattern-based access control scenarios. Although multiple technologies already exist to perform ID- or rolebased access control, and for many use cases these technologies satisfy the requirements, pattern- (or context-)based access control has been identi ed 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 work ow was initiated in which not the identity of the client determines access to certain resources, but rather their properties as con rmed by trusted third parties. To a certain degree, 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 implementations, 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 eld. 6
This research is funded by the Research Foundation Flanders (FWO) in the form of a personal Strategic Basic (SB) Research grant (grant no. 1S99020N).