Add ADR Identity Matching and Subject Linking

[Nieuwlaar]

Thanks to @astridverhallen, @michelleludovici-ai and @malinnorlander

[gfour]

Which use case does the Photo ID requirement come from?

[malinnorlander]

Which use case does the Photo ID requirement come from?

One of the payment use cases

[malinnorlander]

Change NONs to nonce

[malinnorlander]

It should be added that the requirement to provide the identifier falls on the PID provider, not the MS. It is not as intrusive as requiring all MS to provide all citizens with a unique identifier from birth, it is the PID provider that creates a unique persistant identifier for all persons that request a PID from them.
Also, the identifier is already in the PID schema as optional, for WeBuild we are changing it to mandatory.

[malinnorlander]

Context should include that identity matching only applies to new users. Identity matching of persons in existing records is out of scope.

[SilkeThai]

Retrieving the photo from the German ID card, is currently only allowed for sovereign authorities, such as the police. Use cases from public sector or even private sector are currently prohibited for legal reasons. It is technically possible, but not legally.

[malinnorlander]

That is not a problem, only those that can will implement and test this option.

[oliver-fro]

In Germany there is no persistent unique identifier which can be used. There is only a persistent unique tax number which by law can only be used for tax purposes. Any other use is strictly forbidden.

So this ADR would in the end exclude German citizens who cannot present any unique identifier. Since no European citizen by law can be discriminated all use cases need to be open to European citizens who cannot present any unique and persistent identifier. Because of this I think, there are no use cases which require a persistent number by law. This law would be in violation of European law which prohibits the exclusion of other European citizens. There might be however some cases which only address the citizens of the member state in question. Like voting for parliament. In those cases where discrimination of other European citizens is allowed a persistent number might be required by law. If we want to address those striclty national cases with the exclusion of other European citizens, we should make this in clear terms.

Moreover, I think the rulebook for PIDs is clear. There is no mandatory data field for such an identifier. Even the optional fields only mention a unique but not a persistent administrative number.

I see that Marlin suggests that the identifier is issued by the PID provider and not the member state. For member states which also issue the PID this is of no difference. And as far as I know there are some member states which allow multiple private PID provider. I think that a unique persistent identifier will not be possible without legal action of the member state in question.

I suggest that only unique but not persistent numbers are mentioned. Unique numbers for every citizen may exist in all member states (like a passport number etc.). And then this data field has to be a mandatory field in the rulebook.

Regarding pseudonyms: I understand that this might help to identify a returning customer. Can't the same be achived by issuing an EAA by the relying party when the customer first registers? Like a customer card can help identify a returning customer. Then the pseudonym (like a customer number) is issued by the concerend relying party itself and not by the PID provider. If there is a wallet change the customer needs a new "digital customer card" and has to identify himself to the relying party in order to get a new EAA in the new wallet with the same old customer number (pseudonym). In that case there will be also only one pseudoym for every citizen and relying party.

[SarahGraefer]

I fully agree with the argumentation of @oliver-fro.

An universal pseudonym could theoretically be used to track user behavior across different Relying Parties. Shifting persistence to the EAA level ensures unlinkability, preventing the PID provider from profiling users across different services. By preventing cross-site tracking and adhering to the principle of purpose limitation, this model aligns much more securely with strict data protection regulations (such as GDPR). Decoupling persistence from the core identity provider allows Relying Parties to manage session lifecycles, revocations, and returning user workflows according to their specific technical and business requirements.

[malinnorlander]

In Germany there is no persistent unique identifier which can be used. There is only a persistent unique tax number which by law can only be used for tax purposes. Any other use is strictly forbidden.

So this ADR would in the end exclude German citizens who cannot present any unique identifier. Since no European citizen by law can be discriminated all use cases need to be open to European citizens who cannot present any unique and persistent identifier. Because of this I think, there are no use cases which require a persistent number by law. This law would be in violation of European law which prohibits the exclusion of other European citizens. There might be however some cases which only address the citizens of the member state in question. Like voting for parliament. In those cases where discrimination of other European citizens is allowed a persistent number might be required by law. If we want to address those striclty national cases with the exclusion of other European citizens, we should make this in clear terms.

