Consider a project for a Plant Owner/Operator handled by a number of EPC Contractors, with a large number of subcontractors, suppliers, authorities, etc, all producing data and all requiring data.

All will have Façades, and these Façades need to work together in a controlled manner. For security reasons we certainly do not want the entire Internet to have access to our data. Setting up an Intranet for that purpose is also not feasible, because all parties are involved in many (different) projects.

For that purpose a CPF for that project is defined. A CPF is a register of Façade URIs with information about access rights of any one Façade towards any of the other Façades in that CPF. The CPF server handles the user credentials and user restrictions for all idents in the CPF. However, each company in a CPF is responsible for the user rights to the data it owns. So each company gets one or more idents on the CPF server having administration rights, with which they can only handle the access rights to their own involved Façade(s).

When a SPARQL query is sent to a Façade, it is accompanied by the user credentials. The Façade checks the username and password by submitting them to CPF server, that returns the accessCode of a user. When a SPARQL query is being executed the accessCode shall be used. Only those templates that have that accessCode, or no accessCode at all, shall be returned. For extra security each template instance may have an accessCode. Only in case the query accessCode matches with the accessCode of selected template instances, those template instances may remain in that query result. Passing of the user credentials to a Façade and between a Façade and a CPF server shall be handled by use of the HTTP Basic authentication scheme and SSL.

The username and password in HTTP Basic authentication scheme are stripped from the https:// address code and encrypted along with the rest of the message. The data exchange under SSL is regarded safe.

However, since a Façade endpoint can be part in multiple CPFs, and since HTTP basic authentication handles only username and password, the name of the CPF must be given in the username too. The Façade has a list of the CPFs it participates in, and directs the verification to the appropriate CPF server.

In the CPF Server also a table shall be installed and maintained to define the handover route data shall follow, from their originating system Façade to its ultimate destination Façade, with all intermediate Façades. That table shall have three columns:

-   URI of sending Façade;

-   URI of receiving Façade;

-   AccessCode.

In case the AccessCode is not filled in the URI pair is applicable for all data, except for any other pair starting with the same URI for sending Façade where an AccessCode has been entered.