Contents
1. Introduction
The Commission Implementing Regulation (EU) 2022/1463 sets the requirements for user authentication, identity and evidence matching as follows:
- the Evidence Requesters shall rely on the Regulation (EU) No 910/2014 to authenticate the users,
- the Evidence Providers or intermediary platforms who are responsible for the identity and evidence matching, may require users to reidentify and reauthenticate for this purpose and shall ensure that evidence is only exchanged provided conditions of Article 16(2) are met.
To support the above requirements, the architecture of the OOTS should:
- rely on the reuse of the eIDAS nodes for user authentication,
- foresee that Data Service Directory will include information about the level of assurance of the electronic identification means notified by Member States required for the exchange,
- enable the transmission in an evidence request of attributes of the user, or the user and the representative, together with the level of assurance of the electronic identification means used by the user.
Because the Evidence Requesters shall rely on the Regulation (EU) No 910/2014 to authenticate the users, the user would be asked by the Online Procedure Portal to authenticate with an eID means issued under an eID scheme notified in accordance with eIDAS. (reference Article 11, (EU) 2022/1463). The person identification data retrieved following this authentication enable the identity of natural, natural representing legal or legal person. The eIDAS attributes included in the notification process will have the same level of assurance as the eID means used by the user in eIDAS authentication. After consulting the Data Service Directory and following the explicit request of the user to use OOTS the evidence request is built containing the attributes of the user, or the user and the representative previously obtained by the Online Procedure Portal.
When processing evidence requests, the Data Service needs to make sure that the user, acting directly or through a representative, has access only to evidences related to that specific user.
Therefore, identity and evidence matching on the Data Service side can be performed based on:
- the received attributes of the user, the mandatory attributes of the eIDAS minimum data set as defined by Commission Implementing Regulation (EU) 2015/1501, OR
- may require the user to reauthenticate taking into account the Data Service requirements for authentication.
The Data Service must ensure that the user attributes received in the evidence request match the attributes held by them.
To be noted that there may be other cases which would require re-authentication on the side of the Data Service.
2. Evidence requesters - user authentication and use of eIDAS
2.1 Use of eIDAS attributes in OOTS
The Article 11 of (EU) 2022/1463 requires that the authentication on the Evidence Requester side is done using an eID means issued under an eID scheme notified under eIDAS Regulation (Regulation (EU) No 910/2014)). To be noted that if the eID scheme used has been issued by the Member State of the Evidence Requester, in this case there would not be a cross-border eIDAS flow. Following the authentication on the Evidence Requester side, the eIDAS attributes that can be used are the attributes of natural, natural representing legal or legal person.
The Annex of the Commission Implementing Regulation (EU) 2015/1501 lists the attributes of the eIDAS minimum data set. The list is comprised of mandatory attributes, attributes which must always be requested and provided, and optional attributes ("additional attributes") which may be provided if available. Other attributes beyond the minimum data set, referred to as "sector specific" in section 2.7. Sector specific attributes of eIDAS Attribute Profile - Version 1.2, may be described by Member State and domain experts and further included in the eIDAS Node metadata.
In addition to the mandatory attributes of the eIDAS minimum data set, the Online Procedure Portal may request optional attributes of the eIDAS minimum data set and/or sector specific attributes that may be made available via the eID scheme used, if it is allowed by the national law and if the user gives their consent for this purpose. This is usually done in order to increase the success rate of identity and record matching done on the side of the Online Procedure Portal. Only the mandatory attributes of the eIDAS minimum data set shall be included in the evidence request, with the exception of the Unique Identifier if it is derived receiving Member State specific.
The eIDAS means used in the eIDAS authentication has a Level of Assurance which will be linked to the eIDAS assertion. This Level of Assurance will be included in the evidence request.
Neither the evidence requester nor the evidence provider shall store or use the person identification data, beyond the scope expressed in the consent for the purposes of the evidence request.
Figure 1. Person identification data used in OOTS
2.2 Mandatory attributes of eIDAS minimal data set for Natural Persons
Mandatory attributes of the eIDAS minimum data set must always be requested and provided during the eIDAS authentication.
Attribute (Friendly) Name | eIDAS MDS Attribute | ISA Core Vocab Equivalent | Notes |
|---|---|---|---|
| FamilyName | Current Family Name | cbc:FamilyName | Encoded as xsd:string |
| FirstName | Current First Names | cvb:GivenName | Encoded as xsd:string |
| DateOfBirth | Date of Birth | cvb:BirthDate | Encoded as xsd:date |
| PersonIdentifier | Unique Identifier | cva:Cvidentifier | Encoded as xsd:string |
Mandatory attributes of the eIDAS minimum data set for Natural Persons, eIDAS SAML Attribute Profile V1.2. , 31 August 2019
These attributes will be further included in the evidence request, with the exception of the Unique Identifier if it is derived receiving Member State specific. For more information on the Unique Identifier see the next section.
2.3 eIDAS Unique Identifier
Identity matching is typically done by looking up and matching the identity received with the identities registered. For this purpose, the eIDAS Unique Identifier (eIDAS UID) can only be directly used if it is already known by the Evidence Provider. This may be true in cases where the Evidence Provider has already linked the eIDAS UID to a known identifier or has access to such record.
The eIDAS UID is a mandatory attribute, and its definition is defined in the eIDAS SAML Attribute Profile.
Extract from eIDAS SAML Attribute Profile v1.2., 31 August 2019
"The unique identifier consists of:
1. The first part is the Nationality Code of the identifier
- This is one of the ISO 3166-1 alpha-2 codes, followed by a slash (“/“))
2. The second part is the Nationality Code of the destination country or international organization
- This is one of the ISO 3166-1 alpha-2 codes, followed by a slash (“/“)
3. The third part a combination of readable characters
- This uniquely identifies the identity asserted in the country of origin but does not necessarily reveal any discernible correspondence with the subject's actual identifier (for example, username, fiscal number etc)
Example: ES/AT/02635542Y (Spanish eIDNumber for an Austrian SP)"
Figure 2. Figure 2 from eIDAS SAML Attribute Profile v1.2., 31 August 2019
Some Member States issue an outbound identifier for each Member State, which is also usually derived. This means that the third part of the Unique Identifier, the combination of readable characters, may not have the same value for all requesting Member States. Taking the above example, the identifier for the user authenticating in Austria can be "ES/AT/02635542Y", however, when authenticating in Belgium, it would not only have a different Nationality Code of the destination country, but also a different third part, resulting in, for example: "ES/BE/03835542X".
This means that in such cases, the eIDAS UID (PersonIdentifier) was issued for the specific context of the Online Procedure Portal and it cannot be used by the Data Service. In this case the Online Procedure Portal should not send the Unique Identifier to the Data Service.
How these outbound identifiers are generated, is specific to each Member State and/or eID means. The derivation process could potentially make it challenging even for a matching function from the issuing Member State to identify the user based only on this identifier. Additional attributes may be needed.
The information on the Unique Identifier, if it is derived and/or receiving Member State specific is communicated during the notification procedure and in the following resource. This information could be requested to the eIDAS Cooperation Network and configured accordingly. More examples on how Unique Identifier could be used by a Data Service and its matching service can be found in section 6. Examples Unique Identifier and Data Service identity matching (Informative).
2.4 eIDAS optional and sector/additional specific attributes for Natural Person
In cases where the mandatory attributes of the eIDAS minimum data are not sufficient to identify a unique user, identity matching may need to rely on other attributes.
Users can reduce the ambiguity and therefore increase the likelihood of unambiguous record matches by agreeing to exchange more attributes.
Optional attributes of the eIDAS minimum data set if they are available, may be requested by the Online Procedure Portal in order to increase the success rate of identity and record matching. The decision to request these attributes belongs to the Online Procedure Portal and may be based on the national identity matching requirements.
These optional attributes would not be further sent as part of the evidence request to the Evidence Provider.
Attribute (Friendly) Name | eIDAS MDS Attribute | ISA Core Vocab Equivalent | Notes |
|---|---|---|---|
| BirthName | First Names at Birth | cvb:BirthName | Encoded as xsd:string |
| BirthName | Family Name at Birth | cvb:BirthName | See above re birth names |
| PlaceOfBirth | Place of Birth | cva:BirthPlaceCvlocation | See above re birth names |
| CurrentAddress | Current Address | cva:Cvaddress | Encoded as multiple xsd:string elements |
| Gender | Gender | cvb:GenderCode | Encoded as xsd:string with a restriction of selection: Male, Female, Unspecified |
Optional attributes of the eIDAS minimum data set for Natural Person, eIDAS SAML Attribute Profile V1.2., 31 August 2019
(eIDAS-provided) Sector specific/additional attributes (non eIDAS minimum data set) that can be provided via eIDAS could similarly be requested in order to increase the success rate of identity and record matching provided that the user has given her/his consent. The Online Procedure Portal could request these attributes but they would not be sent further to the Evidence Provider as part of the evidence request.
The sector specific attribute schema must be defined and published in-line with section 2.7. Sector Specific Attributes of eIDAS SAML Attribute Profile, currently at version 1.2. More information on all eIDAS available attributes of pre-notified and notified eID schemes can be found here.
2.5 eIDAS attributes for Legal Persons
Mandatory attributes of the eIDAS minimum data set must always be requested and provided during the eIDAS authentication.
Attribute (Friendly) Name | eIDAS MDS Attribute | ISA Core Vocab Equivalent | Notes |
|---|---|---|---|
| LegalName | Current Legal Name | cvb:LegalName | Encoded as xs:string |
| LegalPersonIdentifier | Uniqueness Identifier | cvb:Cvidentifier | Encoded as xs:string |
Mandatory attributes of the eIDAS minimum data set for Legal Person, eIDAS SAML Attribute Profile V1.2., 31 August 2019
In addition to these mandatory attributes, section 2.3.1 of the eIDAS SAML Attribute Profile v1.2 lists eight optional attributes that MAY be supplied by a MS if available and acceptable to national law.
| Attribute (Friendly) Name | eIDAS MDS Attribute | ISA Core Vocab Equivalent | Notes |
|---|---|---|---|
| LegalAddress | Current Address | cva:Cvaddress | Encoded as multiple xsd:string elements |
| VATRegistration | VAT Registration Number | cva:CvbusinessCode | Encoded as xsd:string |
| TaxReference | Tax Reference Number | cva:CvbusinessCode | Encoded as xsd:string |
| BusinessCodes | Directive 2012/17/EU Identifier | cva:CvbusinessCode | Encoded as xsd:string |
| LEI | Legal Entity Identifier (LEI) | cva:CvbusinessCode | Encoded as xsd:string |
| EORI | Economic Operator Registration and Identification (EORI) | cva:CvbusinessCode | Encoded as xsd:string |
| SEED | System for Exchange of Excise Data (SEED) | cva:CvbusinessCode | Encoded as xsd:string |
| SIC | Standard Industrial Classification (SIC) | cva:CvbusinessCode | Encoded as xsd:string |
Optional attributes of the eIDAS minimum data set for Legal Person, eIDAS SAML Attribute Profile V1.2., 31 August 2019
The processing of mandatory and optional attributes for legal persons is done analogously to the processing of mandatory and optional attributes for natural persons.
Only the mandatory attributes of the eIDAS minimum data set are sent in the evidence request.
For more information on using the OOTS for evidences related to legal persons, see 2.3 - Representation - Q4 2022.
2.6 eIDAS attributes for Natural Person representing Legal Person
Article 3(1) of the Regulation (EU) No 910/2014 allows the case of representation, in particular "natural person representing a legal person”. Because in reality there are more cases of representation, the eIDAS Technical subgroup has been requested by the eIDAS Cooperation Network to amend the technical specifications to include all the cases of representation.
Figure 4. Section 2.8. NATURAL AND LEGAL PERSON REPRESENTATIVE from eIDAS SAML Attribute Profile V1.2., 31 August 2019
Even if the representative attributes MUST not be explicitly requested, the eIDAS response MAY however return one representative attribute set in case of representation.
The representative attributes follow the specifications of natural person (2.2 Mandatory attributes of eIDAS minimal data set for Natural Persons) and legal person (2.5 eIDAS attributes for Legal Persons) as described in the eIDAS SAML Attribute Profile V1.2., 31 August 2019 and they need to be pre-fixed with "Representative".
3. Evidence providers - identity and evidence matching
3.1. Authentication
In the context of the SDG, identification and authentication of the user serve two separate purposes:
- to use the procedure;
- to use the once-only technical system to retrieve a particular piece of evidence.
Identification and authentication performed by the Online Procedure Portal for the purpose of using OOTS must use electronic identification schemes that have been notified by a Member State in accordance to Regulation (EU) No 910/2014. If the access to the procedure has been granted without the fulfillment of this requirement, the Online Procedure Portal must ask the user to authenticate taking into account the previously mentioned requirements before using OOTS.
The Online Procedure Portal includes the mandatory attributes of the eIDAS minimum data set retrieved during the eIDAS authentication at the Online Procedure Portal side in the evidence request to be sent to the Evidence Provider. The same applies when a national eID scheme notified under eIDAS is used (no cross-border eIDAS flow). This information should be accompanied by the level of assurance of electronic identification means used. The Unique Identifier shall not be sent if it is Member State specific as explained in section 2.3. Unique Identifier.
3.2. Re-authentication by the Evidence Provider
This version of the OOTS provides a 4.9 - Evidence Preview - Q4 2022 feature in which the user interacts, using redirection, with a service provided by, or on behalf of, the Data Service, and therefore a service offered from the Member State of the Evidence Provider. The component offering the service is called Preview Space. As the operation of the Preview Space is coordinated with the operation of the Data Service, the Preview Space has access to all identity attributes provided by the user that are included in the evidence request. At this stage, the Preview Space and Data Service need to determine if the personal identification data provided is sufficient for the purposes of identity matching or if there is the need to re-authenticate. To be noted that the requirement for re-authentication is defined by the Data Service and it may include criteria beyond the identity attributes exchanged in the evidence request. When re-authentication is required, the principles set by article 6 of Regulation (EU) No 910/2014 must be enforced. This means that the user would be asked to re-authenticate using one of the below options:
- eID schemes from the Member State of the Evidence Provider, which are deemed adequate for the access to the Evidence Providers' services. This includes both notified and non-notified eID schemes.
- eID schemes notified by other Member States in accordance to Regulation (EU) No 910/2014.
When re-authentication occurs, the Data Service must ensure that the person identification data received match the attributes held by them as follows:
| Type of person | Checks performed |
|---|---|
| Natural person | MUST ensure that the identity and record matching, was done based on the same value of the First Name, Last Name and DoB; |
| If the Unique identifier is sent and is processable, it MUST perform additional checks in the process or following the re-authentication and identity matching on the Data Service side. | |
| Legal person | MUST ensure that the identity and record matching, was done based on the same value of the LegalName, LegalPersonIdentifier (if sent); |
| Natural person representing legal person | MUST ensure that the identity and record matching, was done based on the same value of LegalName, LegalPersonIdentifier (if sent) of the represented |
| MAY perform additional checks on the attributes of the representative (First Name, Last Name and DoB) if the Data Service hold this information and the access policy requires it. | |
| If the Unique identifier of the representative (natural person) is sent and is processable it MUST perform additional checks in the process or following the re-authentication and identity matching on the Data Service side. |
If the process of identity matching does not result in a match, an error message MUST be generated and an error report is sent back to the Evidence Requester.
4. Sample attribute collection and evidence exchange flow
The following diagram shows the ways in which the eIDAS attributes are collected. It covers all steps that prepare to collect attributes on the side of MS A. These attributes are made available for further processing steps (not shown in this diagram) by the Data Service and Preview Space.
The following table describes the various steps.
| Step | Description |
|---|---|
| 1-2 | User chooses to authenticate with eIDAS in order to get access to the Online Procedure Portal. |
| 3-4 | The user is requested to select the Member States who issued the electronic identification means he/she would like to use for authentication. The user makes a choice. NOTE: The Member States selection is for the case when the electronic identification means is issued by another Member State, a Member State other than the one of the Online Procedure Portal. |
| 5 | Based on the requested attributes and LoA, the user is presented the option(s) for electronic identification schemes and/or electronic identification means. |
| 6-8 | The user is asked to consent the exchange of requested attributes and the user confirms. The user selects one of the electronic identification means issued by an eID scheme notified in accordance with Regulation (EU) 910/2014. The Online Procedure Portal MAY request all available attributes that can be made available by the elD scheme that issued the eID means that the user selected. The available attributes are listed in the Proxy-Service metadata, and it should be requested provided that it is allowed by the national law and that the user has given her/his consent. |
| 9-10 | The user is requested by the eID scheme to authenticate. The authentication process depends on the eID means selected. |
| 11-13 | The user is successfully authenticated using electronic identification means notified in accordance with Regulation (EU) 910/2014 and the Online Procedure Portal receives (natural or legal) person identification data. This MUST include the mandatory attributes of the eIDAS minimum data set and, if available and approved by the user for exchange, optional and/or sector specific attributes. Depending on the national implementation of the eIDAS node and identity matching service, the Online Procedure Portal may receive additional national specific person identification data, e.g. a national registration number. NOTE: For simplicity reasons, the identity matching service and the eIDAS node Member State specific part have been depicted as a single component - eIDAS Node (MS A). The additional attributes beyond the mandatory attributes of the minimum data set are not sent in the evidence request. |
| 14 | The Online Procedure Portal consults the Data Service Directory to find if there are additional attributes beyond the the minimum data set laid down in accordance with Commission Implementing Regulation (EU) 2015/1501, that need to be specified in order to facilitate the identification of the relevant evidence provider. The Online Procedure Portal received the list of additional attributes which have to be provided by the user for the purpose of the identification of the evidence provider. |
| 15 | If there are any additional attributes beyond the mandatory attributes that are needed for the identification of the evidence provider, ask the user to provide them. The user provides the additional attributes. NOTE: All mandatory attributes of the eIDAS minimum data set must be provided. Therefore if any of these attributes are not available, the user must be re-authenticate with an eID means issued by an eID scheme notified under eIDAS. |
| 16-17 | With the user's input and consent, the Online Procedure Portal adds all the person identification data to the evidence request and sends this request to the Data Service. |
5. Examples Unique Identifier and Data Service identity matching (Informative)
A Data Service may be faced with some of the following cases when performing the identity and record matching:
NOTE
In the below scenarios and examples, where referring to the Unique Identifier being derived or not, known or unknown, it should be understood as the "the third part a combination of readable characters" of the PersonIdentifier, and it is based on the information provided during notification process and summarised here: https://ec.europa.eu/digital-building-blocks/sites/x/pSQIBQ
When the Unique Identifier is referred to as receiving Member State specific, it means that the identifier changes for each country.
The list of examples is not exhaustive and other cases may exist.
NOTE
In the below examples, the Unique Identifier has been retrieved during the eIDAS authentication on the Online Procedure Portal side.
The Online Procedure Portal is from Member State B and the Data Service is from Member State A.
The eID used by the user may be issued by Member State A, Member State B or Member State C, depending on each example.
Figure 3. Unique Identifier various examples
| # | Derived (YES/NO) | Unique Identifier (YES/NO) | Member State specific (YES/NO) | eID means issued by | Description |
|---|---|---|---|---|---|
| 1 | NO | YES | NO | Member State different from the Member State of the Data Service | Unique Identifier is non-derived and it is known by the Data Service Example: User is using an eID means issued by Member State C which uses as Unique Identifier a national personal identification code, without derivation.
Following a previous interaction of the user with the Data Service or its matching function, this identifier is known by the Data Service. Therefore, it doesn't matter in which Member State the Online Procedure Portal is, the eIDAS authentication request will retrieve the Unique Identifier which is known by the Data Service or it's matching function. |
| 2 | NO | NO | NO | Member State different from the Member State of the Data Service | Unique Identifier is non-derived but it is not known by the Data Service Example: User is using an eID means issued by Member State C which uses as Unique Identifier a national personal identification code, without derivation.
However, as the user has never linked this identity to his/her records in the Member State of the Data Service, the Unique Identifier is not known by the Data Service or its matching function. Therefore, even if the Data Service receives the non-derived Unique Identifier, simply by using this identifier and the other mandatory attributes of the minimum data set , it would not be able to do the identity match. Additional attributes would be needed, similar to the process used nationally for linking the different identities. |
| 3 | YES | YES or NO | NO | Member State of the Data Service | Unique Identifier is derived, not receiving Member State specific and it has been issued by the Member State of the Data Service Example: User is using an eID means issued by Member State A, which has a derived identifier but which is not receiving Member State specific.
The Data Service is also in Member State A, but as the Unique Identifier is not receiving Member State specific, it does not matter from where the request for evidence is made, as the same Unique Identifier would be returned. Depending on the derivation methodology, the Data Service or its matching function may be able to directly perform the identity match or it may require additional person identification data beyond the mandatory minimum data set. The eIDAS Unique Identifier may or may not be known by the Data Service Provider, depending on the national implementation of the management of Unique Identifiers and if the user is registered with the Data Service. |
| 4 | YES | YES or NO | YES | Member State of the Data Service | Unique Identifier is derived, receiving Member State specific and it has been issued by the Member State of the Data Service Example: User is using an eID means issued by Member State A, which is a derived identifier and which is receiving Member State specific.
The Data Service is also in Member State A, but unlike case 3, the Unique Identifier received would depend on the Member State of the Online Procedure Portal. Depending on the derivation methodology, the Data Service or its matching function may be able to directly perform the identity match or it may require additional person identification data beyond the mandatory minimum data set. The eIDAS Unique Identifier may or may not be known by the Data Service Provider, depending on the national implementation of the management of Unique Identifiers and if the user is registered with the Data Service. |
| 5 | YES | YES or NO | NO | Other Member State than Member State of the Data Service and Online Procedure Portal | Unique Identifier is derived, not receiving Member State specific and not issued by the Member State of the Data Service or Online Procedure Portal Example: Data Service is in Member State A, Online Procedure Portal is from Member State B and eID means is issued by Member State C.
The Unique Identifier is derived, but since it is not receiving Member State specific, the same Unique Identifier would be issued for requests made from Member State A and B. Therefore, if the user has in the past linked her/his identity at the Data Service or its matching function, when receiving the evidence request, the Data Service should be able to perform the identity match. If she/he has not linked her/his identity, this identifier is not known and additional attributes would be needed, similar to the process used nationally for linking the different identities. |
| 6 | YES | YES or NO | YES | Other Member State than Member State of the Data Service and Online Procedure Portal | Unique Identifier is derived, receiving Member State specific and not issued by the Member State of the Data Service or Online Procedure Portal Example: Data Service is in Member State A, Online Procedure Portal is from Member State B and eID means is issued by Member State C.
Unlike the previous case, the Unique Identifier is derived and receiving Member State specific, therefore the Unique Identifier received by the Online Procedure Portal, is specific to Member State B and cannot be used in Member State A of the Data Service. Therefore, even if the user has in the past linked her/his identity at the Data Service or its matching function, the Unique Identifier cannot be used and additional attributes would be needed, similar to the process used nationally for linking the different identities. |
| 7 | YES | YES or NO | NO | Member State of the Online Procedure Portal | Unique Identifier is derived, not receiving Member State specific and is issued by the Member State of the Online Procedure Portal Example: Data Service is in Member State A, Online Procedure Portal is in Member State B, eID means is issued by Member State B.
When authenticating at the Online Procedure Portal, since the authentication is using a national eID means, even if in the context of OOTS it has to be an eID means notified under eIDAS, the eIDAS infrastructure and its components are most likely not used. The Online Procedure Portal may receive a Unique Identifier that is nationally specific and therefore, when creating the evidence request it should ideally send the identifier that it is meant to be used for the context of the Data Service. In this case, it is a derived identifier but which is not receiving Member State specific, so it would be the same value no matter the Member State of the Data Service. If the identifier sent by the Online Procedure Portal is the same as the one issued when making an eIDAS request from Member State A, and the user has linked her/his identity, the Data Service should be able to perform the identity match. If this identifier sent by the Online Procedure Portal is the same as the one issued when making an eIDAS request from Member State A, but the user has not linker her/his identity, the Data Service would need additional attributes, similar to the process used nationally for linking the different identities. |
| 8 | YES | YES or NO | YES | Member State of the Online Procedure Portal | Unique Identifier is derived, receiving Member State specific and it is issued by the Member State of the Online Procedure Portal Example: Data Service is in Member State A, Online Procedure Portal is in Member State B, eID means is issued by Member State B.
When authenticating at the Online Procedure Portal, since the authentication is using a national eID means, even if in the context of OOTS it has to be an eID means notified under eIDAS, the eIDAS infrastructure and its components are most likely not used. The Online Procedure Portal may receive a Unique Identifier that is nationally specific and therefore, when creating the evidence request it should ideally send the identifier that it is meant to be used for the context of the Data Service. In this case, it is a derived identifier which is also receving Member State specific, so it should provide a different identifier depending on context of the Data Service. If this identifier sent by the Online Procedure Portal is the same as the one issued when making an eIDAS request from Member State A, and the user has linked her/his identity, the Data Service should be able to perform the identity match. If this identifier sent by the Online Procedure Portal is the same as the one issued when making an eIDAS request from Member State A but the user has not linker her/his identity, the Data Service would need additional attributes, similar to the process used nationally for linking the different identities. |
For the last two cases, where the eID means is issued by the Member State of the Online Procedure Portal, the Online Procedure Portal should have available the possibility to retrieve and provide a UniqueIdentifier, to the Data Service. This should cover also the cases where the eIDAS UniqueIdentifier is derived and receiving Member State specific.