Moreover, I think the rulebook for PIDs is clear. There is no mandatory data field for such an identifier. Even the optional fields only mention a unique but not a persistent administrative number.

I see that Marlin suggests that the identifier is issued by the PID provider and not the member state. For member states which also issue the PID this is of no difference. And as far as I know there are some member states which allow multiple private PID provider. I think that a unique persistent identifier will not be possible without legal action of the member state in question.

I suggest that only unique but not persistent numbers are mentioned. Unique numbers for every citizen may exist in all member states (like a passport number etc.). And then this data field has to be a mandatory field in the rulebook.

Regarding pseudonyms: I understand that this might help to identify a returning customer. Can't the same be achived by issuing an EAA by the relying party when the customer first registers? Like a customer card can help identify a returning customer. Then the pseudonym (like a customer number) is issued by the concerend relying party itself and not by the PID provider. If there is a wallet change the customer needs a new "digital customer card" and has to identify himself to the relying party in order to get a new EAA in the new wallet with the same old customer number (pseudonym). In that case there will be also only one pseudoym for every citizen and relying party.

There is a big difference in providing a unique persistent identifier as a PID provider and as a member state. For a PID provider to provide it only requires an additional attribute stored coupled to the PID. For a member state that doesn't already provide unique persistent identifiers to their citizens it is a rather huge undertake, which is why it isn't a suggestion. Germany is not excluded, neither is any other member state, as long as thay can produce a unique persistent identifier which is a simple technical task, it could just be an UUID.

Sweden requires a unique persistent identifier for all govermental eServices, as well as acess to hospital care, being able to request an invoice, so there are many examples where it is regulated by law. I think it is the same situation in Netherlands for their public sector body.

There is no point in having idetifiers that are not persistent, the whole point of the persistance is to be able to identify a unique person with it and if that identifier changes then there is no identity match any longer.

It is not the PID provider that issues pseudonyms, they just add a nonce as a new attribute in the PID. One psudonym per relying party is already a requirement on psudonyms. The psedonym is generated by the wallet of the user.

See: https://github.com/AltmannPeter/webuild-architecture/blob/08772f00b2b61ef37af133adf37d5598108bdc6b/adr/ar-pseudonyms.md

[malinnorlander]

I fully agree with the argumentation of @oliver-fro.

An universal pseudonym could theoretically be used to track user behavior across different Relying Parties. Shifting persistence to the EAA level ensures unlinkability, preventing the PID provider from profiling users across different services. By preventing cross-site tracking and adhering to the principle of purpose limitation, this model aligns much more securely with strict data protection regulations (such as GDPR). Decoupling persistence from the core identity provider allows Relying Parties to manage session lifecycles, revocations, and returning user workflows according to their specific technical and business requirements.

I think there might be a misunderstanding how pseudnyms are impleneted and their use. PID providers will not issue pseudonyms, they will add a nonce as an attribute used for generating pseudonyms, neither will there be one general pseudonym used at every relying party. Please see: https://github.com/AltmannPeter/webuild-architecture/blob/08772f00b2b61ef37af133adf37d5598108bdc6b/adr/ar-pseudonyms.md

[SarahGraefer]

I fully agree with the argumentation of @oliver-fro.
An universal pseudonym could theoretically be used to track user behavior across different Relying Parties. Shifting persistence to the EAA level ensures unlinkability, preventing the PID provider from profiling users across different services. By preventing cross-site tracking and adhering to the principle of purpose limitation, this model aligns much more securely with strict data protection regulations (such as GDPR). Decoupling persistence from the core identity provider allows Relying Parties to manage session lifecycles, revocations, and returning user workflows according to their specific technical and business requirements.

