3. TO-BE

3.1 Overview of possible solutions

Process and thought behind 3 types of personas

1. Willing to cooperate, active person. With scenario 1 we may assume that we are living in an abundance of information if such information exists or can be created. A person is willing to share information necessary to make decision on the identity matching and is also assumed to be active in sharing that information. In this scenario the risk of NOT matching is leaving a person without their right to access the data about them and exercising their rights on that data.
2. Unwilling to cooperate, passive and resisting person. In scenario 2 we imagined an actor who does not actively want to connect identities one has in different countries. This may be for simple privacy concerns one has or that such matching would harm a person’s ability to perform intended actions now or in the future. Therefore, the identity matching decision might need to be made in lack of data. User intent on not cooperating may be not detected and even if detected the motivation will not be clear. The biggest risk in this scenario is NOT matching person to existing records and giving them unearned clean start.
3. State who is interested to have up to date records in their registries (population registry, social benefits applicants, tax declarations, etc.). The third scenario is meant to allow Member States to perform their duties and serve their residents. Law may either grant some benefits of take them away based on individual's activities and if these activities are performed in different Member State may not matter. People are either unaware that they should report something to a Member State, or they refuse to report that knowingly. Thus, matching people’s records bilaterally seems to include promise to mitigate several risks for states. The risk of incorrect matching and the risk of not finding a match when there really is one – both may have significant negative consequences due to the scale of the process.

Exresidence

QuickFix

Hard_EAA

Easy_EAA

eIDAS_0

eIDASNode+

E-services can operate based on local personal identification number.Defense

Hinting

Bonding

Binding

3.2 Description of highest potential solutions

1. eIDASNode+
2. Easy_EAA
3. QuickFix
4. Hard_EAA

3.2.1 eIDASNode+

Personas

• is a resident of country_A,
• has eID_A mean from country_A,
• has been awarded bachelor’s degree (diploma) at university_B located in country_B,
• wants to apply for master’s degree at university_A in country_A,
• is eager to improve his educational qualification and is thereof very co-operative (has no problem with submitting PII beyond eID scheme content).

• has e-service for submitting applications for admission to university,
• e-service users can authenticate with eID means supported by eIDAS node,
• must verify holding of bachelor’s degree,
• must match the identity of diploma holder with the identity of authenticated user.

• has e-service, which provides access to diploma records,
• e-service users can authenticate with eID means supported by eIDAS node,
• must match the identity of diploma holder with the identity of authenticated user.

• has access to PII data of country_A residents,
• has processes and logic in place for IdM,
• has access to data of matched identities, authority to create matches between identities and create new identity in country_A,
• has data exchange with IdM_B for sharing matching results involving identities of country_A and country_B,
• accepts and trusts matching results delivered by IdM_B, which involve identities of country_A and country_B.

• has access to PII data of country_B residents,
• has processes and logic in place for IdM,
• has access to data of matched identities, authority to create matches between identities and create new identity in country_B,
• has data exchange with IdM_A for sharing matching results involving identities of country_A and country_B,
• accepts and trusts matching results delivered by IdM_A, which involve identities of country_A and country_B.

Epic

User stories

Use cases

• University_B e-service authenticates user through eIDAS node and eID_A provider and receives identity attributes for eID_A.

• University_B e-service delivers eID_A attributes to IdM_B.
• IdM_B searches for existing matches between Id_A and Id_B.
• If not found, then IdM_B searches from Country_B registry match for Id_A. Match between Id_A and Id_B is created in Country_B registry and stored with Id_A attributes. IdM_A is notified about created match of identities and data is stored in Country_A registry.
• If no match is found, then IdM_B creates new Id_B in Country_B registry. Match between Id_A and Id_B is created in Country_B registry and stored with Id_A attributes. IdM_A is notified about created match of identities and data is stored in Country_A registry.
• IdM_B provides Id_B attributes to University_B e-service.

• User uploads the diploma as attachments to application.

