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.
In my last post, we started looking at how the asymmetry we have discovered in Informational Identity in the relationship between an individual and a gated privilege domain owner structures personal identity privacy issues. We looked at privacy issues that arise from the instrumentation, observation, and reporting of personal identity information in granting and exercising access to a privilege domain.
In this post, we will look at privacy issues that obtain around the domain owner’s persistence and use of the personal identity information they acquire.
First let’s recap the different contexts for the domain owner’s acquisition of personal identity data.
- They may ‘see’ it when the user presents credentials for proofing, if those credentials happen to contain it.
- They may infer it at proofing, authentication, or engagement from the communication method used, such as Caller ID or the MAC id and IMSI from a smartphone.
- They may ask for it at proofing to validate the presented identity with third parties such as Lexis Nexis or Equifax.
- They may ask for it at registration to determine the user is unique in their privilege domain.
- They may request the user’s communication keys, their unique addresses in a communication space such as email, telephone, or street address, at registration or during engagement in order to communicate to the user. Some of those keys require the user’s name as well as the key itself.
- They may request personal identity information in order to be able to process a financial transaction and provide the user the goods or services acquired.
- They may request personal identity information in order to match the identity against other identities in their domain, or in their trading partners’ domains.
Now that we know when the can ‘see’ it, let’s look at why and when they want or need to persist it.
Of the acquisition contexts above, there are only a couple where the domain owner may need to persist the personal identity data.
If they need to communicate to the user while the user is not in session, they have to persist communication keys.
Offhand it seems like the times when they must be able to communicate offline are few and far between. When would that be? If a home security system with monitors streaming telemetry to the cloud detected a kitchen fire, the user would not only prefer the domain owner to be able to communicate offline, it must be in the service contract.
Let’s generalize that: when there is a formal or informal agreement between the user and the domain owner that requires offline communication, the domain owner would need to persist the communication information in order to comply.
If the domain executes a transaction under contract to provide a good or service, they may be required by one or more laws to persist information about that transaction, including personal identity information.
Any other times the domain has to persist the personal data?
If they ‘see’ it in the presented credentials at proofing, they can choose not to look at it, let alone persist it. If they have the ability to infer it at registration or during engagement they don’t have to use that ability. They may ask for it at proofing to use it with third party proofing services vendors.
In all three of those cases, the domain could either not look at, or use then throw out, the personal identity data. They might want to both look at it and keep it for access security reasons – it can help them identify and assess risks that the user is nefarious or the user account has been compromised.
And as we descibed in an earlier post, a credential need not contain personal data accessible to the domain owner. If your birthdate was not on a driver’s license, but only an ID number, you could still use it to buy alcohol if there were a service the bartender could use to verify that ID number is over the state’s legal drinking age. But the most common proof-of-identity credentials used do contain personal data: birth certificates, driver’s licenses, state ID cards, and passports.
With respect to asking for identity data at registration to determine a user is unique in their domain, obviously whatever data is used to make the determination must be persisted in the domain and acquired from the current user. That does not have to be a full name, address, serial number and hat size thing. The domain could persist only the identifiers of the credentials presented at proofing, for example.
For other matching purposes, such as across internal operational systems, or with third parties, at first it seems like once a match has been determined, the domain owner could discard the identity data. The problem with that is that matching is not a one-time activity. Every time new identities are added to either system, or personal identity attributes are updated, new matching is required.
For transaction processing, a domain could ask a user for necessary personal data, such as the card number, expiration date, CSC/CVD/CVV code, name and billing zip code for a credit card, use it, then discard it. They may be required to persist some part of the transaction-related data by law or by contract. A user might also prefer the domain persist the data for convenience to save them having to re-enter it for future transactions.
Once they have acquired and persisted personal identity data, how can a domain use it?
The domain owner may analyze their users’ behavior, using the dimensions of personal identity data such as age, gender, address as well as the explicit transactional and engagement data they gather about that individual. They may supplement that data with third party data, using identity matching to ‘marry’ the data sets. They may send the data to a third party to do the analytics. They may sell the data, their analysis, or both.
As we discussed in the last post, there is a patchwork of overlapping law and regulation governing the instrumentation, observation and reporting of personal identity data. There is a similar quilt of code governing the persistence and use of personal identity data once it has been acquired.
In health care, the HIPAA Privacy Rule, which has been in effect for over 15 years, provides both regulation and guidance for HIPAA covered entities – providers, payers, and clearinghouses – with respect to the use and disclosure of personal health information without patient authorization. For treatment, payment, and health care operations, the Privacy Rule does not, however, require patient consent to be obtained.
Interpreting and applying the aging HIPAA regulation in the situations arising in today’s technology world has attorneys poring over the regulation like Kabbalists over the Zorah.
The worldwide trend to give individuals more control over their private data is making the navigation of overlapping federal and state regulation even more tortuous.
The European Union’s General Data Protection Regulation, GDPR, effective in May 2018, and California’s similar consumer privacy law, the California Consumer Privacy Act, CCPA, which becomes effective 1/1/2020, give citizens the right to know what data is being collected about them, to be able to access it, to know if it is being disclosed, and to whom, to opt out of having their data sold, and to have their personal identity data deleted on demand. California’s law applies to businesses with over $25M gross yearly revenues, those who possess personal information of 50k or more individuals, and those which earn more than 50% of their revenue from selling personal identity data. Nevada and Maine have already passed similar legislation. And over 20 other states have introduced or considered legislation around consumer privacy this year.
In health care, HL7 (and FHIR’s) Data Segmentation for Privacy, DS4P, speaks to how to structure data to make privacy protection actionable, a necessary prerequisite to implementing privacy policies around its access. The IHE framework provides for what it calls basic and advanced patient privacy consent management. But privacy and consent management looks to be the least-finished part of the draft TEFCA regulation.
In the context of the consumer API legislation from CMS and ONC, identity and authorization to access data are effected with the Open ID Connect and OAuth 2.0 standards. Conformance with the HIPAA privacy laws is the established bar for consent. There is an emerging standard for consent management, User Managed Access. But until it is matured and adopted, ad hoc solutions will continue to dominate the health care landscape.
As I pointed out in ‘Personal Identity Snapshots in Informational Identity‘, personal identity is most practically understood as a narrative, where the individual is the ‘center of narrative gravity’ of their story.
Recasting the privacy issues around the persistence and use of personal identity data from that perspective, the key question becomes ‘who owns your story?’.
There is increasing realization in this age of big data that each of our stories has value. Individually and collectively the trajectories of our stories can be used to predict the future – our future purchases, our future health, our future vote. Knowledge of the future has value.
Emerging legislation such as GDPR and CCPA doesn’t explicitly say the individual owns their story. They are more about transparency at this stage.
There is also an emerging technology solution path moving toward effecting personal identity ownership: self-sovereign identity.
We’ll dive into self-sovereign identity from our Informational Identity perspective in our next post. Stay tuned.
Health IT Architect 