DE4A Cross-border Access Authorisation Registry (CAAR)

From DE4A
Revision as of 15:20, 14 February 2022 by Thasmee.karunaratne (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.3, 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): /IEMRequestMessage/Procedure/ProcedureCategory

Authorization Managing

The CAAR stores authorizations to be used in the AC authorization checking. A CAAR entry is an authorisation associated with a IDK provision, so the same user with permissions to manage IDK provision from a certain DO is also allowed to manage the DO’s authorisations. An authorisation in CAAR is represented by the next properties:

  • IDK Provision: Reference to the IDK provision that includes: (a) DO’s URI according to the DE4A policy for identifiers; (b) Canonical object type URI, either a canonical evidence type or a canonical event catalog according to the DE4A policy for identifiers.
  • DE’s URI, according to the DE4A policy for identifiers, or “any”.
  • Procedure category, according to the categories of administrative procedures considered by the SDG link repository and the directives included in SDGR Article 14, or “any”


In the extended version of the access control for evidence requests, the authorization may include the grounds for the request:

  • Request Grounds, one of:
    • EventNotification (token)
    • A LawELIPermanentLink (a valid link)
    • ExplicitUserRequest type (token)


Table 1: Categories of administrative procedures

# Cat. ID Procedure Category Proc. ID Procedure
1 R Birth R1 Requesting proof of registration of birth (SDG Annex II)[2].
2 S Residence S1 Requesting proof of residenceRequesting proof of residence (SDG Annex II).
3 T Studying T1 Applying for a tertiary education study financing, such as study grants and loans from a public body or institution (SDG Annex II).
4 T Studying T2 Submitting an initial application for admission to public tertiary education institution (SDG Annex II).
5 T Studying T3 Requesting academic recognition of diplomas, certificates or other proof of studies or courses (SDG Annex II).
6 U Working U1 Request for determination of applicable legislation in accordance with Title II of Regulation (EC) No 883/2004 (SDG Annex II).
7 U Working U2 Notifying changes in the personal or professional circumstances of the person receiving social security benefits, relevant for such benefits (SDG Annex II).
8 U Working U3 Application for a European Health Insurance Card (EHIC) (SDG Annex II).
9 U Working U4 Submitting an income tax declaration (SDG Annex II).
10 V Moving V1 Registering a change of address (SDG Annex II).
11 V Moving V2 Registering a motor vehicle originating from or already registered in a Member State, in standard procedures (SDG Annex II).
12 V Moving V3 Obtaining stickers for the use of the national road infrastructure: time-based charges (vignette), distance-based charges (toll), issued by a public body or institution (SDG Annex II).
13 V Moving V4 Obtaining emission stickers issued by a public body or institution (SDG Annex II).
14 W Retiring W1 Claiming pension and pre-retirement benefits from compulsory schemes (SDG Annex II).
15 W Retiring W2 Requesting information on the data related to pension from compulsory schemes (SDG Annex II).
16 X Starting, running and closing a business X1 Notification of business activity, permission for exercising a business activity, changes of business activity and the termination of a business activity not involving insolvency or liquidation procedures, excluding the initial registration of a business activity with the business register and excluding procedures concerning the constitution of or any subsequent filing by companies or firms within the meaning of the second paragraph of Article 54 TFEU(SDG Annex II).
17 X Starting, running and closing a business X2 Registration of an employer (a natural person) with compulsory pension and insurance schemes (SDG Annex II).
18 X Starting, running and closing a business X3 Registration of employees with compulsory pension and insurance schemes (SDG Annex II).
19 X Starting, running and closing a business X4 Submitting a corporate tax declaration (SDG Annex II).
20 X Starting, running and closing a business X5 Notification to the social security schemes of the end of a contract with an employee, excluding procedures for the collective termination of employee contracts (SDG Annex II).
21 X Starting, running and closing a business X6 Payment of social contributions for employees (SDG Annex II).
22 O Other 2005/36/EC Procedures under Directive 2005/36/ECof the European Parliament and of the Council of 7 September 2005 on the recognition of professional qualifications.
23 O Other 2006/123/EC Procedures under Directive 2006/123/EC of the European Parliament and of the Council of 12 December 2006 on services in the internal market.
24 O Other 2014/24/EU Procedures under Directive 2014/24/EU of the European Parliament and of the Council of 26 February 2014 on public procurement and repealing Directive 2004/18/EC.
25 O Other 2014/25/EU Procedures under Directive 2014/25/EU of the European Parliament and of the Council of 26 February 2014 on procurement by entities operating in the water, energy, transport and postal services sectors and repealing Directive 2004/17/EC.
26 O Other BUSnoSDG Procedures for business not included in SDGR Article 14(1) (IEM common types)[3]
27 O Other CITnoSDG Procedures for citizens not included in SDGR Article 14(1) (IEM common types)
Retrieved from ‘https://wiki.de4a.eu/index.php?title=DE4A_Cross-border_Access_Authorisation_Registry_(CAAR)&oldid=4481’