2022-02-24T01:29:03Z

Thasmee.karunaratne:

<<insert high-level diagram>>
{| class="wikitable"
|+Title
!Component
!Description
!Piloted?
|-
|[[DE4A Issuing Authority Locator (IAL)|IAL]]
|Issuing Authority Locator (IAL) component helps the Data Consumer (DC) to find out the issuing authority that can provide the required evidence within a particular country.
|Yes
|-
|[[DE4A Evidence Service Locator (ESL)|ESL]]
|Evidence Service Locator (ESL) helps the DC to locate the evidence service able to provide a canonical evidence from a particular competent issuing authority, along with the relevant evidence service characteristics
|Yes
|-
|[[DE4A Cross-border Access Authorisation Registry (CAAR)|CAAR]]
|Cross-border Access Authorisation Registry (CAAR) is the authorization controller that allows for checking access to specific evidence types initiated by a specific DC to a selected data owner (DO).
|No
|-
|[[DE4A Multilingual Ontology Repository (MOR)|MOR]]
|Multilingual Ontology Repository (MOR) provides a common understanding of the semantics and syntax of canonical evidence types, additional parameters of provisions, and code lists used for the cross-border evidence exchange, by describing all the terms that compose them.
|Yes
|-
|[[DE4A Information Exchange Model (IEM)|IEM]]
|The Information Exchange Model (IEM) provides the payload specification of the messages to be exchanged between competent authorities.
|Yes
|-
|[[Canonical Evidence]]
|Canonical Evidence is the ''canonical form of domestic evidence according to a common data structure and format''. DE4A has defined a canonical form for each of the evidence types required by the procedures involved in the cross-border evidence exchange.
|Yes
|}
According to the ''European Interoperability Framework'', <blockquote>'''Semantic interoperability''' ensures that the precise format and meaning of exchanged data and information is preserved and understood throughout exchanges between parties, in other words ‘what is sent is what is understood’. In the EIF, semantic interoperability covers both semantic and syntactic aspects:

* The '''semantic''' aspect refers to the meaning of data elements and the relationship between them. It includes developing vocabularies and schemata to describe data exchanges, and ensures that data elements are understood in the same way by all communicating parties;
* The '''syntactic''' aspect refers to describing the exact format of the information to be exchanged in terms of grammar and format.
</blockquote>In this sense, '''semantic interoperability agreements''' need to be set up and manage as part of the interoperability governance and the public service governance. In DE4A, there are concepts and information that need to have a common understanding and the semantic assets of the [[Information Desk]] implement the corresponding semantic interoperability agreements. The main concepts of such agreements and the components that implement them are:

* '''[[Canonical Evidence|Canonical evidence type]]''': canonical form for each evidence type that has been identified by the DE4A pilots as needed by their online procedures and issued by cross-border authorities. The full semantic description of the terms that compose each canonical evidence type is available trough the ''[[Multilingual Ontology Repository|DE4A Multilingual Ontology Repository (MOR)]]''.
* '''Provision''': availability of a data service according to a ''exchange pattern'' for issuing a ''canonical evidence type'' by a ''issuing authority (data owner)'' corresponding to an administrative territorial unit within a country. Each provision can also require some ''additional parameters'' for properly identity the data subject and the evidence. The full semantic description of provisions is available through the ''[[Issuing Authority Locator|DE4A Issuing Authority Locator (IAL)]],'' obtaining the provision information from an administrative territorial level or unit and a canonical evidence type. The additional parameters are semantically described in the ''[[Multilingual Ontology Repository|DE4A Multilingual Ontology Repository]].''
* '''Data Service Endpoint''': information for actually use of the data services that are part of the DE4A evidence exchange system. This information is available through the ''[[DE4A Evidence Service Locator (ESL)]]'', obtaining the data service endpoint information from a issuing authority (data owner) and a canonical evidence type. Besides, the ''DE4A Information Exchange Model (IEM)'' implements the semantic agreement for the exchange of business messages through the data services.
* '''Multilingual term''': term uniquely identified and semantically described from the semantic and the syntactic point of view for a common understanding. The meaning of a term is described in every EU official language through automatic translations from English or translations verified by national domain experts. The data type of a term can be a simple type (e.g. string) or a complex type; complex types are compose by other simple and/or complex types. A special complex type is either a canonical evidence type, or a set of additional parameters for a provision or a code list. The full semantic description of all the terms used in DE4A is available trough the ''[[Multilingual Ontology Repository|DE4A Multilingual Ontology Repository (MOR)]]''.
[[Category:Wip]]

2022-02-07T15:01:27Z

Thasmee.karunaratne:

DE4A Cross-border Access Authorisation Registry (CAAR)

2022-02-07T14:57:21Z