I think there might be a misunderstanding how pseudnyms are impleneted and their use. PID providers will not issue pseudonyms, they will add a nonce as an attribute used for generating pseudonyms, neither will there be one general pseudonym used at every relying party. Please see: https://github.com/AltmannPeter/webuild-architecture/blob/08772f00b2b61ef37af133adf37d5598108bdc6b/adr/ar-pseudonyms.md

Thanks for the clarification. But wouldn't issuing an EAA be easier and avoid the problems with ZKPs?

[SarahGraefer]

In Germany there is no persistent unique identifier which can be used. There is only a persistent unique tax number which by law can only be used for tax purposes. Any other use is strictly forbidden.
So this ADR would in the end exclude German citizens who cannot present any unique identifier. Since no European citizen by law can be discriminated all use cases need to be open to European citizens who cannot present any unique and persistent identifier. Because of this I think, there are no use cases which require a persistent number by law. This law would be in violation of European law which prohibits the exclusion of other European citizens. There might be however some cases which only address the citizens of the member state in question. Like voting for parliament. In those cases where discrimination of other European citizens is allowed a persistent number might be required by law. If we want to address those striclty national cases with the exclusion of other European citizens, we should make this in clear terms.
Moreover, I think the rulebook for PIDs is clear. There is no mandatory data field for such an identifier. Even the optional fields only mention a unique but not a persistent administrative number.
I see that Marlin suggests that the identifier is issued by the PID provider and not the member state. For member states which also issue the PID this is of no difference. And as far as I know there are some member states which allow multiple private PID provider. I think that a unique persistent identifier will not be possible without legal action of the member state in question.
I suggest that only unique but not persistent numbers are mentioned. Unique numbers for every citizen may exist in all member states (like a passport number etc.). And then this data field has to be a mandatory field in the rulebook.
Regarding pseudonyms: I understand that this might help to identify a returning customer. Can't the same be achived by issuing an EAA by the relying party when the customer first registers? Like a customer card can help identify a returning customer. Then the pseudonym (like a customer number) is issued by the concerend relying party itself and not by the PID provider. If there is a wallet change the customer needs a new "digital customer card" and has to identify himself to the relying party in order to get a new EAA in the new wallet with the same old customer number (pseudonym). In that case there will be also only one pseudoym for every citizen and relying party.

There is a big difference in providing a unique persistent identifier as a PID provider and as a member state. For a PID provider to provide it only requires an additional attribute stored coupled to the PID. For a member state that doesn't already provide unique persistent identifiers to their citizens it is a rather huge undertake, which is why it isn't a suggestion. Germany is not excluded, neither is any other member state, as long as thay can produce a unique persistent identifier which is a simple technical task, it could just be an UUID.

Sweden requires a unique persistent identifier for all govermental eServices, as well as acess to hospital care, being able to request an invoice, so there are many examples where it is regulated by law. I think it is the same situation in Netherlands for their public sector body.

There is no point in having idetifiers that are not persistent, the whole point of the persistance is to be able to identify a unique person with it and if that identifier changes then there is no identity match any longer.

It is not the PID provider that issues pseudonyms, they just add a nonce as a new attribute in the PID. One psudonym per relying party is already a requirement on psudonyms. The psedonym is generated by the wallet of the user.

See: https://github.com/AltmannPeter/webuild-architecture/blob/08772f00b2b61ef37af133adf37d5598108bdc6b/adr/ar-pseudonyms.md

