Identity and privacy: it’s all about context

It’s easy enough to see that identity and security are tightly intertwined, since security practices almost always involve authentication and authorization, usually handled through various identity-proving methods. Less obvious is the link to privacy.

If we accept as a definition of identity the set of an object and the attributes which accompany it, then privacy is the act of shielding some or all of those attributes from some or all of the people who wish to view them for whatever purpose.

One attribute, for example, is your driver’s license. A person filling the role of a highway patrol officer has a legitimate right and need to examine that license in the context of a traffic stop. That same person, in the role of a youth soccer coach, has no legitimate right to examine that license when making up the drinks and snacks list. It’s all about the context.

In a freewheeling discussion with IBM’s Steve Adler last week (he’s the global privacy market manager for IBM’s Tivoli software) he made me realize the importance context plays in determining privacy issues involving identity details.

As an old-time network administrator, I still tend to see identity security as a username/password combination that allows you to access and use various resources on the network. But the identity object (the user) and its attributes also have access control lists associated with them as well as policies determining who can see and manipulate the data. What the traditional view doesn’t have is context.

Over the years, identity and network vendors have added context-like policies, such as restrictions based on time of day, day of week, or platform accessed from (e.g., laptop over the public Internet). But these are mostly static restrictions; there’s no “why” component, just “who and when,” with a possible “where and how.”

IBM has created an XML-based privacy language (Enterprise Privacy Authorization Language, or EPAL) which allows the idea of context – the “why,” if you will – to be included along with the who, what, when and how of authorization.

Two examples will illustrate this.

In healthcare, it’s important and necessary that your primary care physician have unimpeded access to all of your health records to properly diagnose and prescribe for you. A vision specialist, though, doesn’t necessarily need to know about a broken bone you had 20 years ago, or about the “social disease” you contracted. An insurance administrator, even one with a medical degree, needs only limited access to relevant details of a particular treatment in order to approve or deny payment.

In the travel industries, one company may offer management services to a number of different, branded entities in, say, the hotel and restaurant fields. The manager of a single property needs access to that hotel’s guest register to know who is staying there and when. The hotel chain’s management doesn’t need to know individual details, just how many and which rooms are used each day. The management company, when reporting to its customers, needs only report aggregate information without identifying either the chain involved, the individual property or the individual guest.

In both cases, all of the data are present as part of the attributes of the particular object, but access to that data is restricted based on the context of the retrieval. The EPAL specification (linked below) makes interesting reading. It has now been turned over to the World Wide Web Consortium for standardization, and vendors in the identity and security spaces need to pay attention.