• University_A e-service delivers eID_A attributes to IdM_A.
• IdM_A searches for existing matches between Id_A and Id_B.
• Existing match is found due to IdM_B having shared result of earlier matching process conducted with User’s identities.
• IdM_A confirms match of two identities and provides Id_B attributes to University_A e-service.

• Upon successful validation of IdM_A response and diploma records, User’s application is accepted.

3.2.2 Easy_EAA

Personas

• is resident of country_A,
• has eID_A mean from country_A,
• has eID_B mean from country_B,
• has been awarded bachelor’s degree (diploma) at university_B located in country_B,
• wants to apply for master’s degree at university_A in country_A,
• is eager to improve his educational qualification and is thereof very co-operative (has no problem with submitting PII beyond eID scheme content).

• has e-service for submitting applications for admission to university,
• e-service users can authenticate with eID means issued in country_A,
• must verify holding of bachelor’s degree,
• must match identity of diploma holder with the identity of authenticated user,
• has capability to process EAAs.

• has e-service, which provides access to diploma records,
• e-service users can authenticate with eID means issued in country_B,
• must match identity of diploma holder with the identity of authenticated user,
• has capability to process EAAs.

• has access to PII data of country_A residents,
• has processes and logic in place for IdM,
• has process for reliably pairing of eID means of two countries,
• has access to data of matched identities, authority to create matches between identities and create new identity in country_A,
• has data exchange with IdM_B for sharing matching results involving identities of country_A and country_B,
• accepts and trusts matching results delivered by IdM_B, which involve identities of country_A and country_B,
• issues matching results in format of EAAs.

• has access to PII data of country_B residents,
• has processes and logic in place for IdM,
• has process for reliably pairing of eID means of two countries,
• has access to data of matched identities, authority to create matches between identities and create new identity in country_B,
• has data exchange with IdM_A for sharing matching results involving identities of country_A and country_B,
• accepts and trusts matching results delivered by IdM_A, which involve identities of country_A and country_B,
• issues matching results in format of EAAs.

Epic

User stories

Use cases

• University_B e-service authenticates user through eID_B provider and receives identity attributes for eID_B.

• University_A e-service authenticates user through eID_A provider and receives identity attributes for eID_A.

• User uploads diploma as attachments to application.

• IdM_A searches for existing matches between Id_A and Id_B.
• If not found, then IdM_A searches from Country_A registry match for Id_B. Match between Id_A and Id_B is created in Country_A registry and stored with Id_B attributes. IdM_B is notified about created match of identities in format of EAA and data is stored in Country_B registry.
• If no match found, then IdM_A requests User through open session with University_A to authenticate with eID_B and eID_A in sessions under control of IdM_A. Once User has authenticated with both eID_B and eID_A in the session created by IdM_A the match between both identities is created. IdM_B is notified about created match of identities in format of EAA and data is stored in Country_B registry.
• IdM_A confirms match of identities and provides Id_B attributes to University_A e-service in format of EAA.

• Upon successful validation of IdM_A response and diploma records, User’s application is accepted.

3.2.3 QuickFix

Personas

• is resident of country_A,
• has eID_A mean from country_A,
• has been awarded bachelor’s degree (diploma) at university_B located in country_B,
• wants to apply for master’s degree at university_A in country_A,
• is eager to improve his educational qualification and is thereof very co-operative (has no problem with submitting PII beyond eID scheme content).

• has e-service for submitting applications for admission to university,
• e-service users can authenticate with eID means supported by eIDAS node,
• must verify holding of bachelor’s degree,
• must match the identity of diploma holder with the identity of authenticated user.

• has e-service, which provides access to diploma records,
• e-service users can authenticate with eID means supported by eIDAS node,
• must match the identity of diploma holder with the identity of authenticated user.

• has access to PII data of country_A residents,
• has processes and logic in place for IdM,
• has access to data of matched identities, authority to create matches between identities and create new identity in country_A registry,
• has data exchange with IdM_B for sharing matching results involving identities of country_A and country_B,
• accepts and trusts matching results delivered by IdM_B, which involve identities of country_A and country_B.