Thasmee.karunaratne:

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)[https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria], 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'''
{| class="wikitable"
!#
!Cat. ID
!Procedure Category
!Proc. ID
!Procedure
|-
|1
|R
|Birth
|R1
|Requesting proof of registration of birth (SDG Annex II)[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32018R1724#d1e32-36-1].
|-
|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/[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32005L0036 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/[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32006L0123 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/[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32014L0024 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/[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32014L0025 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)[https://github.com/de4a-wp3/IEM/blob/main/iteration2/common-types.xsd]
|-
|27
|O
|Other
|CITnoSDG
|Procedures for citizens not included in SDGR Article 14(1) (IEM common types)
|}

DE4A Semantic interoperability

2022-02-07T14:40:20Z

Thasmee.karunaratne:

<<insert high-level diagram>>
{| class="wikitable"
|+Title
!Component
!Description
|-
|[[DE4A Issuing Authority Locator (IAL)|IAL]]
|Issuing Authority Locator (IAL) component helps the Data Consumer (DC) to find out the issuing authority that can provide the required evidence within a particular country.
|-
|[[DE4A Evidence Service Locator (ESL)|ESL]]
|Evidence Service Locator (ESL) helps the DC to locate the evidence service able to provide a canonical evidence from a particular competent issuing authority, along with the relevant evidence service characteristics
|-
|[[DE4A Cross-border Access Authorisation Registry (CAAR)|CAAR]]
|Cross-border Access Authorisation Registry (CAAR) is the authorization controller that allows for checking access to specific evidence types initiated by a specific data evaluator (DE) to a selected data owner (DO).
|-
|[[DE4A Multilingual Ontology Repository (MOR)|MOR]]
|Multilingual Ontology Repository (MOR) provides a common understanding of the semantics and syntax of canonical evidence types, additional parameters of provisions, and code lists used for the cross-border evidence exchange, by describing all the terms that compose them.
|-
|[[Canonical Evidence]]
|Canonical Evidence is the ''canonical form of domestic evidence according to a common data structure and format''. DE4A has defined a canonical form for each of the evidence types required by the procedures involved in the cross-border evidence exchange.
|}
According to the ''European Interoperability Framework'', <blockquote>'''Semantic interoperability''' ensures that the precise format and meaning of exchanged data and information is preserved and understood throughout exchanges between parties, in other words ‘what is sent is what is understood’. In the EIF, semantic interoperability covers both semantic and syntactic aspects:

* The '''semantic''' aspect refers to the meaning of data elements and the relationship between them. It includes developing vocabularies and schemata to describe data exchanges, and ensures that data elements are understood in the same way by all communicating parties;
* The '''syntactic''' aspect refers to describing the exact format of the information to be exchanged in terms of grammar and format.
</blockquote>In this sense, '''semantic interoperability agreements''' need to be set up and manage as part of the interoperability governance and the public service governance. In DE4A, there are concepts and information that need to have a common understanding and the semantic assets of the [[Information Desk]] implement the corresponding semantic interoperability agreements. The main concepts of such agreements and the components that implement them are:

* '''[[Canonical Evidence|Canonical evidence type]]''': canonical form for each evidence type that has been identified by the DE4A pilots as needed by their online procedures and issued by cross-border authorities. The full semantic description of the terms that compose each canonical evidence type is available trough the ''[[Multilingual Ontology Repository|DE4A Multilingual Ontology Repository (MOR)]]''.
* '''Provision''': availability of a data service according to a ''exchange pattern'' for issuing a ''canonical evidence type'' by a ''issuing authority (data owner)'' corresponding to an administrative territorial unit within a country. Each provision can also require some ''additional parameters'' for properly identity the data subject and the evidence. The full semantic description of provisions is available through the ''[[Issuing Authority Locator|DE4A Issuing Authority Locator (IAL)]],'' obtaining the provision information from an administrative territorial level or unit and a canonical evidence type. The additional parameters are semantically described in the ''[[Multilingual Ontology Repository|DE4A Multilingual Ontology Repository]].''
* '''Data Service Endpoint''': information for actually use of the data services that are part of the DE4A evidence exchange system. This information is available through the ''[[DE4A Evidence Service Locator (ESL)]]'', obtaining the data service endpoint information from a issuing authority (data owner) and a canonical evidence type. Besides, the ''DE4A Information Exchange Model (IEM)'' implements the semantic agreement for the exchange of business messages through the data services.
* '''Multilingual term''': term uniquely identified and semantically described from the semantic and the syntactic point of view for a common understanding. The meaning of a term is described in every EU official language through automatic translations from English or translations verified by national domain experts. The data type of a term can be a simple type (e.g. string) or a complex type; complex types are compose by other simple and/or complex types. A special complex type is either a canonical evidence type, or a set of additional parameters for a provision or a code list. The full semantic description of all the terms used in DE4A is available trough the ''[[Multilingual Ontology Repository|DE4A Multilingual Ontology Repository (MOR)]]''.