As part of the IDK, the Cross-border Access Authorization Registry (CAAR) stores access authorizations registered by the corresponding data owners to access their provisions. The CAAR is used by the Authorization Controller (AC) that allows checking access to a specific canonical evidence type or event catalog provided by a specific data owner (DO) and requested by a specific data evaluator (DE) to be used in the scope of a specific procedure category. The pair issuing authority and canonical object type -canonical evidence type or event catalog- identifies an IDK provision. Therefore, an authorization is a function of three parameters: requesting authority (DE), procedure category and IDK provision. The authorization could be extended to include legal grounds for requesting an evidence type.

Authorization Design Alternatives

According to Trusted Computer System Evaluation Criteria (TCSEC)[1], there are four divisions for criteria to assess system security policies:

D - Minimal protection (no security),
C - Discretionary protection,
B - Mandatory protection,
A - Verified protection (highest security level)

The AC is only a part of the system security policy to provide a mechanism to limit access to DO’s canonical object types.

We can identify different access control models:

Mandatory Access Control (MAC):

The strictest model. Each resource object is controlled by access settings defined by the administrator, so users cannot change these settings.
Each resource object is assigned a security label with two properties: security classification (top secret, confidential, public, etc) and availability level category (department, project, user).
Access permissions are controlled only by an administration.

Discretionary Access Control (DAC):

Every resource object has an owner controlling its access settings.
Each resource object is associated with an Access Control List that contains the list of users and groups with the level of access for each of them.
Users or groups may control access permissions.

Role-Based Access Control or Non-discretionary Access Control:

Access is based on the user’s role, i.e., their job function within the organization.
Users may belong to several groups but are assigned to only one role.
Users in a specific role may control access permissions.

Rule-Based Access Control (RBAC):

Access is based on a set of rules defined by the administration, which are stored in the Access Control List (ACL).
When a user or group wants to access a resource object, the system checks the rules stored in its ACL.
Access permissions are controlled only by an administration.
Attribute-Based Access Control (ABAC) or Policy-Based Access Control (PBAC) or Claims-Based Access Control (CBAC):
Access rights defined through the use of policies, which combine attributes of any type (e.g., user, resource, environment, timing attributes).

Example: The online store (resource owner) sells alcoholic beverages (resource) to consumers of a given age (attribute). The decision to grant a claim is made upon the user attribute.

Graph-Based Access Control (GBAC):

Access rights are defined using an organizational query language instead of total enumeration of roles or attributes.

The AC is using an Attribute-Based Access Control model for accessing DO’s evidence types and event catalogs, with attributes from the IEM request that identifies the DO and canonical object type (provision), the DE, the category of the procedure and, in the extended version, the legal grounds of the request.

Authorization Controller (AC)

According to the AC architecture introduced in D2.x [REF], there are two application components to enable the AC functioning: for managing the authorisations registered in the CAAR and for checking authorisations for a particular IEM request.

Authorization Checking

The AC implements the authorisation checking process that requires the information from the CAAR and from the corresponding IEM evidence or subscription request messages. The authorisation is related to the functional parties (i.e., DE and DO), but the technical parties (i.e., data requester (DR) and data transferor (DT)) are the ones who check if the evidence request can be responded to. IEM evidence and subscription requests specify which data evaluator is requesting a canonical object type from which data owner in the scope of a procedure of a certain category. IEM evidence requests also include the grounds of the request. Therefore, the authorization checking is to be incorporated into the system by its implementation in the DT’s connector component to prevent unauthorized access; using the authorization checking in the DR’s connector component can avoid sending abroad authorized requests.

In order to know whether an IEM evidence or subscription request has appropriate authorization, the following preconditions are required:

The IEM evidence or subscription request includes the URIs of the DE and DO involved.
The IEM evidence or subscription request includes the URIs of the requested object type -canonical evidence type or event catalog- and the category of the procedure that requires such an object.
The IEM evidence request includes the grounds of the request.

Authorizations are stored in the CAAR regarding the DO included in the IEM request. Otherwise, it is understood that such a DO does not limit the access to its provisions.
A DO’s authorization is stored in the CAAR for the canonical object type, the DE and procedure category included in the IEM request, or some of these parameters are set to “any”.

The authorisation checking could result in only one main flow for a specific IEM request. The flow can result in three possible outcomes:

R1 (Success): The IEM request is authorized to get the corresponding response.
R2 (Waiting for approval): Request for data access by a DO has not yet been processed.
R3 (Reject): The IEM request is not authorized to get the corresponding response.
R4 (Error): Technical error has happened during request processing.

The IEM request attributes used for defining authorizations are:

DO’s identifier: /IEMRequestMessage/DataOwner/AgentUrn

DE’s identifier

/IEMRequestMessage/DataEvaluator/AgentUrn

Canonical object type’s identifier, one of:

/IEMRequestMessage/ExchangeRequestItem/CanonicalEvidenceTypeUri

/IEMRequestMessage/EventSubscripRequestItem/CanonicalEventCatalogUri

Procedure Category (Table 1):

DE4A Cross-border Access Authorisation Registry (CAAR)

Contents