This post is one in an ongoing series (starting here) in which I am developing the concept of ‘Informational Identity’. Your name, your legal identities, your digital identities, are all the same kind of thing: information tools created to pick you out of a crowd, to refer to you when you are not present, to bind your will to virtual worlds. These Informational Identities are related to each other in a directed graph whose nodes are privilege domains and whose edges are the authentication by the ‘tail’ nodes of credentials issued by the ‘heads’ for the credentials’ secondary purpose: demonstrating that the issuers were satisfied at the time of issue that they knew who you were.
The relationship between a user seeking access to a gated resource or privilege domain, and, once granted access, exercising their privileges, and the owner of the domain is obviously asymmetrical.
Privacy issues around personal identity information are born out of that asymmetry.
As I’ve described in the thread of posts leading here, the user may be required to divulge personal identity information in order to be credentialed, either to establish a unique identity record in the domain, to use with third parties to vet their identity, or to gate access based on age, gender, or other personal identity attributes.
But once the credential (consider several as a single aggregate credential) has been issued, their digits are no longer logically necessary to exercise that access. The credential binds the individual to their privileges. Sometimes the credential itself may contain personal identity data accessible to a third party.
At a base level, the user may ask questions, issue commands, and send notifications without the domain needing their personal information. (Remember, however, that it may be possible for the domain to infer identity information from the device and method of access.)
To receive notifications, though, the user has to supply some kind of communication key, some kind of unique address in a communication channel. Those addresses are themselves personal identity information. If the user wants to receive notifications – or coupons, or products, or candygrams – in person, by ground mail, voice, text, or email – they have to supply those addresses.
Achieving a particular goal in a domain may require the user to divulge data. If the user wants to buy something, they will have to provide a credit card number or checking account number and the personal data needed to validate the payment method. If they want their horoscope read, they will have to provide their birth date (and hour if they know it – you can’t do a proper horoscope without it : ).
The domain could prompt the user each time personal identity was needed transactionally, then immediately discard it. So under the banner of convenience, the personal identity attribute snapshots are frequently stored.
To recap, the user may be required to divulge their digits when they apply for access to a resource or privilege domain. Their personal identity data may be on or in the credential itself. They may be required to divulge their personal data to effect a particular transaction, or to receive communications, goods or services. They may choose to have the domain persist their personal information for convenience, so they don’t have to re-enter it for future transactions.
The domain owner’s perspective is very different.
The domain owner may want personal identity data at registration as part of gating access and ensuring the user is unique within their domain.
They may also have access to it, even if they don’t require it, when the user presents credentials for proofing.
The domain may attempt to infer the user’s personal identity information from the mechanism of their access, such as Caller ID or the MAC id and IMSI from a smartphone.
If the domain owner wants to proactively communicate with the user, they need to persist their communication keys, their addresses. Some of those keys, such as ground mail, require names as well. If they don’t persist the keys, they can only communicate with the user when the user is actually in session in their domain. Even then, depending on the domain, the user may not be readily accessible, leaving the point where the credential is authenticated as the opportunity for communication.
In addition to requiring personal identity data to effect some transactions, the domain owner may be obligated by law or contract to persist those transaction records for some period of time.
If the domain owner wants to analyze their users’ behavior, they have to persist transaction and interaction records (e.g. system of record and system of engagement records) over time.
For some sites, such as Facebook, the data gathered is valuable enough for them to offer the domain access itself for free.
Domain owners may want to sell your personal identity data to others.
To interact with trading partners about their users, the domain owner may require personal identity data for matching individuals, effecting transactions, or both.
The domain may be in a jurisdiction that governs why, how, and how long they may persist personal identity attribute snapshots, and when, how and to whom they may communicate them.
So now the lines are drawn – we have modeled the basic user-domain owner relationship and its asymmetries. Next time we will step back, look at the Informational Identity map we have made so far, and see how its features structure the current dialog about personal identity privacy. Stay tuned.
Health IT Architect 