• has access to PII data of country_B residents,
• has processes and logic in place for IdM,
• has access to data of matched identities, authority to create matches between identities and create new identity in country_B registry,
• has data exchange with IdM_A for sharing matching results involving identities of country_A and country_B,
• accepts and trusts matching results delivered by IdM_A, which involve identities of country_A and country_B.

Epic

User stories

Use cases

• University_B e-service authenticates user through eIDAS node and eID_A provider and receives identity attributes for eID_A.

• University_B e-service delivers eID_A attributes to IdM_B.
• IdM_B searches for existing matches between Id_A and Id_B.
• If not found, then IdM_B searches from Country_B registry match for Id_A. Match between Id_A and Id_B is created in Country_B registry and stored with Id_A attributes. IdM_A is notified about created match of identities and data is stored in Country_A registry.
• If no match is found, then IdM_B initiates remote video identification session and directs User to facial image capturing procedure.
• User presents facial image.
• IdM_B system performs verification of captured facial image.
• IdM_B engages human operator in necessity for clarification of additional information.
• IdM_B creates new Id_B in Country_B registry. Match between Id_A and Id_B is created in Country_B registry and stored with Id_A attributes. IdM_A is notified about created match of identities and data is stored in Country_A registry.
• IdM_B provides Id_B attributes to University_B e-service.

• User uploads the diploma as attachments to application.

• University_A e-service delivers eID_A attributes to IdM_A.
• IdM_A searches for existing matches between Id_A and Id_B.
• Existing match is found due to IdM_B having shared result of earlier matching process conducted with User’s identities.
• IdM_A confirms match of two identities and provides Id_B attributes to University_A e-service.

• Upon successful validation of IdM_A response and diploma records, User’s application is accepted.

3.2.4 Hard_EAA

Personas

• is resident of country_A,
• has eID_A mean from country_A,
• has been awarded bachelor’s degree (diploma) at university_B located in country_B,
• wants to apply for master’s degree at university_A in country_A,
• is eager to improve his educational qualification and is thereof very co-operative (has no problem with submitting PII beyond eID scheme content).

• has e-service for submitting applications for admission to university,
• e-service users can authenticate with eID means supported by eIDAS node,
• must verify holding of bachelor’s degree,
• must match identity of diploma holder with the identity of authenticated user,
• has capability to process EAAs.

• has e-service, which provides access to diploma records,
• e-service users can authenticate with eID means supported by eIDAS node,
• must match identity of diploma holder with the identity of authenticated user,
• has capability to process EAAs.

• has access to PII data of country_B residents,
• has processes and logic in place for IdM,
• has access to data of matched identities, authority to create matches between identities and create new identity in country_A,
• has data exchange with IdM_B for sharing matching results involving identities of country_A and country_B,
• accepts and trusts matching results delivered by IdM_B, which involve identities of country_A and country_B,
• issues matching results in format of EAAs.

Epic

User stories

Use cases

• University_B e-service authenticates user through eIDAS node and eID_A provider and receives identity attributes for eID_A.

• University_B e-service delivers eID_A attributes to IdM_B.
• IdM_B searches for existing matches between Id_A and Id_B.
• If not found, then IdM_B searches from Country_B registry match for Id_A. Match between Id_A and Id_B is created in Country_B registry and stored with Id_A attributes. IdM_A is notified about created match of identities in format of EAA and data is stored in Country_A registry.
• If no match is found, then IdM_B creates new Id_B in Country_B registry. Match between Id_A and Id_B is created in Country_B registry and stored with Id_A attributes. IdM_A is notified about created match of identities in format of EAA and data is stored in Country_A registry,
• IdM_B confirms match of identities and provides Id_B attributes to University_A e-service in format of EAA.

• User uploads the identity matching EAA and diploma as attachments to application.

• Upon successful validation of EAA and diploma records, User’s application is accepted.

3.3 Suggestions for Nordic-Baltic region

