Option 1: OpenID Attribute Exchange

Some view provisioning as being little more than an attribute exchange. So it is natural to consider OpenID Attribute Exchange, which allows the federation service to request additional attributes from the OpenID Provider during the authentication flow. Essentially, when the federation service detects that the user doesn’t have an account, it could validate the claims it received as part of the token, and if it needs additional data, then it could add a request for those to its authentication request.

This can solve the data retrieval challenge, and squarely positions OpenID as a JIT Provisioning protocol. But the componentized architecture we have been assuming does face some other problems that it must solve in the enterprise cloud context. These are not problems with OpenID itself, rather with the overall architecture (again, this disappears when all 3 components are combined into a single service application, which is how OpenID-based RPs are able to do this today).

As discussed previously, when the SP is hosting more than one service, you often find that the attributes needed for provisioning depend on which service the user is trying to get access to. This means that the federation service would need to ask the OP for different attributes depending on which cloud service the user is trying to reach. Since the federation service can no longer just work off a static list of attributes that it should always query for, this adds the need for the federation service to able to ask the provisioning service for the list of attributes it needs, in the context of the specific service being provisioned. While the SchemaRequest operation in SPML could be used here, there needs to be a way to differentiate (in a standard way) the complete schema supported for the target by the provisioning system from that subset needed to create an account.

Another challenge created is for subsequent first interactions of the user with the other services hosted at the same SP. Since the provisioning system already knows the user, it already has some of the attributes it needs, but not all. So when the federation service queries it for which attributes it needs to retrieve, it should reply with just those attributes it doesn’t already have (from provisioning the user to a different service). The SchemaRequest operation cannot handle this scenario currently.

The bigger enterprise challenge is how the work on the OP side can be broken up between the OP (federation service) and the provisioning engine (policy and GRC service).

These are minor challenges to be sure (since you can always just get the full schema and update attributes that have changed to maintain consistency), but ones that become important when the flows are examined for compliance and consistency.

Option 2: SAML Attribute Query

In the last post, I mentioned how SAML (with the SSO Profile) and OpenID are both squarely positioned to handle the majority of the basic JIT Provisioning use cases. Good thing is, the SAML folks have been thinking about the attribute exchange problem as well, and in the spec have defined a mechanism to handle this called the SAML Attribute Query, which takes a different approach from the OpenID solution. The query for attributes in this case can go over what they call a back-channel. This can be leveraged to facilitate an attribute exchange between the Provisioning Services on each side of the federation boundary.

The big advantage of this model is that the front-channel (usually the browser, but could be other environments much harder to manipulate) is not getting overloaded with the data retrieval task. Also, since the two provisioning systems are talking to each other, they are fully aware of what is going on and can enforce standard provisioning policies as well as track and audit the happenings on the other side – major considerations in the enterprise space.

However, this does mean that it isn’t truly on-the-fly, since the SAML spec would require that a trust relationship be defined between the two sides ahead of time. There is actually a lot of interesting work being discussed right now in the SSTC that could directly influence fed-prov use cases, so I would encourage folks to keep an eye on that.

Option 3: OAuth + ArisID (IGF)

Last (but not least) is a possible solution that I first contemplated on my blog a few months ago, and have since been noodling over with other folks, and that is the thought of leveraging two emerging powerhouses – OAuth and the Identity Governance Framework. The idea here is very simple. When the user first goes to the SP, the SP can initiate the creation of an OAuth connection with the enterprise provisioning engine, facilitated by the user, of course (this is, after all, a user-centric protocol). The enterprise, for its part, can put in place policies and risk-based controls that would allow it to trust such a connection. With the connection between the parties established, the SP provisioning service can now use the ArisID APIs being defined as part of the IGF work to retrieve the data it needs. IGF adds a whole policy layer here, since the SP will provide a CARML declaration regarding itself (for instance, including details of its SAS 70 certification), the attributes it needs, and how it intends to use them (emailing user policies, storage policies, etc). The enterprise provisioning engine for its part can evaluate the CARML file and publish it’s own AAPML file with its policies.

One of the interesting things about this approach is that it enables the creation of on-the-fly trust between the two sides. The enterprise may never have dealt with this SP before, but can still interact with it with a certain level of trust. This trust is built on two separate components – the assertion from the user itself asking that provisioning take place (OAuth flow), and the CARML file declarations (IGF flow) – that make the creation of the federation a risk-based decision (automate-able) as opposed to a business decision (manual). Since this model also involves the provisioning engines on both sides, the security and policy controls can be enforced.

