Discussion on having `CodiceFiscale` as PID claim

[balanza]

This is an ongoing discussion about whether we handle the Italian tax code, CodiceFiscale*, as a PID claim. This is a subject that brings concerns about implementation, UX, privacy, normative references, adoption, and interoperability across member states as well as the assessment of the actual Italian scenario.

We must balance our choices between having an EU-interoperable solution and being pragmatic about having the IT Wallet operative in Italy. So far, many entities in Italy use CodiceFiscale as a unique identifier for a user.

Let's use this issue to keep track of any idea/concern we have.

---

(*) For non-italian readers: in Italy CodiceFiscale is a reversible code that is associated with a citizen and acts as both a health insurance number and a tax code. For historical reasons, it also became a de facto unique identifier for citizen in both public and private sector.

[balanza]

So far we are shipping our PID with CodiceFiscale into the tax_id_code claim (ref). We chose this to help Italian Relying Parties correlate the interacting user with an entity of their database - which is usually identified by CodiceFiscale.

This approach is less interoperable as only PID emitted in Italy can ship CodiceFiscale.

Another approach would be to consider CodiceFiscale as an attribute of a (Q)EAA. We already have this attribute on the Tessera Sanitaria credential, which is on a plan to be shipped. The implications are:

1. The Relying Party must require Tessera Sanitaria to be presented when the CodiceFiscale is needed
2. The User must obtain Tessera Sanitaria before interacting with the Relying Party

This flow reflects the actual User experience (they require the emission of a physical Tessera Sanitaria card along with their ID card); it also allows for cross-state interoperability as non-italian users can still require the emission of a Tessera Sanitaria credential (which is something they do now when they need to interact with Italian public entities).

[peppelinux]

We agreed that attribute tax_id_code is optional and will be provided within the italian domestic PID until the digital Health Card (tessera sanitaria) would not be provided in the form of a EAA.

RP that will to obtain the tax_id_code should request both the PID and the digital Health Card (where the tax_id_code would resides if issued by an italian EAA Provider)

standing on what we already have in the PID the account linking with the PID must be done with the unique_code and could be done with the tax_id_code as well, until the born the the Health Card EAA Provider

[balanza]

We agreed that attribute tax_id_code is optional and will be provided within the italian domestic PID until the digital Health Card (tessera sanitaria) would not be provided in the form of a EAA.

Health Card as a credential is confirmed to be available with the public beta of the project, so I would take it for granted.

I'd rather choose one of the two options:

1. We keep the tax_id_code in the PID and in the Health Card. _Rationale: it's handy for the Users as we know the Italian ecosystem relies heavily on tax_id_code_
2. We assume tax_id_code to be on Health Card only Rationale: we shrink the dataset on PID, which is a good design principle for future EU interoperability

My preference is for 1 because it better addresses IT Wallet needs, but I'm open to that. I'd just avoid temporary workarounds as there is no urgency or benefit.

[peppelinux]

I'm in favor of the first option and that having it as optional in the PID would help the future deletion of it when the health card credential will be consolidated

[fmarino-ipzs]

@peppelinux @balanza it seems to me that we can close the issue as we already have tax_id_code in our PID data model (option of your comment). Is it fine with you?