1. How actually member state e-services would be able to smoothly start serving non-residents of a given member state regardless of the user being a returning user with changed residency or a new user?
2. How potential match between identities from different member states be made with the least amount of effort on the level of required assurance and following once only principle?

Actionplan to implement suggestions

• Define EAA standard to use and specify content (e.g. OpenID Connect for Verifiable Credentials (OIDC-VC) for electronic usage, but we do recommend PDF to support F2F interactions as well). Although the content of the attestation is not too complex, issues like data minimization and privacy preservation may lead to some difficulties. Standards that exist allow interpretations that do not guarantee interoperability on attribute level, so specific implementation must be agreed. Also, we note that the agreement must be ready to be changed as the maturity of eIDAS defined attribute attestation service evolves in coming years.
• Create common extension or use existing one to allow eIDAS Node to replace incoming identity with local one before reaching e-Service provider. Organizationally the identity matching data and the service that translates the foreign eID’s into locally acceptable ones, does not need to be bundled with eIDAS Node hosting, but that might ease the implementation. It is important that the service is usable by eIDAS Node and that is supported in the product lifecycle as an extension. This may need cooperation agreement with European Commission that is responsible for the building blocks development.
• Review national legislations for processing of personal data in terms, that would support deployment of once only principle and in justified use cases facilitate identity management processes in a user controlled manner. Initiate legal changes necessary for introduction of proposed procedural and technical activities.
• Agree on NBCM level that electronic identification of one’s resident on “high” level of assurance must be accepted as proof of identity on the same level as using physical identity documents from that country and to identify physical person, countries grant to each other similar rights and obligations what are contextually needed.
• Formalize sharing of the matched identity data between countries. Establish framework defining principles for identity matching process and acceptance of matched identities in Nordic-Baltic region. It should give requirements for:
  1. Accepted sources for identity attributes (e.g., eID means, identity documents, cross-border data exchanges between registries),
  2. Handling identity attributes (e.g., minimum data set, encoding of characters),
  3. Defining the level of assurance for results of identity matching process dependent of identity attributes’ sources and procedures in involved case,
  4. Data governance rules, protection, and mechanisms for supervision for data handling (e.g., notification to matched identity about established cross-border connection with other identity, enable users to view events accessing their data).

• Enable data exchange of attributes between countries, deemed necessary for identity matching process.
• Address the issue of derived personal identification number usage as value for person’s unique identifier delivered by eID schema in a cross-border context. Following EC published information there are several countries in Nordic-Baltic region, who implement such practice. Handling of derived personal identification numbers adds remarkable complexity layer to identity matching process and to usage of matching results, if created evidence does not contain personal identification number values that are operated domestically or communicated to other countries (i.e., receiving country specific derivation).
• Amend domestic legislation and processes so that creation of identities through digital process would be allowed. Currently persons accessing cross-border e-services without having an e-service provider’s domestic country’s personal identification number are queued in virtual “waiting rooms”. Passage through a virtual waiting room is granted only after completion of specific physical activities in receiving country. Digital transformation of physical procedures meets the aim of SDG regulation. Dependent of country specifics, the identities created through digital processes could have dedicated level of assurance or status in country’s identity management system.

What will the future safety concerns be for identity matching?

What will the future need for identity matching be and are the suggested solutions scalable?

Suggestions on how quality of data across countries can be improved

eIDAS revision implications