Still Work To Be Done

These models obviously need to be explored and poked at in depth to determine if they hold. And while these depend on some standards work that is still to be baked, there is a lot of other standards work happening (in particular in the OpenID and OAuth arenas) that could supplant these options completely.

And there are major lifecycle management issues still to be discussed and explored. How does one handle de-provisioning in a JIT Provisioning environment? How can SPs that want to know about profile updates find out outside of the user interaction? And how do all those workflow and policy based controls that are present in Provisioning systems today fit into all of this? Well, I will be exploring some of this in my Burton Catalyst North America talk on “Beyond SPML: Access Provisioning in a Services World” in July. So be sure to check out that session if you’ll be there. In the meantime, please keep leave your comments and feedback here so we can keep the discussion going.

[Ends Part 4 of 4]

Tags: Attribute Exchange, Cloud Computing, Federated Provisioning, Gluecon, GlueCon-FPSeries, Identity Governance Framework, IGF, JIT Provisioning, OAuth, OpenID, SAML

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.

Tags: Identity Governance Framework, IGF, International Data Privacy Day, International Privacy Day, Privacy

While DIDW (like any conference) tends to have its share of vendor sales pitches, it is always good for a few sessions to inspire me and give my gray cells something to work on. My biggest problem tends to be figuring out how to divide my time, because unlike Burton Catalyst, where I know which track to just plant myself in, every session on the agenda here is related to identity. Looking at this years agenda, I see some interesting sessions planned.

Oracle will obviously have a big presence there. Besides being a Platinum sponsor, there will be a few folks from Oracle speaking:

• Eric Leach will be talking on “Next Generation Access Management Solutions” [Sept 9 from 12:20 - 1:10pm]
• Phil Hunt will be talking about the Identity Governance Framework [Sept 10 from 3 - 3:50pm]

And some of our customers will be on panels discussing lessons learnt in tackling some thorny identity issues:

• Brenda Hughes from Cisco on “Successful Compliance Deployments” [Sept 10 from 11:25am - 12:15pm]
• Vikas Mahajan from AARP and Divya Sundaram from Motorola on “Successful Virtual Directory Deployments” [Sept 10 from 11:25am - 12:15pm]

(Hmm, too bad both the panels are at the same time)

I know a lot of folks that will be making it out to DIDW, so I look forward to some interesting conversations over food and libations (drinks are always a good way to get the tongues wagging). An attempt I made on Twitter at organizing a tweetup at DIDW didn’t really take off, probably because it was too early for people’s plans to be made. But if you are going to be there, let me know and I would love to meet up. And I will be spending some time at the demogrounds earning my keep, so stop by if you just want to have a chat.

Tags: Digital ID World, Identity Governance Framework

Coincidentally, the version we are developing internally is code-named IDx (According to Kim, Microsoft’s internal name for Zermatt used to be IDFX). The first version is being built as the underlying platform for Fusion Applications. But my main job on this project is to make sure that it does not end up as an Oracle proprietary framework, and can become a true development platform on which anyone can build identity-enabled applications, running on top of any identity management provider (MS, Oracle, Sun, etc.).

That is a challenging task, and requires a strong standard API as an abstraction between the application and the identity management providers supporting it. One of my hopes for the Burton Groups Identity Services Working Group is that they will help us ratify what this standard interaction needs to be (of course, we are planning on contributing in a major way to the definition of these APIs, and have been working hard on some aspects of these as part of the IGF initiative). Hopefully, we can do the right thing, and justify Pamela’s optimism for the future.

Zermatt allows applications to incorporate a claims-based identity model for authentication and authorization. The claims-based model is one that I brought up in my talk at DIDW almost one year ago. Microsoft has published a whitepaper in conjunction with the Beta release, and I’ll be taking a look at it to learn and to contrast it with our approach. I’ll talk about my thoughts on Zermatt in the upcoming weeks.

Tags: Identity Frameworks, Identity Governance Framework, Identity Services, ISWG, Microsoft Zermatt

I’m not going to recap all the interesting sessions that I attended. If you followed my twitter postings (and a big “Hi and Thank You” to everyone who tripled my following last week by connecting, including some folks who signed up for Twitter just to follow me), you got a sense of what was being talked about, and my thoughts on the same. For some great reporting on the key sessions, read Mark Dixon’s blog postings (this post is a map to the various posts he has written covering the conference).

