Culture neutral replacement for the "social-security-number" credential type

[ChlorideCull]

Summary

The name "social-security-number" is very US specific, while presumably the credential type will be used for all kinds of government issued personal ID numbers, and not just for US citizens.

I propose replacing it with the more neutral "national-identification-number", which seems to be the commonly acceptable generic equivalent.

Details

No response

Proposed Feature Type

Format

Proposed Feature Name

No response

Related Content

No response

[Progdrasil]

This is reasonable, we noticed this as well and we're in the process of renaming it to national-identity-number.

[LikeLakers2]

My only concern with national-identity-number is that an SSN was not originally meant to be an ID number, nor was it designed to be one. Thus, while the USA does currently use SSNs as a national ID number, some users might still be confused as to how to treat national-identity-number when it comes to the USA.

[Vogeltak]

My only concern with national-identity-number is that an SSN was not originally meant to be an ID number, nor was it designed to be one. Thus, while the USA does currently use SSNs as a national ID number, some users might still be confused as to how to treat national-identity-number when it comes to the USA.

Thanks for the feedback! For context, this specific name (whether we call it national-identity-number or social-security-number) isn't directly seen by users. The importing and exporting credential providers use it to signal the type of credential they are exchanging so they can handle and store it correctly for the user. The credential providers choose how to ultimately display the contents of the credential in their respective apps.

[LikeLakers2]

@Vogeltak Perhaps the word "users" in "some users might still be confused" was the wrong choice. My apologies for the mix-up.

What I meant when I said "users", are the people programming the importing and exporting ends of credential providers. Those folks may be confused by what to use when sending an entry they know is an SSN, because SSNs were not being originally designed to be national identity numbers (despite being used as one anyways). Thus, they may mark an SSN entry as something else than national-identity-number.

I hope that clarifies what I meant.

---

As an aside, I'll admit my concern is more of a technicality than anything else. Chances are, if the issue comes up, there will be some sort of internal conversation which will likely end with "Use national-identity-number."

Plus, I imagine this is an issue easily fixed by documentation (such as mentioning SSNs when describing the national-identity-number type of credential).

Still, I felt it worthwhile to bring up.

[Vogeltak]

@LikeLakers2 ahh sorry, misunderstood what you were trying to say.

We'll be specifically calling out the SSN situation in the credential type description to establish context for implementors, and that should probably clear it up :)

[Firstyear]

I think https://fidoalliance.org/specs/cx/cxf-v1.0-wd-20241003.html#enum-credential-type you should add the Queensland(Australia) CRN (Customer Reference Number) here too. Passport number or TFN (Australian Tax File Number) would be useful too.

[Vogeltak]

@Firstyear Thanks for the suggestion! We're currently reworking this credential type a bit; splitting it up into separate types for identity documents, passports, and probably one for "identification numbers" as well. Tax identification numbers (of all sorts) and the CRN would then best fit in that new credential type (identification-number), while full identity documents (passports, id cards) would have their own separate types (with all of their respective additional fields).

Let me know if you see any problems with that for your use cases!