Sign in

List of predefined identifier types

Because different IT-systems use different identifiers, and there is no single global identifier implemented across Telia, our service needs to work with more than one identifier. The party responsible for the data subject identification is the data controller.

This document provides guidance on the use anc choice of identifiers.

One usually categorise identifiers into a matrix comprising of 2 ranges:

  • strong vs weak
  • global vs local

Strong identifiers are unique across the entire lifetime of an identity, while weak identifiers may change ownership over time or simply cease to be.

Example of strong identifiers are Social Security Numbers or a company’s internal Customer ID. Weak identifiers are phone numbers, email addresses and names, which may not be “owned” by the same person over time and/or are not inherently unique in usage. This is not necessarily a universal truth though, some emails never change ownership and social security numbers can actually change in certain cases in certain countries.

Global identifiers stay the same across services while local identifiers stay the same within a set of local services or organisation.

Example of a global identifier is a person’s National Identification Number, while a local identifier could be a person’s Bank account number, which would only be identifiable and usable by the bank that assigned it to that person.

Guidance

  • IT Systems shall define preferably only one, globally unique, strong identifier that is needed for the requests. If more than one identifier is absolutely needed, then it is imperative that the controller ads multiple identifiers to an identity as aliases.
  • When using service specific identifiers, make sure this is unique across identities within a project for the whole lifetime of that identity.
  • In case of multiple possible identifiers, prefer always the strongest one.
  • Weak identifiers shall not be used at all, as there is a risk of data duplication and leakage to incorrect data subject when identification is unreliable.
  • Unidentifiable requests shall not be performed at all.
Identifier Type (URN) Comment/Description
National Identification Number urn:tdx:cc_national_id Country specific National Identification Number of the End-User. "cc" MUST be an ISO 3166-1 Alpha-2 country code in lowercase.

Examples:
no_national_id : Norwegian National Identity Number (Corresponds to "personnummer" in Norway)
sv_national_id : Swedish National Identity Number
fi_national_id : Finnish National Identity Number
dk_national_id : Danish National Identity Number
National Person ID of the End-User urn:tdx:cc_personal_id This is a reference to the no_national_id.
(Person ID is the id provided by "Det National Folkeregisteret" in Norway, corresponding national registry ids should be used in other countries if exists) "cc" MUST be an ISO 3166-1 Alpha-2 country code in lowercase.

Examples:
no_personal_id : Person ID provided by "Det National Folkeregisteret" in Norway
National Organisation Identifier urn:tdx:cc_organisation_id National government issued organization identifier. Used in context of OMB, One Man Business/Sole Trader identification
"cc" MUST be an ISO 3166-1 Alpha-2 country code in lowercase.

Examples:
no_organisation_id : Organisation ID provided by "Brønnøysundregisteret" in Norway

Other potential identifier types

This is a list of possible acceptable identifiers and types based on defined identification categories from personal data group types.

General personal identifiable information (urn:tdx:identification:pii)

Name, title, address (work and home), former addresses, emails, telephone number (work and home), IDs assigned by the controller.

Identifier Type (URN) Comment/Description
Email urn:tdx:identification:pii:email Email address
MSISDN (mobile) urn:tdx:identification:pii:msisdn Mobile Station International Subscriber Directory Number
IMSI (mobile) urn:tdx:identification:pii:imsi International Mobile Subscriber Identity
Internal account/user id urn:tdx:identification:pii:internal_id Internal account number or other globally unique identifier representing a data subject in internal systems.

Identification information assigned by government institutions, other than the national identification number (urn:tdx:identification:gov)

ID card number, passport number, driver’s license number, license plate number, etc. These identifiers are considered strong.

Identifier Type (URN) Comment/Description
Passport number urn:tdx:identification:gov:passport Passport number
Driver’s licence number urn:tdx:identification:gov:licence:driver Driver’s licence number

Electronic identification data (urn:tdx:identification:electronic)

IP addresses, cookies, connection moments, etc. Any other unique identifying number, characteristic or code that could identify an individual electronically.

Identifier Type (URN) Comment/Description
Card number urn:tdx:identification:electronic:cardnumber Credit/Debit card numbers
RFID tag urn:tdx:identification:electronic:rfid RFID tag

Biometrical identification data (urn:tdx:identification:biometric)

DNA data, finger and voice prints, iris scans, facial recognition, finger or hand shape recognition, dynamic signatures, etc. These identifiers are considered strong.

Identifier Type (URN) Comment/Description
Finger ID urn:tdx:identification:biometric:fingerid Fingerprint identifier
Face ID urn:tdx:identification:biometric:faceid Face scan identifier
Voice ID urn:tdx:identification:biometric:voiceid Voiceprint identifier

These weak identifiers should not be used:

Identifier Reason
IMEI It identifies device, but not who is using the device. In systems where IMEI is usually there is also IMSI or other mobile id. Also, user could sell his/her device at any point of time without informing this to Telia, therefore, IMEI can't be used as an reliable identifier to identify data subject.
Email Anyone can create any email address. Majority of the emails are provided by 3rd party service providers and there is no way to know if the data subject is really owning that email address, or did he/she just copy that from some received email or was it just guessed email address. Only in truly exception cases, like only emails managed and provided by the same company as the data subject identification, it could be considered, but even then, other choices should be looked. Data controller can't verify the ownership of the email address.

What to do if there is no identifier or identification is weak

If it is not possible to identify data subject at all or identification is not reliable, requests should not be executed. (Risk of data breach, ie exposing other data subject's data).