The Ephemeral ID
By suncpo on Mar 08, 2008
I just looked this over briefly & understand that it reads a little rambling & quite longish. If I had more time, this would be short & pithy. It's not. It's a blog. If it makes any sense to you, I'd still love to hear your thoughts:
Ms. Thang is reading Little House on the Prairie with her dad & I can hear the rumble of a deep voice and the lilt of a giggle here & there. I took advantage of this moment of quiet to peek in on Miss Sweet Cheeks where she is sleeping peacefully, clutching a knitted sock dolly, her lovely eyelashes resting lightly on rosy apple blossom cheeks.
Have you ever loved someone so much you were sometimes in physical pain? My ribs feel like they must be broken & my head feels a little weird-- only way I can describe it.
Which leads me, naturally, to thoughts about...data protection & identity management. Of course.
Both of my girls' identities are changing so rapidly. Each day their needs, desires, interests and abilities morph in & out, forward, backward & sideways. Imagine if you will, looking over the identity of just one \*system\* user over the course of time.
Would the 'mature' customer or employee ever bear resemblance again to the 'infant'? Would data collected in the early years of the relationship be relevant in the decision making of today or the strategy planning for tomorrow?
Furthermore, is this human data ever \*that\* great a long term predictor for that one user or is it the trend data for many similarly situated individuals that helps us make our plans?
Why then do we insist upon retaining account data associated with one person for any great length of time in an enterprise setting? Anonymous data for many purposes seems to be the more expedient vector.
Granted, there are some details either so static or so stark that they must be retained, but only as they continue to color the present & predict the future.
I, for example, am a human of the XX variety. Like it or no, for certain characteristics, that fact- collected if you will at my birth- continues to be a decent predictor of certain things.
The fact that I am a mom & have freely disclosed that fact is also significant & an okay predictor for some things and a fantastic predictor for others. Threaten a mommy's kids with serious harm, for example, and there's a pretty good chance she will crush your larynx with her pinkie & be more than able to sip a fat free latte guilt free 30 seconds thereafter.
(More ladies should be in senior management for the same reason, but that's a different topic for a different day.)
The point here is that identity management schemes and data collected that is associated with one's ID should contemplate the temporal who I am now, the role I intend to play in this interaction, the role you wish me to play and the roles into which we will both evolve over time.
Take for example, a key fob strategy-- tons of these have been proposed, with some louder than others but not all that different. I suppose one could chose a "role" based on any number of data elements, but that role would only work to gain access to goods or services or more data where the transaction partner has enough flexibility in authentication and alternative goods, services or more data to match the self selected role.
Here's what I mean: Am I an employee or a customer when I eat at the company canteen? Is it relevant know any of my work details to be sure I may enter? Should I bring "Sun employee" data element key fob, or "Sun employee, badge Number XXXXXXXXXXXXXXX, Chief Privacy Officer, digital access level XXX, etc..." Should we have to mess with a dual system or that much over collection just to authenticate into the building that houses the cafe just to get a salad? The system gets to dictate my role, not me.
Question is, in later years, the same user could return as a completely different role by virtue of time or circumstance & now the user would essentially change the role rather than evolving the relationship. Alternatively, the enterprise can assume that the role holder had changed & can start changing permissions and management of that user's data accordingly based on information that enterprise holds on other similarly situated users. Obviously it makes a difference if I am no longer employed at Sun but no one in the lunch room needs to know or cares if my rank is up or down. (I purposely picked a silly example to make a point, but a similar analysis applies where I am a manager v.when I am acting as an employee;n when I need HR data to figure out my benefits v. when I inspect that system for compliance.)
It's not a bad thought from a management perspective to add and add and add or whittle away notice because the predictive trust that the user gains may, in that case, outweigh the need for fresh 'clear & conspicuous' legal notice. Here, the old timer customer, gets a "Hi Michelle!" v. the dreaded "Hello Ma'am." or the frequent customer starts to get discounts and nice extras without clicking on an email offer.
But, you see, it is the individual data that often describes her role. It is the individual mom's right to dream that she will not grow old, that she will still be able to make her girls giggle with a kiss on the tummy or call them 'baby' long after she knows they are not. The role of goofy sentimental clown may beat in the chest of tough competitor and senior executive. No role based ID scheme easily can always discern which part of that human is presenting herself for system authentication or inspection. AND it is that individual's prerogative-- and often her legal right-- to change her mind.
Where the hell did that come from & why is it relevant, you may ask??
It is the data from our customers and employees that they hold most dear, that is most personal, that allows us to serve them...personally. We cannot and should not always predict that each year of service will equal a greater degree of skill for our employee nor will a new customer always purchase less than the tried & true account. Therein lies the rub of roles, role based management and Identities with a capital I.
I'm not saying that really really good IDm or RBAC is impossible or even that it's not valuable. I am, however, saying that it's tricky and that our developers must look to their software/ hardware platforms, their lawyers, their geography & culture lessons...and perhaps into their hearts just a little bit.
Personal data is, after all, personal.
A little bit of a crazy thought before I head in to read a little Harry Potter to Miss Thang...