I’ll simply present what I saw as the theme of the conference: Reality Hits The World Of Identity. People are realizing that the only way this identity stuff is going to work is if the online experience and constructs mirror how we operate in the real world. And this opens up a whole set of new areas to explore.

You Complete Me
A key realization that is taking hold is that relationships must be made a key part of the fabric of identity, and that relationships can form the trust basis for identity related transactions. While I don’t completely agree with Jamie’s assertion that a lot of work in the real world happens before any contracts are drawn up (no contractor can even begin work for Oracle until a contract is signed; similarly I can’t work for Oracle and get access to systems till an employment agreement is in place), I do recognize that the value proposition of transactions is a continuum, along which are different levels that require different levels of assurance. Assurance can be built up over time as a function of relationships (user is related to this company, user has X friends, user is certified by this identity provider, etc). Eve Maler gave a very interesting talk on how relationships can be nurtured and made available in the online world, and connected it to some of the work being done on R-Cards and Project VRM.

I Need An Authority Figure
Another sign that real world concepts are seeping into the online world was the increased discussion on the topic of Identity Proofing, and the externalization of Authoritative Identity Providers. Just like in the real world, companies are realizing that in order to scale  and distribute liability, they would like someone else to be responsible for vetting identity data and providing a validated, trustworthy identity into their environments. This is the first sign of a legitimate market emerging for the Identity Oracle that Bob Blakely has defined, and that I have discussed so often in the context of Identity Services. The Liberty Alliance has jumped in here to help out by proposing an Identity Assurance Framework (our old friend Frank Villavicencio is co-chair of the effort) that can define a trust language in this context. And everyone knows that I consider the work being done on the IGF a critical part of such an infrastructure.

I Got Your GRC Right Here (Not!)
Burton decided to take the IAM vendors to task for using GRC as a crutch to sell all manner of products. Referring to GRC as a four letter word, Bob attempted to blow up the myths surrounding GRC and posited that all the bluster around GRC has made companies lose sight of what they really need to address. He stated that each discipline conflated within GRC should be looked at independently by businesses with regards to its objectives, and that tools and processes should be put in place that address the specific needs identified. The message was clear – there is no such thing as a GRC product; instead there are a multitude of products that provide tools for addressing specific problems that fall under one of these disciplines, and enterprises should take a fresh look at what GRC means to them and how to approach it.

For me, the highlight of the conference was the talk by Nick Leeson, the securities trader who brought down Barings Bank. Not a technical talk at all, his explanation of how his actions exploited failings in the areas of governance and compliance drove home the point about process and tools being complementary parts of the puzzle.

The rest of the conference had some interesting announcements and decent discussions on the usual topics of Authentication, Provisioning and Role Management. I did what little I could to break the monotony and generate some controversy, but I’ll cover all of these in my upcoming posts.

Tags: Burton Catalyst Conference, BurtonGroupCatalyst08, GRC, Identity Assurance Framework, Identity Governance Framework, Identity Oracle, Identity Proofing, IGF, Nick Leeson, Relationship Management

In a nutshell, the Identity Provider (or “Identity Hub” to borrow another term Dave has proposed) is a service that an application can go to when it wants to retrieve identity data for any identity it cares about. This service (and its associated service provider) support some key characteristics:

• Data Virtualization: The IdP leverages virtualization technology to leave the data where it belongs – with the authoritative source of that data (HR databases, CRM databases, LDAP stores, etc) – and retrieves it as needed, combining it across the various stores to present a rationalized, unified profile to consuming applications. This means that the data is always up-to-date, and complicated synchronization connectors can be eliminated.
• Cloud Identity Providers: The IdP should not be limited to physical data stores it has a direct connection to. It must also support cloud identity providers, where the data is coming over the wire (in the form of tokens or claims) as part of the authentication or user-centric interaction.
• Simple API: This is one area where I differ with the discussion. I believe in a higher level programming abstraction that eliminates the need for application developers to become experts in LDAP, SAML or any other standards-based protocol. The API for accessing the identity data is a developer-friendly API that exposes the identity profile using a rich schema. The API layer can deal with multiple protocols underneath, thus allowing any technology supporting any protocol to act as the provider.
• Principle of Least Knowledge: The IdP enforces minimal disclosure of identity data through a combination of features and controls. This is a key characteristic that enables compliance with security and privacy needs by making identity data available to consumers on a need-to-know basis. Among the features that help enforce this are:
  • Support for both definitive (date of birth) and derived (over 21) identity claims.
  • A governance model that controls how identity data is provided and consumed.