• Electronic Attestation of Attributes. Electronic Attestation of Attributes is seen as Trust Service in regulation, and it will create greater clarity on organizational and technical requirements for such services and attestations themselves. However, nothing prohibits Nordic and Baltic countries to use such methods already now. In principle this is document with e-seal confirming that identity data set of one member state belongs to the same person as identity data set from another member state. These e-seals must be trusted by the NBCM community. As there is e-seal issuance and handling in current regulation then agreement can be made based on this. It is important to note that lifecycle management of such attestations must be well thought through. Although it is assumed that identity matching is done once and the link between identities is persistent forever, then as the process is open to errors of different kinds, the need to revoke this link must be foreseen. Attestation is a digital document and is living independently of its issuer. The other attestation related concern might be data privacy. Attestation should include only a minimal set of user data, but enough that it is unique to the member state it originates from. Additionally, it is possible to create attestations that would only be usable to validate the claim of identity matching and that cannot be used to derive the identities it connects. We do see that such discussions must take place before launching the system, but there are solutions that allow to implement a politically agreed solution.
• eID scheme notification obligation. eIDAS’ new version foresees that all member state will have to notify an identity scheme and at least one such scheme should be on the level of assurance high. Although this statement may change but it at least now gives hope that there is a way to authenticate from every member state using the highest level of assurance through eIDAS node infrastructure. There is no statement however how many citizens of any country such scheme should cover, but in our proposals, we can assume that for willing participant such mechanism is available, and it is not discriminatory to request using such scheme to interact with identity matching service.
• Introduction of EU Identity Wallet. The introduction of the EU Identity Wallet (EUDIW) will change the landscape of e-services in coming years and may well compete for attention and budget for most other issues either this report or any other may address. Therefore, alignment of this change has been a burning issue for the research. Introduction of EUDIW as mandatory tool for authentication for public and private sector services creates incentives to leave central identity brokers such as eIDAS Nodes infrastructure. We have therefore envisaged the EAA model alongside the eIDAS Node extension. We see that the proposal allows smooth transition from one model to another. However, we do see that the shift that is planned creates an environment without identity data that could be matched, rather a lot of pseudonyms and only claims about attributes existence. That leaves the active and cooperative participant sometimes without proper support - because data is not available to help then but even more it hides the traces of these who did not want to be matched in the first place. It leaves no room for state-to-state cooperation. So based on that we also feel that our focus on the scenario of helping a person who seeks help and is supportive on the identity matching is best suited.

3.4 Suggestions for Member States

Denmark

• Creation of new Danish identities during digital process of identity matching is not supported and requires longer term principal preparations in legal and organizational aspects. Currently creation of new identities requires physical presence in Denmark. In addition, feasibility of this change is questioned, because in practice persons requiring Danish personal identification number (CPR) are usually already residing in Denmark.
• Easy_EAA could be complimenting eIDASNode+, as in use cases of migration persons can have eID means of two countries at their hand.
• Retrieval of additional attributes besides eID 4 mandatory ones deemed to be necessary.

Faroe Islands

• No EU notified eID scheme and has not integrated with eIDAS node yet.
• Creation of new identity requires change in identity management ecosystem.
• Retrieval of additional attributes besides eID 4 mandatory ones deemed to be necessary.

Greenland

• Return on investment will have a very poor score due to the very limited number of transactions that might require identity matching.

Estonia

• Adjusting legal framework.
• Integration works of API between identity matching solution and e-services.
• Handling of identity matching results with lower level than ‘High’ in terms of LoA.

Finland

• Retrieval of additional attributes (e.g., citizenship, ID-document number) besides eID 4 mandatory ones deemed to be necessary.
• Changes in legislation and development of systems is necessary. In addition, topics needs prioritization for resources to be allocated.
• Handling of derived personal identity numbers increases identity matching complexity.

Latvia

• Retrieval of additional attributes (e.g., citizenship, ID-document number) besides eID 4 mandatory ones deemed to be necessary.
• Creation of new identity during identity matching process requires legislative changes.
• Conclude data exchange agreements with most countries’ population registries.

Lithuania

• Accepting the identity matching results of other countries requires legislative and technological amendments.
• Levels of assurance for identity matching results require further analysis.
• e-services require significant time for adjustment to changes.

Norway

• Creation of identities for persons not residing in Norway requires changes in population registry.
• Appointing the owner of identity matching solution.

Iceland

• Legislation changes required.
• Creation of new identities during the identity matching process.
• e-services must adapt their business logic if matching results will have several levels of assurance, that do not align with currently established levels.