It\u2019s 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\u2019s 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\u2019s all about the context.In a freewheeling discussion with IBM\u2019s Steve Adler last week (he\u2019s the global privacy market manager for IBM\u2019s 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\u2019t 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\u2019s no \u201cwhy\u201d component, just \u201cwho and when,\u201d with a possible \u201cwhere and how.\u201dIBM has created an XML-based privacy language (Enterprise Privacy Authorization Language, or EPAL) which allows the idea of context - the \u201cwhy,\u201d if you will - to be included along with the who, what, when and how of authorization.Two examples will illustrate this.In healthcare, it\u2019s 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\u2019t necessarily need to know about a broken bone you had 20 years ago, or about the \u201csocial disease\u201d 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\u2019s guest register to know who is staying there and when. The hotel chain\u2019s management doesn\u2019t 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.