• Pub/Sub Models: The IdP provides a way for consumers of the identity data to subscribe to identity data events of interest. When a qualifying event occurs (like a persons address changing or the person being promoted), then the IdP can publish an event that notifies the subscribers of the occurrence of the event.
• Schema Mapping: One of the reasons for the meta-directory not succeeding is the need it imposed on defining a universal user profile schema. This effort is doomed to fail at the very start, since coming to agreement on a universal schema is pretty much impossible. The Identity Services IdP solves this by allowing the IdP and the consuming application to each define their own schemas, and allowing these schemas to be properly mapped at deployment time. Thus an application developer can code to look for an attribute called “Surname”, without having to worry about what is available in the IdP the application will eventually hook up to. The IdP can publish an attribute called “Last Name”, which gets mapped to the attribute “Surname” required by the application during the deployment of the application.

Identity Provider

As has been pointed out, the concept has a great deal of overlap with the capabilities found today in virtual directories. At Oracle, we are trying to combine a set of technologies we have (including OVD) with the work being done on the Identity Governance Framework, to deliver something that looks like this Identity Provider (actually, the name “Identity Hub” is growing on me. What do you think?). Stay tuned for more on this.

Tags: Identity Governance Framework, Identity Hub, Identity Services, IGF, Oracle Identity Management

“Let’s be honest. The meta-directory is dead. Approaches that look like a meta-directory are dead.”

Kim Cameron questioned this in his response. The flaw in his argument (imo) is in lumping directory and metadirectory technology together. Nobody is saying that the directory is dead. It still is (and will continue to be for the foreseeable future) the best storage mechanism available for identity data. What is being said is that the metadirectory approach of taking directory based storage and adding centralization processes and technology (the synchronization, arbitration and flattening of data inherent to the metadirectory story) doesn’t make sense in the brave new world of identity services we are moving towards.

Centralization of data still exists, and will continue to for some time to come. But for a while now, the solution there has been provisioning technology, not metadirectory (see my previous blog post on this topic). Provisioning adds a crucial overlay of policy, controls and process onto the rationalization of identity data (centralization being a byproduct of this).

Where workflow and process are not needed there is no longer a need to centralize, as virtual directory technology provides a scalable, manageable solution far superior to what metadirectory used to provide. Oracle (for one) recognized this a while ago when it bought the technology that became Oracle Virtual Directory.

Virtual directory technology is fast becoming the underpinning of the “identity bus” (as Kim calls it) in an Identity Services based architecture. It provides a services interface that pulls the identity data from where it sits, and transforms it into the claims that the consuming application is interested in. It acts as an abstraction/indirection layer between the identity producer (HR, CRM, Corporate Directory, you name it) and the identity consumer. It also acts as a gatekeeper, ensuring that data use is authorized and policy-compliant. Oracle’s efforts at defining the IGF standard is an attempt to add much needed controls into that interaction of producer and consumer, and OVD is on the very frontlines of this effort.

As always, the mantra should always be to choose the right tool that solves you problems. An Enterprise’s best bet is to put in place an infrastructure that is a nice blend of provisioning and virtual directory. This infrastructure will continue to evolve as the vision for Application-Centric identity evolves.

Tags: Application-Centric IdM, Identity Governance Framework, Identity Hub, Identity Services, IGF, Metadirectory, Oracle Identity Management, Provisioning, Virtual Directory

Predictions are risky business, especially in the slightly schizophrenic world of IdM. On the one hand, things tend to move way too slowly; on the other hand, things emerge out of nowhere to take center stage. So I tend to shy away from making predictions. But I will talk about what I hope to see happen in the coming year. These are not impractical, fantasy wishes that will require me to find a magic lamp buried in the sand. These are things that have a good chance of happening if we as an industry stay focused.

Integrating Risk Management with Identity Management
Recent events have brought to light the need to build comprehensive integration between risk management and identity management software. Oracle’s acquisition of Bharosa last year was a response to marketplace demand to bring more context into the identity management process. There is a better understanding of the complex heuristics that need to become part of identity management decisions, and how to encapsulate them as workflow and rules. The coming year should bring more tools and more capabilities in these areas.

For the longest time, people would talk about integration in the context of product suites. The focus will now shift to integration in the context of pre-canned and pre-defined solutions and workflows.

Role Management Comes Into Its Own
Over the last couple of years, we have seen Role Management become an established part of identity management. But its real value will be realized when it stops being an explicitly deployed and managed part of IdM (a la access management) looking for consumers, and evolves into a business tool that is deployed within the enterprise context of provisioning, entitlement management and ERP. A number of other folks have already challenged vendors to do this, and hopefully a lot of work going on in this area will come to fruition.

