Blog

Another MSSP (Symantec) Joins the Identity World - Who's Next?

Last week, Frank Villavicencio (Identropy's EVP) blogged regarding the Identity-as-a-Service (IDaaS) market direction, and the potential for MSSPs to step in to fill the vaccuum of a trusted provider for clients in the delivery of IAM solutions.

In fact, in his conclusion, he predicted:

Over the next three years, IAM will shift from the traditional deployment model (buy, host, deploy and operate) to an IDaaS model, making the latter the default. IAM technology will be mainly designed to enable IDaaS deployment models, and customers will most likely procure IAM via their MISP [Managed Identity Service Provider] of choice.

It looks like his words are proving true sooner than later (although I'm not sure if the term MISP will catch on).  Yesterday, Symantec announced its plans to acquire of Verisign's authentication business for $1.28 billion.  Here's an interesting quote from Symantec CEO, Enrique Salem:

"With the combined products and reach from Symantec and VeriSign, we are poised to drive the adoption of identity security as the means to provide simple and secure access to anything from anywhere, to prevent identity fraud and to make online experiences more user-friendly and hassle-free."

OK...so not exactly IDaaS in its full glory, but definitely a step in that direction.  Although MSSPs like Symantec love low-complexity technologies with predictable delivery models, they still seem to be gaining an appetite for some areas of identity - such as PKI, Federation, 2-Factor Authentication and Fraud Detection.  With Verizon, SecureWorks and Symantec in the game, I think its just a matter of time before they begin embracing other areas of the identity stack. 

Are MSSPs the future of IDaaS?

Or is it the reverse: Is IDaaS the future of MSSPs?  That is the question...

For some time now, I have been talking about Identity as a Service (IDaaS) and discussed a few approaches to IDaaS for Enterprise Identity Management, which truly set a baseline for what we believe is the next paradigm in Identity and Access Management (IAM): the shift towards managed services, away from traditional Enterprise deployment models.

Are we talking about a paradigm shift?

I believe we are.  Let me illustrate with a few questions:

1. Have you been involved in, or responsible for, the deployment of an IAM solution?
2. Has this deployment succeeded in meeting the business objectives and stayed within the timelines and estimated budget?
3. Has your organization needed only one attempt to implement an IAM solution, without re-architecting, replacing technology vendors or system integrators, etc?
4. Is your organization able to measure the return on investment (ROI) on this initiative?
5. Lastly, was your ROI positive?

After over 12 years of experience deploying IAM solutions, large and small, I have seen only a small percentage of people who answered these questions in the affirmative. Even though the number has increased over the years, it is still not as high as most would want or expect, given the availability and maturity of IAM technology.

Why is this so?  Many respondents cite issues with the technology choices underpinning the solution. Others point to a lack of alignment and sponsorship between technology and business stakeholders. Some say that there were no clear business objectives and expectations were not properly managed.  A few venture that IAM solutions are complex and difficult to implement and underestimating their size or complexity proved a recipe for disaster.

All of these are valid reason.  But does this mean that most IAM solutions are doomed to fail?  The answer is not very encouraging if you follow "traditional" deployment approaches. To date, most if not all IAM deployments follow a scenario like this:

Faced with requirements from the business, IT selects a technology vendor, allocates the environment in which it will run (hardware, software, network, and data center), and in most cases engages a system integrator to help design the architecture, map the business requirements and processes, and implement the solution.  Once deployed, IT is then tasked with hiring, retaining, or developing the qualified personnel it needs to operate the infrastructure.  As we discussed in a recent blog post titled "Top 10 Common Pitfalls of an IAM Initiative", this combination of factors causes most projects to run longer and cost more and, in many cases, do not meet the business requirements they were meant to address. The organization is then left with a capital expenditure that needs to be recovered over time.  Therefore, IT embarks on programs looking to integrate more applications and absorb more environments (M&A, intranet, extranet, etc.)-and their success rate increases only marginally.  In many cases, attrition of the internal personnel further complicates the ongoing success of the deployment.

Sound familiar?  The fundamental issue with the "traditional" approach is that the organization's best interest is not well aligned with that of the partners it relies on to undertake the deployment.  The organization is at the center of the storm, looking at mediating and balancing the interests of vendors, system integrators, and, its own staff, who are typically not qualified to deploy an IAM solution or aware of its complexities.

This is why a new approach is needed-one that aligns more closely with the interests of the organization.

 In my view, this paradigm shift is the motivation for IDaaS.  One could also say that the economic conditions of the last two years, combined with the rise of the Software-as-a-Service (SaaS) model have been catalysts for this new direction.

But what is different about IDaaS?

The idea with IDaaS is that rather than having the organization strike a balance among the interests of vendors, system integrators and its own staff, an external entity acts as a trusted provider, entering a long-term relationship that is gauged by measurable results (i.e. SLAs, performance metrics, delivered milestones, etc.)

From the organization's standpoint, this model can alleviate the need for selecting, purchasing, and depreciating IAM technology; building, maintaining, and operating the IAM infrastructure; customizing and integrating various products; and staffing, training, and retaining personnel to manage the IAM environment, all of which will immediately translate in a reduction in costs.

The idea is to engage a trusted provider to build, integrate, deploy, and operate an IAM infrastructure that suits the organization's requirements. This approach should reduce upfront costs (not needing to procure hardware and software and their respective maintenance annuity), which are now blended as part of the managed service.  Likewise, by not having to recruit, train, and retain specialized staff to operate the environment, the model expedites deployment timelines and reduces operational costs and risks to the organization. For the provider, the need to reduce the implementation timeline and create the capability of a repeatable model forces it to streamline the deployment process and ensure that it is done with such quality that its operation after deployment requires minimal involvement. In the end, these elements accelerate time to value.

Under this model, the trusted provider is involved in the delivery of the IAM solution, which is then governed by established parameters and service standards. Whether it is hosted on premises or outsourced (in the "cloud"), in the end the organization sees immediate and measureable value for the services they purchase-in a predictable and simpler manner.

Well, this kind of sounds like an MSSP model?

Bingo. This is precisely our prediction: the IAM deployment model as we know it is already being transformed from a highly complex approach toward a simpler one. It does not mean that IAM technology is simpler; it just means that the deployment model needs to get simpler. 

"Everything should be made as simple as possible, but no simpler." - Albert Einstein

From my standpoint, this is just a natural evolution, and while it will take time for it to pan out, it is already at play, as evidenced by events like these:

• April 27, 2010: Verizon and Novell Unveil Cloud-Based Security Solution - an interesting quote from the announcement grabbed my attention: "Additionally, as part of this agreement, Verizon will be Novell's preferred identity and access management managed service provider."
• December 12, 2009: SecureWorks Expands its Global Operations and Services with the Acquisition of UK-based dns Limited - here are two relevant quotes from the announcement: "For ten years, dns has been delivering a wide range of security services to its clients, including an innovative Identity and Access Management Service"; and "SecureWorks is expanding the scope of its service offerings with the addition of dns' Identity and Access Management Practice which will benefit clients worldwide."
• May 14, 2007: Verizon Business acquires Cybertrust - and the quote: "Cybertrust's services include identity management, managed security services, vulnerability/threat management, security certification programs and a range of professional services..."

Similar events have been taking place for some time, such as IBM Managed Identity Services (part of IBM's Managed Security Services) and BT's Identity Administrations Solutions.

If you follow this logic, you will see that two paths are intersecting:

1. Established MSSPs are adding IAM to their model because they want to differentiate and grow their role as a trusted partner to their clients or are responding to client pressure.
2. IAM solution providers, and even software vendors, are evolving and embracing the SaaS model, and as such are starting to morph into MSSPs with a focus on identity, or as I like to call them: MISPs (for Managed Identity Services Providers)

Our prediction

Over the next three years, IAM will shift from the traditional deployment model (buy, host, deploy and operate) to an IDaaS model, making the latter the default. IAM technology will be mainly designed to enable IDaaS deployment models, and customers will most likely procure IAM via their MISSP of choice.

Considerations for an Identity Management Initiative in 2010

First off, I would like to express my sympathy to victims of the terrible earthquake that hit Haiti. I can only wish that the rescue and recovery efforts yield positive results.

Thanks to the recession, we have learned a lot (or so we would like to think) on the importance of sound business decisions, have we not?

This blog post is my attempt to bring some of the lessons learned, along with scar tissue, that I have been able to sum up from the last 24 months, as it relates to identity and access management initiatives. Last year, I spent time reading some Harvard Business Review articles, and recall reading a blog post titled: "6 Lessons Learned in the Downturn" by Anthony Tjan, which were very influential in shaping my thoughts for this post.

At the risk of stating the obvious, I would start by saying that the last 24 months have forever changed the way in which Identity initiatives will be carried forward.

It is clear that identity and access management systems are, more than ever, critical parts of any IT infrastructure. Organizations will always need to grant application and system access to those who need it and eventually remove that access once it is no longer needed. This is a recession-proved observation. The circumstances of today's economy highlight the need to tackle these activities in a more efficient, transparent and scalable way, and in most cases, automation is about the only choice you've got. Manual labor is way too expensive today, even when outsourced. This should be an encouraging statement for any identirati.

5 Lessons Learned

Below are five points that best capture the essence of this change.  These are based on experience working with clients across many industry verticals:

1. Your dollar needs to go a much longer way than before - If you even have an approved budget, you really need to maximize the value you will get from your initiative, and be ready to show how. Consider getting a second opinion before you buy new IDM technology. Ask yourself some questions:
• Have you done proper due diligence?
• Do you or your team have the cycles to invest in carrying out the proper due diligence?
• Are you relying only on what the vendor says or what you read on an analyst report?
• Do you have enough insight on how to negotiate with the vendors you have selected, based on what is important for your initiative?

We have seen from experience that even a nominal 2-week investment in an Identity Management Workshop that assesses your current state, identifies business drivers, high-level requirements, and formulates an implementation roadmap can go a long way.

A case in point: One of our clients allocated $750,000 in budget to acquire IDM technology in 2009.  Before moving forward, they invested in a workshop and in the end, identified a set of previously unknown requirements and ultimately saved 40% ($300,000) in their purchase, all within 8 calendar weeks. Considering what they spent on our services, this is an ROI in excess of 450%. Not bad in any type of economy if you ask me.

2. Minimize capital expenditure if you can - Consider lease vs. buy scenarios. The maturity of IDaaS today provides options for customers to avoid procuring software and hardware products that require capital expenditure, and instead consume them on an on-demand basis as an operating cost. This of course will maximize your cash-at-hand. Evidently, not all of your identity and access management needs can be met with an IDaaS approach, at least not today, but I would argue that 24 months ago this was not even an option to consider. There are several approaches to IDaaS, which can be appropriate to your initiative. It may be worth exploring these and engaging with providers that specialize in these kinds of models. Not all organizations are ready or comfortable with an all-in-the-cloud approach, but there are managed services models that work on-premise that should be explored.
3. You have to have metrics - For identity and access management initiatives, there is no longer room for soft ROI; hard dollar is king. As you define your Identity initiative, you need to think about how you can measure value and ROI to the organization. For some organizations, which adopt internal chargeback models for managing budgets, this should be relatively easy. The idea is not to stop at simply measuring costs, but ensure that you are measuring returns. In a way, try to make your metrics meaningful to the lines of business that you support (i.e. your internal clients). A metric that is often overlooked is time to value - everything being equal in cost, you should look to shorten the wait until you can show measurable value to the organization. In practice this will help you decide how you undertake your initiative. Maybe shorter phases are better than longer ones. Perhaps rather than a pure waterfall project management approach, you start to introduce agile methodology concepts. We have seen initiatives whose budget is cut in mid-flight. Even though you cannot fully prepare for this, you want to consider what you will show for if it ever happens, and whether or not delivering value early is the key to preventing your funds from being cut in the first place.
4. Let's demystify identity management - This may get controversial, but after 14 years of experience in IDM, I would like to demystify it. I agree that IDM is complex, requires specialized skill sets, and above all, is unforgiving if you do not have the right experience, but at the same time it is not unattainable, and settling for less is not the right posture. There are many ways to meet compliance requirements, even if you have not automated all of the access granting flows in your environment.

I applaud the advent of identity activity monitoring (the term we like to use to describe this new trend) in 2009, and while the analysts have not yet coined a particular name for it, there is a great report by Gartner's Mark Nicolett and Earl Perkings that focuses on this area, separate from just SIEM or just IDM, more as a separate niche in its own right.

I intend to further discuss identity activity monitoring in a future blog post, but for now, I would describe it as an approach to tracking user activity in various IT systems and applications that is correlated to the definition of a digital identity; thus creating a closed feedback loop that allows you to more confidently determine if your IDM controls are effective, regardless of whether they are automated or manual. In this way, organizations have a way to extract value out of lazy assets (such as application, database or system logs), which otherwise are used only for security event monitoring, and leverage them to increase visibility into what users are doing within the IT infrastructure. This is a very clever and effective way to approach some of the compliance requirements that Identity initiatives often try to address, in a faster and cost effective way. Moreover, it does not conflict with a traditional IDM implementation, but rather complements it.

5. Understand and embrace identity assurance - this is not limited to scenarios in the extranet in which users from one organization interact with systems in another - scenarios that some would deem esoteric and not as business critical. Even within the same organization, you need to pay attention to identity lifecycle as a whole and not just as discrete steps: provisioning, authentication, single sign-on, etc. Consider the intersection of identity assurance with your data and risk classification, and ask yourself: am I spending too much in authentication technology and too little in the process of ensuring I know who the person is? Is it the reverse? Strong authentication alone is useless from an identity assurance perspective (a good friend assures me that a well-trained Labrador could figure out how to use a smart card - although I have not seen the documentary on TV yet). The point here is to ensure that your effort and investment is balanced in light of your requirements. Otherwise, you may be wasting precious dollars.

To illustrate, here is a real life example: a client has a request/approval process in place to manage the issuance of access cards (with no picture ID) to various facilities in their organization. When an employee first comes on board, to issue an access card, they undergo a process of vetting their identity against information in HR, and that the request that has been approved by two management levels. Now, since the process often takes a few days to complete, some managers tend to hold on to the access card from a departed employee, and literally keep them in a drawer. When a new employee comes onboard, the manager recycles the access card and increases the employee's productivity by orders of magnitude, but all access activity and access authorization is based on the departed employee's information. The organization is now incurring significant costs to ensure that access to its facility is tightly managed, but the process for ensuring that a departed employee event triggers the deactivation of the access card is not well enforced.  So in the end, this imbalance in identity assurance costs the organization money and does not really mitigate the risk it was intended to.

I would love to hear comments and feedback on these points, particularly if you disagree.

Approaches to IDaaS for Enterprise Identity Management

Happy New Year 2010 to all. Best wishes in the year that just starts.

I will start this year's first posting by acknowledging Burton Group's (just acquired by Gartner) Bob Blakley September 30^th, 2009 vantage point titled: "2010 Identity and Privacy Strategies Planning Guide: A Market in Transformation", which has been an excellent reference in helping me shape some of my thoughts for this article. I think it is a great document with great insights on current trends in identity management.

My prior blog posting introduced a definition for Identity as a Service (IDaaS), setting the stage for this posting, which discusses models for deploying IDaaS, from the perspective of the entity that consumes the Identity service, in this case an organization (as opposed to an individual). The assumption will be that the entity and the service provider are two separate organizations, and moreover, two separate legal entities. In a way, this perspective is no other than the Enterprise identity management.

In addition, for this discussion, we will try not differentiating the kind of Identity services being provided (provisioning, registration, authentication, etc.), or which user population within the entity it is intended (i.e. employees, contractors, suppliers, customers or business partners). The idea is that the approaches should be applicable to all of them.

Defining Managed IDaaS

In this article's context, Managed IDaaS is an approach to IDaaS in which the entity employs one or more separate legal entities as service providers. The service provider is contractually bound to specific terms that define how the service is performed, and it governs its adherence to these terms through mutually agreed and measurable service level agreements (SLAs). In other words, Managed IDaaS, is the scenario in which an organization consumes Identity services from an external service provider. These services can range from operating a provisioning infrastructure, to verifying the identity of a person, to providing strong authentication or federated authentication credentials, to managing passwords;  and they can be provided both internally (i.e. within the organizations Intranet) or externally (i.e. through an extranet portal), and can physically reside on-premise or in the cloud, or a combination thereof.

Two main variants of Managed IDaaS are common today, and as Gartner forecasted, they should trend upwards in adoption within the next two years. They are mainly determined by who is responsible for and who owns what part of the Identity service infrastructure, which in many cases correlates directly to where the infrastructure component actually resides:

• Cloud IDaaS - where the service provider owns and operates the entire Identity service infrastructure, and provides it to the entity in a pure SaaS manner, without any sort of footprint or backend integration with the entity's IT infrastructure. Identity information is exchanged in an offline (manual or batched) manner.
• Co-sourced IDaaS - using Wikipedia's definition of co-sourcing, this is an approach in which the Identity service interacts directly or through some technical footprint with the entity's IT backend infrastructure (directories, repositories and other target systems). The entity and the service provider have a shared responsibility for building and operating the Identity service, the balance of this responsibility determines distinct scenarios, which we will focus in more detail in this article.

To better understand Managed IDaaS, it is useful to decompose it into building blocks. The diagram on the left provides a high-level structure for an Identity service, made up by three main functional areas:

Consumable Identity Service - this is the end point of the service, which interacts and integrates with the consuming entity, whether an end user interacting through a web UI or an application or repository that exchanges information with the service. This is the area in which the specific logic and functionality provided by the service is actually "wired".

Identity Management Stack - this is the middleware of the service; the software modules that provide the basic functionality to manage and process identity information.  The diagram shows an arbitrary sample of the software components that make up the identity management stack. It is not mean to be an exhaustive list, but rather a representative sample. Nishant Kaushik has done a great job explaining the identity services framework, which instantiate the identity management stack.

IT Platform - this is the technical backbone of the service. The basic IT computing infrastructure that is not specific to identity management, but generic to any IT service.

These three basic functional areas are useful in explaining how variants of a Managed IDaaS come to life, particularly co-sourced IDaaS.

Co-Sourced IDaaS

It is a Managed IDaaS variant in which the Identity service's consumable service interacts directly with backend (or back office) IT infrastructure managed and operated by the entity. And more importantly, one in which the entity and service provider enter into a partnership in which they share some of the responsibility in building, hosting or operating the Identity service.

The diagram below illustrates four common co-sourced IDaaS scenarios, which we'll discuss next. I admit that while I have spent time thinking about these scenarios, I do not think I have articulated them in a way that clearly delineates their boundaries (if any), so I am hopeful that by venting them out, I will get very good thoughts from you.

1. All on-premise, provider operated - when the entity owns the identity management stack used to build the service, as well as the actual IT platform; and the Identity service is hosted on the entity's premise where it integrates directly with the entity's backend IT systems in the Intranet. The service provider is responsible for configuring and operating the consumable Identity service. This model is a more "traditional" Enterprise identity management deployment approach, where an organization procures the entire IT stack, and hires an external integrator to build, and possibly operate the Identity service, according to defined requirements. The organization and the integrator establish service agreements which govern roles, responsibilities, response times, escalation procedures and son on.
2. Provider hosted and operated - where the service provider hosts and runs the entire Identity service, and integrates directly with the entity's consuming backend IT systems. This scenario is seen often at organizations that outsource their IT infrastructure and operations to an IT outsourcing service provider, and the Identity services are collocated and dedicated to the organization. From a connectivity perspective, the Identity services are typically accessed via dedicated lines (private clouds, private VPN). In this scenario, the service provider is often responsible for procuring and operating the consumable Identity service, the identity management stack and the IT platform. The outsourcing service provider and the organization establish service level agreements as well as licensing agreements which ensure that the organization is entitled to use the technology infrastructure require for the Identity service. This scenario is typically single tenant for both the consumable Identity service and the identity management stack functional areas.
3. Hybrid: on-premise and in the cloud - where the service provider hosts and runs the entire Identity service in an environment hosted in the cloud, and requires some technology footprint to be deployed on-premise at the entity's IT environment to effect the integration with its backend IT systems. The scenario is one where the organization "leases" the Identity service from the service provider, which includes the use of the on-premise footprint - say a virtual or physical appliance, and access to the actual Identity service which is hosted in the cloud. From a connectivity standpoint, the appliance provides secure communication through the public Internet, and it may also provide caching and queuing to increase the reliability and responsiveness of the service. The service provider owns and runs the Identity service backbone and may adopt a multi-tenant model. The organization and provider agree to service SLAs, which will also govern how the on-premise footprint is operated.
4. All in the cloud - where the service provider hosts and runs the entire Identity service in an environment hosted in the cloud and it integrates with the entity's backend IT systems without requiring additional technical footprint, leverage secure, open standards-based interfaces over the public Internet. In this case, the organization "leases" the Identity service from the service provider, and configures its backend IT systems to communicate directly with the service. The provider owns and runs the Identity service backbone and will most likely adopt a multi-tenant model. The organization and service provider agree to SLAs under an Application Service Provider model.

In future postings, we will discuss considerations and advantages of the co-sourced IDaaS model. In the meantime, I look forward to your comments.

Defining Identity as a Service

In the midst of the holiday season, and with the anticipation and emotion that comes with the end of the year approaching, I have decided to write my first blog - an early new year's resolution perhaps. I must state that I have resisted the urge to blog for the last three years of my career for two reasons: on one end, I feared starting to blog and then dropping off and being inconsistent (just like I have been every time I started at the gym), on the other end, I dreaded becoming addicted to blogging and seeing it impact other priorities. But let's just say that I am resolved to give this a good try by sticking to some basic rules: keep the content lean but meaty, keep a constant blogging frequency, and try to be as interactive as feasible - sounds simple. Let's see how I fare (maybe I will also get in shape in the process)...

What is Identity as a Service (IDaaS)?

2009 has seen an increased interest and focus in a relatively new topic in identity management "Identity as a Service (IDaaS)", but just like any upcoming trend, it tends to be understood differently, explained differently and used differently depending on context. Burton Group provides a very concrete definition that focuses on the outsourcing of identity management, such as authentication, provisioning and attributes services. Dave Kearns has covered this topic extensively as well, under the context of "Externalizing Identity into the Cloud". My friend Nishant Kaushik defined the term in 2007 as "the notion of making identity management capabilities available as an infrastructure service to all applications in a SOA environment".

In a way, this reminds of the late 90's when the term identity management was making its foray in the world (yes I admit that I was an identity guy back then - lucky me!), and everyone had its own definition and everybody from Dun & Bradstreet to Access360 to Oblix provided identity management. And I think that the term is still misinterpreted today, though not entirely misunderstood, just like any normal teenager at this age.

So, one would wonder: why propose yet another definition for IDaaS? Well, I encourage you to keep on reading, as I think I will make my point clear, and hope to ignite good comments and discussion along the way.

With that: what is IDaaS? It is an approach to digital identity management in which an entity (organization or individual) relies on a service provider to make use of a specific functionality that allows the entity to perform an electronic transaction which requires identity data managed by the service provider. In this context, functionality includes but is not limited to registration, identity verification, authentication, attributes and their lifecycle management, federation, risk and activity monitoring, roles and entitlement management, provisioning and reporting. 

The relevance, or perhaps novelty, of this definition, is that it focuses on the interaction of four elements: the entity, the service provider (which could be the entity in some cases), the specific functionality and the electronic transaction.

The Context of IDaaS

I believe that IDaaS as a concept has seen increased interest and coverage this year, in big part due to the impact of the global economic challenges which are forcing organizations to revisit its models for adopting and implementing IT initiatives that require identity management, as well as an increased emphasis in regulatory compliance and privacy awareness.

In any case, there are some important considerations regarding the definition of IDaaS that I would like to point out:

• It is not meant to be just a technical definition. And while the definition does not conflict (I would hope) with a technical definition or architectural approaches, it is important to think about IDaaS from a legal and jurisdictional standpoint as well. In this context, the definition of ownership, responsibilities and liabilities is significant to all parties involved in IDaaS. Tom Smedinghoff, a well-known contributor to the identity management industry, has created great content and led several initiatives that are bringing the legal aspect of digital identity management at par with its technical evolution, all of which is relevant to adopting IDaaS.
• The strength, rigorousness and thoroughness by which IDaaS is provided, should be measurable in an objective and demonstrable way, such that they can convey a specific level of confidence or assurance to the parties. This in turn will translate to a risk mitigation level that the parties can agree to be sufficient for a specific type of transaction. The Identity Assurance Certification Program run by the Kantara Initiative provides a very concrete vehicle to achieving this measurement.
• IDaaS should not be restricted or misconstrued as only applying to "cloud" based models. While IDaaS is particularly relevant for cloud-based services, IDaaS could also apply to on-premise models. In fact, I argue that it is in this area where the definition is most beneficial, as organizations can view its internally-facing (and possibly internally deployed) identity management infrastructure as identity services, allowing the demarcation of service scope and boundaries that will make outsourced, on-premise, cloud-based models or any combination therein more concrete, and easier valuate in business terms. The intention is not to confuse IDaaS with "Cloud Identity" or with "outsourced identity management", since the term could apply to all these cases.
• The concept should also not be restricted to enterprise IDaaS vs. consumer IDaaS, since the notion is basically the same. Evidently, the actors, the types of transactions, the levels of sensitivity in them, and other elements will vary greatly from enterprise to consumer environments, but the notion of how digital identity management applies to each could be thought of in the context of IDaaS.

Why is this even relevant?

My motivation to introduce this definition at this point is to attempt to set a common understanding of terms, allowing us to better understand the new trends, services and paradigms in identity management that are unraveling before our eyes. As I believe that a significant shift in identity management from a monolithic model to a true services-based infrastructure, has been at play for the past 2 years, with noticeable effects only in the past 6 months.

With this shift has come some degree of confusion in the industry among identity management in the context of cloud-based services (i.e. SaaS, Infrastructure as a service), identity federation (claims or assertion based) and the more traditional enterprise deployment models, to a point where they are at times seen as independent or separate; causing people to think of IDaaS as not relevant to the enterprise facing environment or mystifying it as another "cloud" term. And in some unfortunate instances this confusion has impacted the way an organization looks at implementing an identity management solution (either by limiting the range of options that it could look at or by widening it to include the wrong set of options).

I intend to demystify this concept a bit more in subsequent blogs, and attempt to bring more pragmatism around it by explaining how it applies to concrete scenarios. In the meantime, I appreciate your comments and reactions.