Talking Identity

Talking Identity is getting a new home

2009-05-06T06:05:22Z

I know I’ve been quiet for a while. In large part, I lay the blame at the doorstep of the almighty Twitter. It made it too easy for me to get my thoughts out there without having to put too much effort into it

But it is partly also because I have been working on migrating my blog from Oracle’s blog infrastructure (known to insiders as BOC) to a self-hosted wordpress install. The new home for my blog is http://blog.talkingidentity.com/. The reasons for my move are far too many to go into, but I do hope that the move enables me to get more engaged with my readers.

If you are seeing this post in your blog reader, then you are subscribed to my old feed, and need to switch to the new one. The new feed url is http://feeds.feedburner.com/TalkingIdentity. So go ahead and do that, and you'll be all set to receive my next insightful, witty post. I look forward to using my shiny new toy as I continue talking with you about identity.

Are Social Networks the biggest threat to User Privacy?

2009-04-06T22:37:29Z

Privacy advocates have long been raising a hue and cry about the negative impact social networking sites are having on privacy. For the most part, the glare has been on the poor security practices and privacy controls of these sites. But now researchers at the University of Texas at Austin have brought to light a far more problematic issue.

Computer scientists Arvind Narayanan and Dr Vitaly Shmatikov have proven that the anonymized data sets that social sites sell to marketing firms are not really that anonymous. It is possible to reverse engineer these data sets and obtain actual names and addresses, by looking at the content and structure of the data (in their example, correlating data from Twitter with Flickr).

BBC Coverage

Detailed look by Ars Technica

The paper: De-anonymizing Social Networks

This raises grave concerns about a practice that has becoming increasingly common as social networking sites seek ways to monetize their data. They routinely release social graphs from which a few bits of personally identifiable information (PII) has been stripped to interested parties - advertisers, third-party apps, government and academic researchers. Conventional thinking is that this is good enough to protect people's identities.

But as the paper shows, this is nowhere near good enough. It's an interesting study that essentially redefines the term PII, and could (should) have grave implications for social networks and their responsibility towards their users.

The lesson, as Ars Technica points out, is that "anonymity is not sufficient for privacy on the web".

More Things about Federated Provisioning

2009-02-18T16:47:11Z