The Evolving Identity Framework
There are a couple of things I hope to see happen this year that will help us move towards our ultimate vision of how identity is used.

• The Identity Services message has been very well received every time I have presented it. In the last year I met a number of individuals, like the folks from the Jericho Forum, the Concordia project, and a number of people at various conferences, who are really committed to changing how Identity becomes part of application development and deployment frameworks. Hopefully the coming year will see some concrete progress made in defining the necessary framework architecture that will enable the externalization of identity from applications
• We have seen everybody and their mother make moves to become OpenID Service Providers, especially the big identity silos. Hopefully this year will see an explosion of services that are OpenID Relying Parties, including some of those same big players. The real adoption of OpenID will come not from the glut of OpenID SP’s, but from the widespread availability of services that accept OpenIDs and do not require registration and username/passwords.
• I also hope to see someone take the Identity Oracle concept and create a viable business out of it. It may not explode right away, but it will start to emerge. It seems obvious that the easiest place for this to happen is in social networking applications like Facebook. They already hold a lot of identity information that they then serve to other applications (those annoying, currently non-critical Facebook apps that clutter everyone’s profile). Putting in place more controls on how my information is shared and with which apps, and then opening the walls to outside applications would be a logical progression in the evolution of identity providers for internet applications. I also hope to see the Identity Governance Framework become part of such a control framework in any Identity Oracle.
  And then hopefully at the start of 2009 I will be commenting on my hopes for the acceptance of internet identity framework tools within the enterprise.

Your Hopes
What are your hopes for the coming year? Leave a comment, or email them to me, so that we can add them to this list. and hopefully take notice.

Tags: Entitlement Management, Facebook, Identity Governance Framework, Identity in Social Networking, Identity Services, IGF, OpenID, Personal Identity Management, Role Management

No, I have been deeply engaged in discussions on the future of IdM in fusion architecture, a discussion that necessitated an all-too-intense trip to Oracle HQ for some much needed discussions. And since I was in HQ, people took the opportunity to engage in planning discussions for future versions of OIM, leading to a pretty hectic week, and some deliverables that have kept me from going back to the blogs for a while.

So when I finally got back to Google Reader, I saw some responses from Pamela Dingle (who was responsible for kicking off my blog thread) and Dave Kearns. While I always appreciate their perspective, I do have to disagree with some of the points that they are making, maybe because I come from a different point of view (the vendor instead of the implementor/analyst).

First off, let me say that I completely agree with Pamela when she says that an enterprise should consider tools that solve real business problems they have, not imaginary problems they think they have to address because of some marketing kool-aid they have been drinking.

But in her post, Pamela says the following:

“The idea that ‘user-centric’ has to mean anything at all in an Enterprise context, just makes no sense.”

Huh? User-centric has to mean something (unless Pamela is saying that it is pure marketing gobbledygook conjured up to create a market for yet more products), and therefore it has to mean something for an enterprise. What exactly it means is what was being discussed in the blog thread that she labeled “philosophical”.

To me, the term “user-centric” has always been about the philosophy (and therefore process) of how identity is handled. It promotes transparency, and empowers the identity stakeholder to exert control over the usage of their identity data. No tool is “user-centric”, but there are tools that can help businesses employ identity in a user-centric manner. And to me, that means that the processes that use identity have to be user-centric.

Pamela says:

“If these tools were built properly, the philosophy should be inherent, not resultant – in other words, you should get user centricity as part and parcel, the kernel of the technology that makes it user-centric shouldn’t be subtractable – but user centricity doesn’t have to be the actual problem that is solved along the way.”

To assume that tools will solve issues of process is wrong. Tools give enterprises the means to enact and deploy the business processes and policies that they want to put in place. They do NOT provide the enterprise the processes and policies themselves. Deploying a provisioning system does not solve your SOX problem. Deploying it in conformance with processes and policies that the enterprise defines (independent of the tool) is what provides SOX compliance. I already pointed out that too many enterprises confuse the tool with the solution. And the so-called user-centric tools are the same way. Pamela herself has pointed out that one can deploy these tools in ways that are in no way user-centric (doesn’t that imply that user-centric means something, by the way).

Debating and understanding the philosophy (not the tool) is important because that is what will define the processes that the enterprise would put in place, and the processes would then determine the right tools for the job. Pamela is correct in pointing out that tools don’t come first, business solutions do. And as tool vendors, it is our job to understand (forecast) the philosophy that will drive the solutions so that we can figure out what capabilities we want to build into our products.