In Germany there is no persistent unique identifier which can be used. There is only a persistent unique tax number which by law can only be used for tax purposes. Any other use is strictly forbidden.
So this ADR would in the end exclude German citizens who cannot present any unique identifier. Since no European citizen by law can be discriminated all use cases need to be open to European citizens who cannot present any unique and persistent identifier. Because of this I think, there are no use cases which require a persistent number by law. This law would be in violation of European law which prohibits the exclusion of other European citizens. There might be however some cases which only address the citizens of the member state in question. Like voting for parliament. In those cases where discrimination of other European citizens is allowed a persistent number might be required by law. If we want to address those striclty national cases with the exclusion of other European citizens, we should make this in clear terms.
Moreover, I think the rulebook for PIDs is clear. There is no mandatory data field for such an identifier. Even the optional fields only mention a unique but not a persistent administrative number.
I see that Marlin suggests that the identifier is issued by the PID provider and not the member state. For member states which also issue the PID this is of no difference. And as far as I know there are some member states which allow multiple private PID provider. I think that a unique persistent identifier will not be possible without legal action of the member state in question.
I suggest that only unique but not persistent numbers are mentioned. Unique numbers for every citizen may exist in all member states (like a passport number etc.). And then this data field has to be a mandatory field in the rulebook.
Regarding pseudonyms: I understand that this might help to identify a returning customer. Can't the same be achived by issuing an EAA by the relying party when the customer first registers? Like a customer card can help identify a returning customer. Then the pseudonym (like a customer number) is issued by the concerend relying party itself and not by the PID provider. If there is a wallet change the customer needs a new "digital customer card" and has to identify himself to the relying party in order to get a new EAA in the new wallet with the same old customer number (pseudonym). In that case there will be also only one pseudoym for every citizen and relying party.

There is a big difference in providing a unique persistent identifier as a PID provider and as a member state. For a PID provider to provide it only requires an additional attribute stored coupled to the PID. For a member state that doesn't already provide unique persistent identifiers to their citizens it is a rather huge undertake, which is why it isn't a suggestion. Germany is not excluded, neither is any other member state, as long as thay can produce a unique persistent identifier which is a simple technical task, it could just be an UUID.

Sweden requires a unique persistent identifier for all govermental eServices, as well as acess to hospital care, being able to request an invoice, so there are many examples where it is regulated by law. I think it is the same situation in Netherlands for their public sector body.

There is no point in having idetifiers that are not persistent, the whole point of the persistance is to be able to identify a unique person with it and if that identifier changes then there is no identity match any longer.

It is not the PID provider that issues pseudonyms, they just add a nonce as a new attribute in the PID. One psudonym per relying party is already a requirement on psudonyms. The psedonym is generated by the wallet of the user.

See: https://github.com/AltmannPeter/webuild-architecture/blob/08772f00b2b61ef37af133adf37d5598108bdc6b/adr/ar-pseudonyms.md

In Germany it is not a question of technical feasibility but a question of constitutional compliance. The German Federal Constitutional Court prohibits such a centralized, uniform identifier to protect citizens from becoming transparent. Legally, Germany is not allowed to do what Sweden does. It must find privacy-friendly, decentralized methods, such as sector-specific or rotating pseudonyms, to verify identities without leaving a permanent, universal trail. Also a PID provider, when it is not the member state itself, can not provide such an unique persistent identifier. It is unlikely that this constitutional challenge is unique to Germany.

[flo0x]

The statement "Should not be used as mandate attestations" should be revised to:
"Should not be used alone as a mandate attestation, but should be used in combination with other attestations."
From the Relying Party (RP) perspective, the process consists of three distinct elements:

1. Identification data (e.g., EUCC, UBO, Owner)
   These attestations are used solely to provide identification-related information.
2. Identity verification
   The verification of the person is always performed using an additional identity attestation (e.g., PID, Passport, mDL) and in same cases rleated to accepted identification means in the regulation
3. Authorization

Authorization is assessed based on the combination of the identification data and any additional mandate or authorization attestations.

a.From the legal perspective:
a. EUCC + PID
This combination is used to verify whether the individual is the legal representative of the company. Whether that legal representative is authorized to perform a specific business operation remains a business decision of the relying party and the company.
b. UBO information + PID/Passport
This combination is used for the identification and verification of the UBO, including UBO submission and compliance with AMLR requirements.

b.From the business perspective:
Additional attestations may be required depending on the use case, such as: Authorised Signatories
, EU PoA, PoA or PoR