My previous post on federated provisioning generated some interesting responses, both in the comments and in the blogosphere (see responses from Ian, Pamela and Pat Patterson). The topic has been so engaging (starting with Jackson Shaw's post) that while I was writing this post I saw that Dave Kearns has made it the topic for a series in his newsletter.

Pat's post is definitely worth a read as it describes how Liberty Alliance has proposed a solution to the thorny issue of data exchange between the two parties in the case of Scenario 2: Just-In-Time Provisioning. It sounds like an elegant solution, especially since it solves the issue Karl brings up in the comments to my post regarding not overloading the SAML assertion with extraneous information. Would love to hear if anyone knows of any issues in the solution.

Ian and Pamela also discuss the issue of federated de-provisioning, which has also been a thorny issue in federation discussions. Pam talks about being able to initiate de-provisioning when a user who should no longer have access tries to authenticate. That is certainly one way to do it. But more often than not, de-provisioning cannot be initiated during an authentication flow because the reason the user should no longer have access is that they are no longer employed at the company they got federated from. Meaning: they cannot authenticate from the RP in the first place.

What harm then, is there in a federated account sitting around if it cannot be authenticated to? Well, the answer I usually get (from customers) is that in the reality of today's systems, creating federated access to a service often involves creating some sort of account in an underlying legacy system. An account that can be authenticated to outside of the federation context, albeit only from a back-channel. While this is a scenario less likely to get abused, it is nonetheless a scenario that security audits frown upon, and that get flagged for remediation as a compliance risk.

So what to do? Ian talks about expiring accounts that have not been accessed in a while. Out-of-band de-provisioning between the RP and the SP is also a possible option, as described by Pam. That makes the overall integration between Acme and Omega a blend of Scenario 1 and 2, where federated provisioning happens just-in-time, but de-provisioning happens out-of-band (probably on a periodic basis) through a well-defined interaction. The de-provisioning can be made real-time as well, in that the provisioning server at Acme can issue a de-provisioning SPML request to the provisioning server at Omega, just like it would to any internal system, when the user is de-provisioned at Acme.

As you can see, solutions abound, and customers can choose the one that suits their needs the best. So it is pretty obvious that it is possible to solve the federated provisioning/de-provisioning problem. The issue is that none of this is standardized or formally productized in any way, and is left as an exercise for the customer to solve (Translation: Costly integration problems when different vendor products are involved). And where this issue was a costly annoyance in federation deployments between businesses, SaaS (where this whole discussion started) takes this to a whole new level, creating a barrier for adoption.

But as Pat says "Seems like that might change now..."

The Thing about Federated Provisioning

2009-02-03T17:55:35Z

Ian Glazer recently blogged about federated provisioning, saying "Federated provisioning should not exist; there is only provisioning.". Well, I think he's both right and wrong about this. Let me explain.

Suppose two companies, Acme and Omega enter into a federation agreement, whereby employees of Acme will be able to access a service at Omega using their Acme credentials. There are two scenarios here for federated provisioning.

Scenario 1: Advance Provisioning

Acme decides that they will decide beforehand which employees are allowed to access Omegas service (based on business rules or approved requests). They will therefore do some advance work sending provisioning requests to Omega for those employees that are to have access, allowing Omega to set up federated accounts (with the appropriate mappings) for those employees. A lot of times today, this is done in the form of a batch file/spreadsheet/LDIF file containing all the users that should have access going from Acme to Omega. In an ideal situation, this would be handled by Acme's provisioning engine sending SPML-based provisioning requests to Omegas provisioning engine.

This is the scenario that Ian is referring to when he says that federated provisioning is no different than regular provisioning, and he's right. As a provisioning target, Omegas service is no different from a sensitive target within Acmes own boundary (the logistics of setting up the trust may be a little harder). And whether or not the service is SPML-enabled or not really doesn't change the problem statement.

However, there is another scenario that changes the discussion a bit.

Scenario 2: Just-In-Time Provisioning

Acme decides that they are not going to decide beforehand which employees are allowed to access Omegas service. Instead, a link to the service is available on Acmes intranet, and whenever a user decides to go to the service, they should be given an account. In this case, no pre-provisioning is taking place. Instead, the provisioning has to occur in real-time, when the user accesses the service via the intranet link for the very first time.

The idea here is that when Omegas federation server encounters the incoming SAML token for a new user, it would recognize that the user does not have a federated account, and send the SAML token to Omegas provisioning server. The provisioning server would create the account right then and there, and return the necessary result back to the federation server so that the federation server can proceed to grant the user access.

This scenario is much more complicated than scenario 1 because of multiple dimensions. First off, the interaction between the federation server and the provisioning server has to be responsive and well-defined (and to prevent vendor lock-in, standards-based). An added wrinkle may be that the federation server may need to collect additional user information not available from the SAML token, in order to provide the complete set of information necessary to provision an account to the provisioning server (an alternative could involve a handoff to the provisioning servers self-registration screens to do the same). And the provisioning server needs to be able to understand the needs of the federation server with respect to provisioning and responses. I won't even go into the need for cache invalidation, etc.

This is where federated provisioning is not like regular provisioning (as we know it today). There are a number of things needed here that regular provisioning isn't set up for. The standards-based interaction between the federation server and the provisioning server isn't defined today, and SPML is not set up to accept SAML tokens as data inputs, or handle the just-in-time nature of this scenario. This is where a lot of work still needs to be done.

I would be interested in hearing if anyone has done anything to do with scenario 2. And, of course, any dissenting opinions on the matter (Ian?).

International Data Privacy Day: Real Problems, Real Solutions

2009-01-28T19:59:59Z

Wednesday, January 28 is International Data Privacy Day, honoring the anniversary of the Council of Europe Convention on Data Protection (No. 108), the most important international law for privacy. The purpose of this convention is to secure in the territory of each Party for every individual, whatever his nationality or residence, respect for his rights and fundamental freedoms, and in particular his right to privacy, with regard to automatic processing of personal data relating to him.

Privacy is a funny thing - most people assume they have it unless they explicitly do something to give it up, but in actuality, information about us is flowing all over the place without our knowing it. As Bob Blakley likes to say, "There are no secrets". In the US (which is yet to ratify this convention), data about individuals is a commodity at the heart of many a business. And advancements in technology have opened the floodgates, with many of us contributing to the flow through our usage of social media. I've lost track of the number of articles I have read warning college students of the impact their Facebook activities could have on their job searches. Asking individuals to basically shrink away from communities in order to protect their privacy is not the right answer. We need to do more to enable privacy.

In honor of International Privacy Day, I thought I'd post a few links that provide some (essential/interesting/weird/amusing) perspectives and information on the topic of privacy as it is being talked about today.

Proposed "Camera Phone Predator Alert" bill would require all cameraphones to make themselves heard
One Man’s Experiment With a Location-Aware Lifestyle: An interesting post from the blog of the Privacy Commissioner of Canada
More information on Data Privacy Day, thanks to Intel (see this interview with David Hoffman, Director of Security Policy and Global Privacy Officer at Intel as well)
In the United States, the US Privacy Coalition (including EPIC) is launching a campaign to urge the US government to support the Council of Europe Privacy Convention
Search Privacy Issue Goes Mobile
Forrester Research Making the case for Data Masking
A Move Toward More Privacy Online: Yahoo changes data retention policies
Identity Governance Framework at Liberty Alliance
Data Privacy Day Exhibit Differences in Approach from Google and Yahoo

If you are doing anything for International Privacy Day (and it isn't private! - thanks @trevcook), or have links to interesting stories regarding privacy, please leave me some comments. And be sure to pass on the word. Request your government to support the Council of Europe Convention on Data Protection (No. 108) and to adopt comprehensive privacy legislation based on that standard.

On Anonymity, Pseudonymity and Personas

2009-01-13T03:18:00Z

One of the online forums I participate in is commonly referred to as the Identity Gang (it is now part of identity commons). An interesting conversation took place last week on the topic of anonymity and privacy. The conversation did branch out a bit (as these conversations often do), but it did bring to the fore some important concepts that need to be clarified.

I found the conversation on anonymity particularly interesting. Those of us in the field of identity management tend to get hung up on terminology a lot. It's an important aspect to any emerging field, as improperly used or appropriated terms tend to create confusion in the marketplace, and act as a barrier to productive engagements. It is with that in mind that I raised the question on the forum last week "Isn't a pseudonym the same as a persona?". Dave Kearns weighed in on my question in this weeks Network World IdM Newsletter.

Much of the conversation last week was on the nature of anonymity and, by extension, pseudonymity. One of the important ideas established is that they are transactional constructs, existing within the context of some identity-based interaction. My question was posed with that frame of reference.

True anonymity in the digital world is pretty hard. There is always some sort of trail (IP addresses, etc) that can lead back to the original user. So it would seem to me that all we have today is varying degrees of anonymity - starting from the barest minimum of information, ranging through being able to piece together a picture based on multiple interactions, having semi-anonymous interactions based on the establishment simply of a username, to a full-fledged fake identity being set up in a website. In other words, all that exists today is pseudonymity.

Does that mean that anonymity is simply an edge case of pseudonymity? I think not. Just because anonymity doesn't exist today does not mean that we don't want to achieve it. Therefore retaining the separation (that an anonymous interaction can never lead back to the originating identity, while a pseudonymous interaction is simply an imposed barrier between the interacting party and the originating identity) is important as a way of enabling us to work towards the technological solutions necessary to achieve anonymity in the digital world.

More interesting is where digital personas fit into this conversation. Look at the definition of a Persona as defined in the ID Commons Lexicon, and in particular at comment 1:

A Persona is something put forward by a user, but how it is perceived, recognized, accepted, rejected, trusted, used etc. by a Relying Party cannot be specified or in any way implied.

Based on the underlined part, it seems to me that a pseudonymous identity is simply a persona. When a user sets up a persona, they specify the information they want to present through that persona. This information can be completely fake, as minimal as necessary, and set up solely for the purpose of interacting with that one party. In other words, the interaction using that persona is pseudonymous in nature. Since personas and digital pseudonyms seem to share the same characteristic of having a range with respect to amount and transparency of identifying information, it would seem to me that they are one and the same thing.

Understanding these constructs will be important as we move beyond identity management systems and start building persona management systems for use on the web. In particular, understanding the relationship between persona and pseudonymity will help frame the requirements for these systems as they help protect us in our online interactions.

Change We Need

2008-12-02T01:56:22Z

It's been a long time since I have been able to post. A lot conspired to make it difficult for me to keep up with my blogging, not the least of which has been a number of interesting, but under wrap, developments within the IdM group at Oracle (if you follow me on Twitter, you may know what I am talking about). I‘ve been knee-deep in meetings planning our development projects for next year, so stay tuned to this space for a look ahead.

My last post was just before I headed to Prague to participate in a panel on Identity Services at Burton’s Catalyst Europe conference. I could make some jokes about how it has taken me this long to recover from the craziness in Prague, and it would be partly true. But I wouldn’t even begin to know how to describe all of it, so this is me moving swiftly on.

During the panel discussion (thanks to Oracle’s own Dennis MacNeil for taking the photograph above), we talked about the work we’ve been doing in Burton’s Identity Services Working Group (ISWG). Kevin preceded the panel with a presentation outlining the results of the first phase of our work, which has focused on the basic services in an identity services architecture – attributes, authentication and authorization. I can’t really share the results of the work here, because of the rules we work under as part of the working group (I’ll try and talk Kevin into letting me share some of it). However, I will say that one of the interesting developments from the many meetings we had, and which informed the approach taken in this phase of the project, was the group adopting the thought that “Authentication is simply an Obligation in an Authorization process” (think about it). As a result, we have come up with an interesting take on the role of PEPs, PDPs and Claims in the architecture.

The bulk of the panel discussion focused on explaining the drivers for the work being done in the ISWG. The fact that all the folks on the panel were either vendors or financial industry folks meant that the talk was about creating efficiencies, standardizing deployment architectures, maintenance and upgrade headaches and freedom from vendor lock-in. All good reasons to keep in mind when understanding how identity services needs to evolve and get used.

But one of the things that didn’t come up was the fact that our industry as a whole is headed towards a seismic shift in how we deal with identity, and that having a good identity services story is crucial to being able to weather the storm. Change is definitely in the air, and not just because the recent election cycle or recession fears have put that word firmly in our conscious. You can sense this by doing a quick scan of the blogosphere. Rapid advancements in the area of Information Cards and OpenID, Microsoft’s recent work encapsulated in the Geneva announcement, our own work on the IDx project and the emerging talk of the “Open Stack” for identity are all key developments to follow to understand where we are headed as an industry. There is a lot of work still to be done in these initiatives, but one can already see the far-ranging implications of all these projects. And identity services will be the backbone that allows enterprises and applications to adapt in a scalable manner.

Much needed change is on the way, so buckle up.

Evolving the Identity Services architecture

2008-10-17T22:12:18Z

The last 3 months or so has been really good to my work defining our vision for Identity Services. I've gotten valuable input from my colleagues in the IdM business, and my participation in Project Fusion and Burton's Identity Services Working Group has helped crystallize some key aspects of the architecture. Below is the latest architecture diagram for the Identity Services Platform.

It doesn't look remarkably different from what I have presented previously on this blog, but it do want to point out some of the evolving ideas captured in the diagram above:

Some of the ongoing discussions that I have blogged about previously have led to a clearer definition of the service called the Identity Hub . In fact, we just put out an Oracle whitepaper talking about the Identity Hub in detail.
It has become clear that the API Interfaces that the applications rely on to consume these services should be coming from the container that the applications are built on.
The provider model by which various IdM products plug into the architecture as Service Providers (within the container) is starting to take shape, thanks to good discussion happening in the standards and vendor communities. Consuming applications will not know or care about the specifics of the deployment. This also provides a way for the existing IdM investments to be leveraged (provided we can get all IdM vendors to agree to the requirements of being an Identity Service Provider).
Authentication and Authorization are both going to have to support contextual and risk-based decisions. This will require greater communication from the applications into the services, and vice-versa.

You can check out a presentation I have put together on how the various IdM products in Oracle Identity Management can be used to create an initial version of this Identity Services Platform. This is an adaptation of my OpenWorld presentation that I will be using in discussions with some customers that are interested in working with us to define their identity services strategy. As always, input and feedback is welcome. And feel free to tell me specific portions that I should talk about in detail in this blog.

Remember, you can find all my published materials (the presentation referenced above, all the Oracle whitepapers on Identity Services, and more) on the downloads page of my blog.

Spreading the Word on Identity Services at Catalyst Europe

My exciting fall season continues as I head to Europe next week. My trip starts with a brief stopover in London for some meetings, after which I head to Prague for the Europe edition of Burton Group's Catalyst Conference. I've been to Prague before (for pleasure, not business), and I absolutely love that city. So that is as good a reason to go as any.

My participation in Catalyst Europe is to continue to spread the gospel of Identity Services. On Thursday, Kevin Kampman will be presenting the results of the work that has been done so far in the ISWG. Following that, I will be on stage as part of a panel discussion involving both customers (TD Bank, BT, Credit Suisse) and vendors (IBM, Novell, Sun and of course Oracle) that are part of the ISWG.

Title: Identity Services Roundtable: Aligning Vendor Strategies with Customer Needs
Date: Thursday, 23 October 2008
Start time: 11:55 am
End time: 12:45 pm
Room: Congress Hall 2

Should be an interesting discussion. We've had some very good workshops in the working group, and we are anxious to put the results out there for people to see and comment on. It is very much a work-in-progress, so lots of feedback is expected. If you are going to be at Catalyst Europe, then please stick around for this roundtable (unfortunately, it is scheduled as the last session in the conference) and participate. And remember to follow me on Twitter for real-time updates on my Europe trip and the proceedings at Catalyst Europe.

The changing face of Password Management

2008-10-09T20:36:15Z

A college student was arraigned on Wednesday for allegedly breaking into Gov. Sarah Palin's private e-mail account last month. Political leanings aside, I read the news article with great interest for the inherent security implications. Reading it, this line jumped out at me:

The F.B.I. said that the younger Mr. Kernell allegedly hacked into the account in mid-September by resetting Gov. Palin’s password.

I obviously don't know the specifics of how the F.B.I. says the password was reset. But for the sake of our discussion, let's assume that the email system relied on a typical challenge response mechanism (currently the norm in most free email systems). The hacker obviously didn't know the password, but was able to reset the password to something of his/her choosing by successfully answering the challenge questions. In the age of Google, how hard is it to find out the the first school, the first car, the mother's maiden name or the pets name of a famous public personality like Sarah Palin?

As Bob Blakely likes to point out, there are no secrets any more therefore any system that relies on secrets is inherently flawed.

In a completely separate conversation, a colleague of mine sent me the following thought:

All the banks and merchants I do business with online have been increasing their level of security, especially with password complexity requirements. Historically I have limited all my passwords down to 3 based on the type of site so I had no need to write them down. Now because of all the different password complexity requirements, especially the password history requirement, I can no longer do that.... so I'm now forced to write them down :(

In some sick way, more security by merchants is now leading to worse security for me, the user. I'm forced back to the sticky note.

From the Good News/Bad News Department

The bad news in all this is that we seem to be going through a phase where additional mechanisms introduced to secure the systems in a user-friendly manner have actually exacerbated the problem because they rely on flawed assumptions. The above issues are clear illustrations of this. The mechanisms deployed (challenge response, password complexity requirements) would have been fine on their own for the system they are meant to protect. But these solutions did not anticipate how they would be impacted by the reality of their users online environment. The aggregation of multiple such systems for a user actually ends up degrading the effectiveness of these solutions, to the point where they end up becoming liabilities instead.

The good news is that new technologies and solutions are emerging that (hopefully) will address these problems. OpenID and Information Cards aim to rid us of the multiple password problem by promising a world of reduced sign-on built on trust. Identity assurance technologies (like the ones in Oracle's Identity Assurance Partner Alliance) provide safer, more reliable means to verify the interacting parties identity than traditional challenge response mechanisms, thus preventing the kind of attacks described above.

So better days are coming. The real challenge ahead of us is getting all involved parties (consumers, online enterprises, vendors) educated on how these solutions can be used to make our online lives more secure.

Dissecting all the buzz about Identity Assurance

2008-10-07T20:19:57Z

One of the big buzzwords this past month or so has been "Identity Assurance". Liberty Alliance made a big push for the Identity Assurance Framework (IAF)at DIDW last month, conducting a number of sessions/workshops introducing it to the masses. Our old friend Frank Villavicencio, who is a co-chair of the IAEG, was a star at the show, even collecting a Liberty Alliance IDDY award. At OpenWorld, Oracle announced the formation of the Oracle Identity Assurance Partner Alliance, an initiative focused on extending our identity and access management offerings with comprehensive and proactive identity fraud prevention solutions from strategic partners (you can read the press release for details).

So what exactly is Identity Assurance? Simplistically, Identity Assurance is the ability to determine, with some level of certainty, that the person (identity) presenting themselves in an identity transaction is who they are claiming to be. The level of certainty one can have about the presented identity is what is referred to as the "Assurance Level". Identity Proofing is another term that is used in this context (and that I have used in the past), though it is more commonly associated with the verification of ones real world identity during the registration process.

So what are these two initiatives, and how are they related?

Identity Assurance Framework - Think TRUSTe for IdPs

The IAF is coming at the Identity Assurance discussion purely from the authentication angle, especially within federation contexts. It is based, in part, on the Electronic Authentication Partnership Trust Framework and the US E-Authentication Federation Credential Assessment Framework, initiatives designed for the sole purpose of enabling interoperability among electronic authentication systems. As such, it attempts to define a trust framework around the quality of claims issued by an IdP based on language, business rules, assessment criteria and certifications.

The IAF has published a standard set of assurance levels regarding the authentication of the user (Level 1 means low assurance, Level 2 means medium assurance, and so on. As of today, there are only 4 levels of assurance, Level 4 being the highest level). When a digital token is issued, it states the level of assurance at which the user was authenticated - Level 1 through Level 4.

The IAF defines a certification process through which an independent auditor assesses whether the issuers interpretation of Level 1-4 meets a standard assessment criteria established by IAF. So one issuer may have used a RSA SecureID token in combination with Username-Password to issue a Level 2 token, while a second issuer may have used a biometric challenge in addition to a UserID-PIN to issue a Level 2 token. The RP receiving the token from both issuers simply knows that both tokens are Level 2, and doesn't know/need to know what the actual mechanics were, simply that an audit process certified that the mechanism for generating the token meets the criteria laid out by Liberty IAF.

The IAF is NOT defining any technology or standard protocols. In this sense, the IAF is trying to set up something analogous to the way TRUSTe verifies and asserts through their web seal that an eCommerce site is trustworthy.

Oracle Identity Assurance Partner Alliance - Tools of the Assurance Trade

Oracle IAPA aims at extending Oracle’s Identity Management Suite with partner technologies that offer capabilities such as identity proofing, internet geolocation, multi-factor authentication, out-of-band authentication, endpoint security and secure remote access. As such, its charter is pretty broad in combating identity fraud and providing context-aware security, and this encompasses identity assurance.

The solutions in the IAPA can provide the underlying mechanism by which an IdP can support the main tenet in the IAF, wherein an assertion can be trusted (at varying levels of assurance) to really belong to the entity represented. The IAPA steps in as a way for Oracle IAM to leverage technologies that enhance an authentication process with additional "challenges" that up-level the authentication assurance to the appropriate level - whether it be by using a biometric challenge, a voice challenge, a knowledge challenge based on external data aggregators, etc. So Oracle IAM + IAPA is positioned nicely to be the execution/implementation arm of an IdPs IAF compliance efforts.

Looking To Tie Them Together

One thing I will be exploring is the possibility of having the IAPA stack go through the Liberty IAF audit process. Then any customer deploying Oracle Access Management in conjunction with one of our partners would immediately know the IAF assurance levels of the authentication tokens being issued. Conversely, a customer that is targeting being able to issue credentials of certain assurance levels will be able to identify the solutions that will meet their need.

The fun never stops in Identity World

2008-10-02T21:14:04Z

Boy, it was an exhausting September. There was a lot going on between work, Digital ID World, Oracle OpenWorld and the Burton Identity Services Working Group. Unfortunately, this left me little time to write on this blog. But hopefully all of you were able to follow my real-time thoughts on Twitter. If you are interested, check out my DIDW tweets and my OpenWorld tweets.

It was interesting to see the amount of discussion going on around the topic of Identity Services. At DIDW, there were a number of different sessions that looked at different parts of the Identity Services challenge. Kim Cameron talked about claims-based identity transactions in his keynote. All the different discussions on Liberty's Identity Assurance Framework were trying to deal with improvements needed in the authentication service. Some of the necessary standards discussions came up in the session on "Bootstrapping Identity Protocols". And of course Jamie Lewis talked about it in his keynote.

At OpenWorld I once again took on the task of trying to illuminate the masses on identity services. It isn't a topic that usually gets a lot of interest at OpenWorld, since the attendees are mostly interested in figuring out real world implementation issues. So the sessions most attended were the ones that looked at best practices and customer case studies. Also, being scheduled for the first session of the day at 9am didn't help drive up my attendance numbers.

But I did get a pretty decent crowd, all things considered, and got some good questions and very good feedback and validation on the content of my presentation. I did try to spice it up by throwing in a bit of humor centered around "The Love Guru" (since identity services is all about achieving identity nirvana); not sure if that helped or hurt. I wanted to post the presentation here for all of you, but OOW presentations are paid content controlled by Oracle, so I can't. But I will be adapting that presentation for some talks I am giving to customers on the topic of Identity Services, and I will post that presentation, along with a discussion of how my architecture has evolved, in an upcoming blog post.

October is looking to be just as busy. Of course there is all the usual stuff going on at Oracle. Tomorrow I'll be doing a quick dash across the border and back for the second all-day workshop of the ISWG. Then later this month I will be heading to Europe, where I will be meeting with some customers and attending Burton's European edition of the Catalyst Conference. I will be part of a panel that includes other ISWG members from TD Bank, BT, Credit Suisse, IBM, Sun, Novell and, of course, Burton that will be talking about Identity Services and presenting some of the work we have done in the working group. Catalyst Europe is in Prague, which is a city I absolutely love, so I am pretty excited about that too. Should be a fun month.

Talking Identity Services at OpenWorld

2008-09-22T08:53:23Z

I was hoping to find some time to dig a little deeper into some of the themes, conversations and ideas that were floating around the halls at DIDW last week. Unfortunately, time was not a luxury I had this week. I am writing this aboard a flight to San Francisco, as I head there to attend the annual Oracle OpenWorld conference.

Oracle's big shindig is the place to come to if you want to find out about all that is going on in the world of Oracle. And this year is no different. The conference is bigger than ever (I hear upwards of 43,000 will be attending), and there will be some big announcements at the keynotes. Oracle Identity Management will be well covered at the show, both on the demogrounds and in the many sessions, where IdM got its own track.

Not surprisingly, I will be speaking on the topic of Identity Services. My 3rd session on the topic continues the discussion I started 2 years ago in a session on application-centric identity management. If you are going to be at OpenWorld, then definitely come check out my session, as I delve into the practicalities of building an Identity Services Platform for your enterprise.

Session ID: S298923
Session Title: Building an Identity Services Layer with Oracle Identity Management
Venue: Marriott
Room: Golden Gate C3
Date: Wednesday, 24th September 2008
Start Time: 09:00 am

During the session, I will present how one can go about deploying identity management in a way that enables the development of identity-enabled applications. I will also discuss some of the things I have learnt from participating in Burton Group's Identity Services Working Group, my many conversations with the identirati at Catalyst and DIDW this year, and from my continued involvement in Project Fusion, which lays down the architecture for the next generation enterprise application. Unfortunately I drew the short straw and got the 9am shift, so there are sure to be people who won't make it as they recover from their shenanigans the previous night. Hopefully I will still be on East Coast time, and sufficiently caffeinated :-)

And as always, I will be twittering my observations from OpenWorld in real-time, so be sure to follow me for the latest. I hear there will be a number of interesting announcements.

See you in San Francisco.

Conversations were center at DIDW

2008-09-11T19:17:50Z

My Digital ID World was all about conversations. Much more useful to me than the sessions was the opportunity to brainstorm with some very smart, very committed (some insanely so) people in the identity community. The sessions were good, and some managed to inspire some original thought. But the hallway conversations (so to speak) were really what made this conference work for me.

I felt a little bit like the blind men examining the elephant, except that I could see a little bit. So while everything being talked about looked and felt like different things addressing unique problems, I could also see a little of how they interconnect and relate as part of a larger, more cohesive whole. This was especially true of the sessions on the Identity Assurance Framework, Identity Protocols, Identity Services and VRM, and my conversations with Kim Cameron, Doc Searls and Bob Blakely, among others.

The remainder of my week is being spent at Oracle HQ, so I will be pretty busy in meetings. I will therefore post more detailed thoughts on specific topics that came up in the sessions at a later time. In the meantime, you can check out the real-time stream of consciousness thoughts I had at DIDW by clicking this link to read my Twitter posts from the conference.

My DIDW just got a lot more interesting

2008-09-06T01:56:52Z

This week I was invited to join Brenda Hughes from Cisco on next weeks DIDW panel discussing "Lessons learned from Successful Compliance Deployments". My hope is to share some of the insight I obtained from watching (at uncomfortably close quarters, from a vendor perspective) a number of our customers go through the process of deploying identity management to solve some of their main compliance issues. Obviously, compliance has been the big story in IdM the last few years, and most companies still have a long way to go. But the nature of the discussion seems to be changing a bit, as compliance itself is de-mystified. Come by for what is sure to be an interesting conversation.

Also, I will be connecting with a number of folks who are coming out to DIDW, both one-on-one and in some interesting group settings. Matt Flynn has organized a blogger meet, which I look forward to, since my attempt at a Tweetup sort of fell flat. Should be interesting. Again, grab me if you see me at the opening reception or at the demogrounds, or while I am rushing from one session to another, if you want to chat.

Continuing something I started as an experiment at Burton Catalyst, I will be twittering extensively during the conference, sharing what I am hearing, my thoughts and the experiences of DIDW (provided I can snag a power outlet and/or AT&T 3G can avoid going down again). Be sure to follow me at http://www.twitter.com/NishantK if you are interested in my perspective on the proceedings.

Does 'User-Centric' also mean 'User-Burdened'?

2008-09-02T16:14:36Z

Dave Kearns recently took on the topic of how user-centric and enterprise-centric identity could possibly co-exist in his articles for the Network World Identity Management Newsletter. In his first post, he discussed what the difference between the two is - the need in the Enterprise scenario to have all identity-related transactions tied together from an audit perspective, contrasted with the need in the User-Centric (or personal) scenario to have no ability to tie together the various transactions a person can enter into. In his follow-up post, he discussed how the two, given these diametrically opposite requirements, could co-exist.

Dave postulates that the solution is based in the idea of Digital Personas. If I am reading his thesis correctly, he basically says that a person (an entity) can keep his online transactions un-linkable by using different personas (as represented by different information cards) that are kept separate and distinct at the source (namely the user and his IdP). In this way, common identifiers are avoided (not sure about that, since the most common identifier - an email address - is likely the same across most, if not all, of your personas), and so correlation reports cannot be built that harvest and mine data.

While Dave is clearly working with the constraint of what is possible today (both on a technological and legal footing), I think this solution puts too much of a burden on the end-user, since this requires the user to maintain multiple personas across the various applications he interacts with. In other words, even if the persona I want to present (PII attributes, credit cards, etc) to two different applications is exactly the same, I would need to create two different personas (in effect duplicates) if I want to make sure that there is no linkability. One can see the potential for persona explosion.

This is like saying that a user (who is extremely paranoid and wants no one building a consumer profile by looking at his purchase history) should maintain a different credit card (in effect tens or a few hundred) for every merchant he interacts with. That is comletely impractical. But just like there is no recourse today for consumers in this arena (the SSN, home address information, etc that every credit card record has enables complete linking, and results in the massive databases that telemarketers thrive and live on), it seems that there are no legal and technological solutions enabling the consumer to use the same persona while guaranteeing non-linkability. It's an interesting problem that I think needs to be addressed by the identity community, because if it isn't, linking of our online identities will happen (whether we want it or not), because the burden of maintaining multiple personas is just too much work, and user habits will prevail (just like it does in the matter of username-passwords).