Here is an example that I am dealing with right now.

I am sure everyone that reads my blogs knows that one of the projects Oracle is championing is the Identity Governance Framework that provides a declarative way for stakeholders in identity data to publish rules around how identity data is used and disseminated. It is a direct outgrowth of the need for privacy controls, and as such it has to play in the space we call user-centric identity.

Well, one of the ongoing discussions at Oracle is how the IGF fits into the future of our provisioning product. With a true identity services architecture many years away, and legacy applications going nowhere anytime soon, enterprises will continue to have provisioning products synchronizing identity data from one place (source) to another (provisioning targets) for some time to come. How does the IGF play into this? Does the workflow that dictates how identity data flows from the source HR application to a bug tracking system downstream have to accommodate the IGF in it? Without understanding where enterprises are going to go with this user-centric stuff, it is difficult for us to determine the correct capabilities to introduce into the product. Sure, we could make a few assumptions, even talk to a few of our biggest customers. But the best way for a vendor to succeed is to be aware of the trends in the consumer space, the emerging thought processes (and philosophies), and factor those into our determinations.

Pamela and Dave are clamoring for solutions, as well they should. But what solution should I (as a vendor) be providing? Understanding that is the intent of my discussion. I need clarity on what it means when an enterprise says that they want to embrace this vision of user-centric identity management. I know what my end-goal is: an architecture built on identity services that eliminates most of the problems we are trying to solve. But until we can achieve that, I still need to figure out a whole lot of intermediate steps that will get us there and still solve the most pressing problems we have around privacy, efficiency and integrity.

Tags: Identity Governance Framework, IGF, User-Centric Identity

Pamela Dingle recently commented on her blog about Patrick Harding’s observations on this topic. The discussion is specifically around employees in an enterprise, so it avoids dealing with the enterprise-customer interaction where using user-centric methodologies can be defined a little more clearly.

User-centricity at its core is about involving the user in the use of their identity data, something that does not happen in enterprises today. Most employees hand over a bunch of their personal identity information to HR on the day they are hired, at which point it becomes enterprise data. The employee no longer knows what is happening with that data and how it is being used. Sure, the use of self-service tools gives these employees the ability to manage that information and keep it up to date, but that is simply a maintenance feature that eliminates unnecessary administrative overhead. It does not give the user any control over how that data is used.

Pamela points out that technologies like CardSpace and OpenID, which are labeled user-centric, can be deployed in ways that violate every tenet of user-centricity. It is not the technology that makes an environment user-centric, it is how it is used. So when I get the question “We want our (enterprise/applications/IdM deployment) to be user-centric. When will you support CardSpace and OpenID?“, it makes me cringe.

The fact is that you can only be user-centric if you involve the user in the business process where that identity data is being used or moved around. Doing that will first require you to understand your current processes and identify the places where it makes sense to involve the user. Only then can you figure out the technology required to make that process happen. This is yet another example of a place where we must not equate the technology with the solution.

It was with this fresh on my mind that I went into a meeting with some analysts on the topic of identity services. In that discussion, we found ourselves being challenged on the relevance of the Identity Governance Framework to enterprises. The analysts opined that while the IGF would make sense in a consumer world of Identity Providers and Relying Parties, it doesn’t seem to fit into a tightly controlled, regulated and (ostensibly) optimized enterprise environment.

As we struggled to explain how we thought the IGF was relevant to enterprises, I found that we were relying a lot more on descriptions of application architectures, development methodologies and compliance requirements as opposed to user experience and involvement. The fact that an employee views everything in the enterprise as one big application, and therefore doesn’t care about those processes going on behind the scenes, seemed to stick out like a sore thumb. As an employee, I want everything to just work seamlessly, so I can concentrate on my job. So as long as the flows are within my enterprise boundary, I really don’t find myself wanting to be bothered. Once it goes beyond the enterprise boundary (like to 401K providers and travel agencies), I do care very much.

So does user-centricity have a place in the enterprise? I’m not sure. Opening up the enterprise to external identity providers may force the adoption of user-centric technologies, but it won’t mean that once I am “in” the enterprise and have given them access to some data, I can still control how that data is used (or would even want to). Modern enterprises are too complex for me to be involved. I’d settle for some involvement when my employer federates with someone. For everything else, just make it work.

Thoughts?

Tags: Identity Governance Framework, Identity Services, IGF, User-Centric Identity