Authorization

1. Purpose of the building block

This building block describes how to assess trustworthiness of parties involved in a transaction.

2. Concepts

2.1 Authentication, Trust and Authorization

The concepts Authentication, Trust and Authorization are closely related but not identical. To describe their relations, we assume that a party A wants to gain access to data owned by party B. During authentication, party A provides its identification and evidence of that identification. Such evidence could be passwords, two-factor id's, PKI-based certificates, or bio-metric data such as iris scans and finger prints. Party B evaluates the evidence and assigns a trust level to A. Based on this trust level, B assigns permissions to certain parts of the data. It will be clear that higher trust levels result in more permissions.

To assign a trust level, party B gathers data about party A. This data includes, but is not limited to, nature of the evidence (PKI certificates are trusted more than simple passwords). It can also include a reputation score built by A during previous interactions.

The following concepts (from the BDI Glossary) are particularly relevant in this building block:

3. Risks

Insufficient authorization may cause data leaks to parties that are not trusted.

4. Interlinkages with other building blocks

This building block has links to:

The Authorization building block uses information from these related building blocks to make a decision whether or not to trust a partner in a transaction.

5. Elements and their key functions

While entering into a transaction, each participant involved in the transaction will decide if it trusts the other party.

To make a decision on trust, the party will use relevant and available information. The BDI provides a framework for four input elements for this decision:

1. , one of it’s parent Associations or the root BDI Network.

2. of the digital identity of the party.

3. as provided by the Reputation Model.

6. Core design decisions

The four inputs for decision making are supported by the BDI trust input elements as follows.

6.1 Trust in case of a Data Service Provider acting on behalf of a Data Owner

A specific situation occurs when a Data Service Provider acts on behalf of a Data Owner. The Data Service Provider is assumed to have a business relationship with a Data Owner in which the rules for sharing data on behalf of the Data Owner are established. Beside the input elements that can be provided using the BDI Framework, a Data Service Provider and Data Owner can agree on other inputs used to make a trust decision.

7. Data Service Providers and Authorizations

Data Service Providers processes data on behalf of Data Owners. Data Owners should make a careful choice which Data Service Providers they use as they have to consent on the Terms & Conditions of the Data Service Provider. These could consists of generic Terms & Conditions of the Data Service Provider and additional Terms & Conditions for the specific data.

Data Service Providers should cater for adequate authorization capabilities to control which organizations / users have access to which data. These authorizations can be registered in an Authorization Register of the Data Service Provider.

8. Data Sharing Triggers

The sharing of data between organizations can be triggered by:

• Process steps which leads to the sharing of data. The data sharing is a side effect of the process flow. For example: a Transport Company receives a transport order from a Customer. Therefore the Transport Company needs access to the transport order data. The authorization for data sharing is an implicit result of the involvement in the business process.

• Providing explicit permission to share the data with another organizations. For example: the permission of a Terminal to share all container shipment related data with CBS.

9. Patterns for authorization evidence

Data Service Providers could use external information in an external Authorization Register (AR) under the control of the Data Owner to provide access. This external information can be retrieved using different patterns including:

• The permissions are synced between the AR and the Data Service Provider. The Data Service Provider holds a local copy which is used to provide access. Synchronization can be done by frequent polling or event updates.

• The (signed/sealed) permission is included in the data request from the Data Consumer. The Data Consumer has retrieved this permission from the Data Owner. Signing/Sealing is required to verify that the permission has been given by the Data Owner.

• The Data Service Provider polls the external Authorization Register at runtime during a data request to check the permission. In more complicated scenario’s Authorization Registers could refer to other Authorization Registers validating the chain of permission to it’s source.

10. Advantages and drawbacks

11. Guidance for trust decision making

It could be helpful to create a trust decision matrix, to improve manageability of decision rules. The approach would be:

1. classify data with a required assurance level (for instance low, medium, high),

2. assign required trust levels to an assurance level.

This could be done at a party's level or at an Association's level.

Example of a trust decision matrix:

Business rules could also consist of a combination of the various trust aspects. For instance that either medium association trust OR medium reputation trust is required.

12. Future topics & Case study

Future topics

• For improved discoverability of the parents of a BDI Association, the BDI Association Register could be improved by returning this information for every party lookup directly as part of the party information.

• To improve interoperability between associations, BDI might consider to define standardized rules for service/data classification and a best-practice approach for trust processing.

Case Study

13. Further reading

This building block has been drafted using the following sources, that provide opportunity for further reading: