5.1.2. Authorisation Evaluation

Authorisation addresses two different scenarios, intra-domain and inter-domain scenarios. Regarding the former, DCapBAC has been implemented. From this point of view, we have assessed different metrics with the objective of measuring the time to gran<sup>t</sup> access to a user to a specific resource, and also to measure the performance in terms of simultaneous connections.

Consider thePDP request, which is the XACML validation process that is performed by the PDP after receiving the authorisation request coming from the CM. This takes around 200 ms. The CT generation considers the previous task, and includes also the processing time required by the CM to issue a CT, which takes about 1.6 s. Finally, the overall authorisation process from the point of view of the clients from the moment they issue an authorisation request, to the moment they receive the authorisation answer together with the CT was measured with around 1.65 s. Since the token includes a validity period to the resources to be accessed, issuing a CT is not required for every access.

The DLT operates using Hyperledger Fabric framework with the Kafka consensus algorithm. The most essential and critical factor that affects the overall performance of a Blockchain network is the ordering service. Ordering service is a part of the consensus protocol. It generates a unique ordered sequence of transactions in a block and the block is delivered to nodes. We measured the Blockchain latency and throughput as the primary performance metrics for Blockchain, with various parameter settings of network size (number of ordering nodes) and block size (blocks committed to the Blockchain of each transaction). Ordering latency is the time a transaction needs to wait for the ordering service until its order in a block is assigned. Ordering throughput is the capacity the service can handle a certain number of transactions per second. Figure 15a,b show benchmark results of our Blockchain network. With small size network (7 ordering nodes), latency is very low (less than 0.5 s for 1000 concurrent clients). When the size of the network increases, the latency also increases (at size of 151 nodes, the latency at 1000 concurrent clients is 3 s). The same pattern for throughput performance. Throughput drops when network size grows (at size of 151 nodes, throughput at 1000 concurrent clients goes below 500 transaction/second). These benchmark results show the tradeoff between latency/throughput performance and network resilience against faulty requests. When the network size is larger it is more resilient to tolerate faulty nodes, however, it bears higher latency and lower throughput.

 **Figure 15.** Latency and throughput performance for Blockchain transactions.

Transactions

We have excluded the cost for the execution of transactions in the benchmark. Instead, we vary the block sizes which simulate various application scenarios in practice. Figure 15a,b show results at a typical block size of 100 bytes. For other block sizes, the patterns of latency and throughput hold the same. The overall performance of Blockchain network needs to consider also the transaction execution time, smart contract invocation time and transaction validation cost, which are application dependent.

(**b**) Throughput  for Blockchain

Transactions
