Authority Access Points
1. The AAP components shall enable the access of the competent authorities’ officers to the eFTI exchange environment and shall constitute an officer’s sole point of access to that environment.
2. An AAP shall perform the following functionalities:
(a)
authenticate the identity of the competent authority officers, or ensure the authentication of the identity of the competent authority officers;
(b)
authorise the request for access to eFTI data of the competent authority officers, based on their respective access rights stored in the authorisation registry, or reject the request if the competent authority officer has no active access rights registered;
(c)
register the authorised requests for access to eFTI data by issuing a unique identification number for each such request, and record at least the following information for each request:
(i)
identification references of the officer responsible for lodging the request;
(ii)
the UIL of the eFTI data to which access is requested, or the identifier or identifiers provided by the officer when lodging the request;
(iii)
the references to the access rights of the competent authority officer responsible for lodging the request, as recorded in the authorisation registry;
(iv)
the date and time at which the request was lodged;
(d)
transmit the authorised requests for access to eFTI data to the eFTI Gate for processing, by providing the following information:
(i)
the unique identification number of the request;
(ii)
the UIL of the eFTI data for which access is requested, or the identifier or identifiers provided by the officer when lodging the request;
(iii)
the references to the processing rights of the competent authority officer responsible for lodging the request, as recorded in the authorisation registry;
(e)
receive the responses to requests transmitted by the eFTI Gate and make these responses available to the competent authority officer responsible for that request via the user application;
(f)
keep an audit trail of the responses received for each request by logging at least the following information:
(i)
the unique identification number of the request for which the response was received;
(ii)
the date and time at which the response was received by the AAP;
(iii)
the date and time at which the response was forwarded by the AAP to the officer responsible for the respective request;
(g)
keep an archive of the requests for access to eFTI data and of the log of the received responses for a period of 2 years or, where national applicable provisions on the availability of evidence for the enforcement of the provisions for which access to eFTI data is required provide for a longer period of time, for that period of time;
(h)
when a follow-up communication in accordance with Article 3(4) is lodged, register the follow-up communication by issuing a unique identification number for the follow-up communication and record at least the following information for that follow-up communication:
(i)
identification references of the officer responsible for lodging the follow-up communication;
(ii)
the UIL of the eFTI data and the unique identification number of the request for access to that data for which the follow-up communication was lodged;
(iii)
the date and time at which the follow-up communication was lodged;
(iv)
the content of the follow-up communication;
(i)
transmit the follow-up communications to the eFTI Gate for processing, by providing the following information:
(i)
the UIL of the eFTI data and the unique identification number of the request for access to that data for which the follow-up communication was lodged;
(ii)
the content of the follow-up communication.
3. To provide the functionalities set out in paragraph 2, an AAP shall:
(a)
use appropriate electronic identification means that allow for reliable identification and authentication of the officers of the competent authorities, or that allow for verifying that the identification and authentication of those officers is ensured by another appropriate ICT component;
(b)
use an authorisation registry;
(c)
establish and maintain a secure connection to an eFTI Gate;
(d)
support a secure connection to the user application.
4. Member States may set up the AAPs either outside of the eFTI Gate, as part of existing ICT systems of their respective competent authorities, or integrated in their respective eFTI Gate.
Authorisation registry
Member States shall ensure that the rights of their competent authority officers to access and process eFTI data are recorded and kept up to date in an authorisation registry. The authorisation registry shall include, for each competent authority officer, at least the following:
(a)
unique identification references of the officer;
(b)
the access rights of the respective officer, expressed as the list of references of the Union and national legal acts that require the provision of regulatory information, in relation to which the respective officer has competences and, more specifically, as the list of the respective identifiers of the eFTI data subsets corresponding to those provisions, as established in Sections 3 and 4 of the Annex to Commission Delegated Regulation (EU) 2024/2024 ( 9 ) ;
(c)
the processing rights of the respective officer, expressed as coded references to the processing operations that the officer has the right to perform on each of the respective eFTI data subsets, in line with the applicable Union or national legislation determining the competences of that officer;
(d)
a log of the changes to the access and processing rights of that officer.
eFTI Gates
1. The eFTI Gates shall ensure, directly or via connection to other eFTI Gates, that:
(a)
the authorised requests for access to eFTI data are transmitted to the eFTI platform and contain the specific information requested;
(b)
for each such request, the response received from the respective eFTI platform is transmitted to the user application of the competent authority officer responsible for that request, either directly or via an AAP, as applicable; and,
(c)
when lodged, the follow-up communication to that request is transmitted to the eFTI platform that contains the eFTI data for which the request had been made and the response provided.
2. An eFTI Gate shall provide the following functionalities:
(a)
validate the request for access to eFTI data and, where lodged, follow-up communication, in one of the following ways:
(i)
when acting as ‘requesting Gate’, where the AAP is established as a separate component outside of the eFTI Gate, by verifying the security key of the AAP through which the request or follow-up communication was lodged;
(ii)
when acting as ‘receiving Gate’, by verifying the security key of the eFTI Gate from which it received the request or follow-up communication;
(iii)
when the validation of the security key of the respective eFTI Gate fails, by returning an error message to the ‘requesting Gate’, the AAP or the competent authority officer responsible for the request or follow-up communication, as appropriate;
(b)
process the request for access to eFTI data and, where lodged, follow-up communication, by means of the search mechanism in accordance with Article 8 and, on that basis, forward the request or follow-up communication, as applicable:
(i)
to the appropriate eFTI platform or eFTI Gate(s), when acting as ‘requesting Gate’;
(ii)
to the appropriate eFTI platform, when acting as ‘receiving Gate’;
(c)
keep an audit trail of all the requests for access to eFTI data or follow-up communications it has processed, by logging at least the following information:
(i)
the unique identification number of the request for access to eFTI data or of the follow-up communication;
(ii)
the identifier of the AAP or of the ‘requesting eFTI Gate’ from which it received that request or follow-up communication;
(iii)
the date and time it received that request;
(d)
validate the response received to a request it processed, as follows:
(i)
when receiving the response directly from the eFTI platform, by checking the security key and certification status of the eFTI platform, on the basis of the registry referred to in paragraph 3(e);
(ii)
when receiving the response from a ‘receiving eFTI Gate’, by checking the security key of that eFTI Gate on the basis of the registry referred to in paragraph 3(f);
(iii)
when the validation of the security key of the respective eFTI Gate or eFTI platform fails, by sending a corresponding error message to the ‘requesting Gate’, the AAP or user application of the competent authority officer responsible for the request, as applicable;
(e)
forward the response received to a request it processed through the same route, in reverse sequence, as the forwarded request, as applicable:
(i)
to the ‘requesting eFTI Gate’; or
(ii)
to the user application of the competent authority officer responsible for that request, directly or via the AAP;
(f)
when an acknowledgement of receipt of the request is received but no other response is received within 60 seconds of that acknowledgement, transmit a ‘no response’ message to the ‘requesting Gate’, AAP or user application of the competent authority officer responsible for the request, as appropriate;
(g)
keep an audit trail of all the responses to the requests for access it has forwarded, by logging at least the following information:
(i)
the UIL of the eFTI data set it received in response to that request;
(ii)
the unique identification number of the eFTI platform or ‘receiving eFTI Gate’ from which it received the response;
(iii)
the date and time it received that response;
(iv)
where no response was received, an indication to that end;
(h)
archive and keep available for auditing purposes the logs specified in points (c) and (g), for a period of 2 years or, where national provisions on the availability of evidence for the enforcement of the provisions for which access to eFTI data is required provide for a longer period of time, for that period of time.
3. To enable the functionalities referred to in paragraph 2, an eFTI Gate shall:
(a)
use a search mechanism, in accordance with Article 8;
(b)
establish and maintain a secure connection to the AAPs that mediate the access to the eFTI exchange environment of the competent authority officers of the Member State that established the respective eFTI Gate;
(c)
where the AAPs are established as integrated components to the eFTI Gate, establish and maintain a secure connection to the user application or applications, as applicable, of the competent authority officers of the Member State that established the respective eFTI Gate;
(d)
where AAPs are established as separate components to the eFTI Gate, establish and maintain an up-to-date registry containing the unique identification numbers and security certificates of those AAPs;
(e)
establish and maintain a secure connection to all the other eFTI Gates, as well as an up-to-date registry containing the unique identification numbers and the security certificates of those eFTI Gates;
(f)
establish and maintain a secure connection to all the eFTI platforms that received certification in the Member State or Member States that established the respective eFTI Gate, as well as an up-to-date registry containing the unique identification numbers, security keys and certification status of those eFTI platforms;
(g)
be able to use commonly defined services or artefacts, such as configuration, error codes, taxonomies or code lists in the eFTI exchange environment, where these services or artefacts are agreed in the framework of the network of operational support referred to in Article 13.
4. Where no conformity assessment body is accredited in a Member State to certify eFTI platforms in accordance with Article 11 of Regulation (EU) 2020/1056, that Member State shall ensure that its eFTI Gate establishes and maintains the secure connection and up-to-date registry, as referred in paragraph 3(f), for eFTI platforms that received certification from conformity assessment bodies accredited in other Member States. That Member State shall do so upon request from the economic operator or eFTI service provider operating that platform and after having requested and received confirmation from the Member State where the eFTI platform received the certification that it received no other confirmation request for that same eFTI platform from another Member State. That shall relieve the eFTI Gate of the Member State where the eFTI platform received the certification from the obligation to establish and maintain a secure connection to that platform.
User application
1. The user application shall enable a competent authority officer to interact with the AAP.
2. A user application shall provide at least the following functionalities:
(a)
generate the requests for access to eFTI data, based on the information provided by a competent authority officer, once the responsible officer has been duly identified, authenticated and authorised by the AAP;
(b)
receive and display for viewing by the competent authority officer responsible for the request the corresponding eFTI data provided by the respective eFTI platform(s) in response to that request or the ‘no response’ or error messages transmitted by the AAP or the ‘receiving eFTI Gate’;
(c)
enable other processing operations by the competent authority officer responsible for the request of the eFTI data received, in line with the processing rights of that officer;
(d)
where applicable national provisions allow, generate follow-up communications, based on the information provided by a competent authority officer.
3. To enable the functionalities referred to in paragraph 2, a user application shall, as a minimum:
(a)
provide the competent authority officers with a graphical user interface;
(b)
establish and maintain a secure connection to an AAP or an eFTI Gate, as applicable;
(c)
for data processing, use as reference the data subsets corresponding to the provisions of the Union and national legal acts, as established by Delegated Regulation (EU) 2024/2024, in relation to which the competent authority officers have competences.
Search mechanism
1. The search mechanism shall be a component integrated into an eFTI Gate that shall, as its main functionality, process the information included in the request or follow-up communication, as follows:
(a)
from the UIL of the eFTI data, retrieve the identifier of the eFTI platform that stores the eFTI data for which the request for access or the follow-up communication was made and, respectively, the identifier of the eFTI Gate to which that platform is connected;
(b)
when the request of information includes one or more of the identifiers set out in Article 11(3), search the registry of identifiers for a matching value and:
(i)
if a match is found, retrieve the active UIL or set of UILs connected to the respective identifiers, then process the information in the respective UILs in accordance with point (a);
(ii)
if no match is found, notify the eFTI Gate accordingly.
2. To enable the functionality referred to in paragraph 1, the search mechanism shall:
(a)
operate a registry of identifiers, in accordance with Article 11;
(b)
use a service metadata publisher (SMP) registry and a service metadata locator (SML) in accordance with the eDelivery specifications or a registry service with similar capabilities, to enable the discovery of the eFTI platforms, based on the information contained in the request or follow-up communication.
