There has been some discussion around the announcement in blogs and forums in the Internet. One of the most interesting aspects discussed is the necessity to educate the broader public about the concepts and value of Information Cards and the entire “Identity Management for the cloud” (aka user-centric Identity Management, aka Identity 2.0). That must be a main target of ICF, but as well of all the other players in this emerging market.

First of all, I’m convinced that Information Cards as well as OpenID will become central standards in the Internet and for Identity Management. Given that at least OpenID isn’t that far away from reaching the critical mass and that Microsoft Vista adoption (which makes it easier to use CardSpace) is happening pretty fast, as well as some important Open Source initiatives working on these topics, that might happen earlier than most expect today.

Nevertheless it is important to explain the concepts for everyone – and to address the privacy and security concerns many will have. There are so many things which can be done using these technologies, from Single Sign-On and Profile Management in the web up to Corporate Business Cards. But they require an accepted concept.

Thus, the idea of ICF is great, when it goes beyond technical discussions around use cases and implementations issues and really focuses on education as well. On the other hand the member list of ICF proves that there is strong interest and support in the industry for Information Cards. You can bet that no one is in there who doesn’t expect that the use of Information Cards won’t support his business – otherwise they wouldn’t invest time and money into ICF.

ICF is a great thing from my perspective. It will drive Information Cards forward – and thus the Identity Management for the cloud.

Besides the ones which are obvious players in that future market segment like the risk-based authentication vendors (Arcot, Entrust, Oracle, RSA and some others) there are some other categories of vendors which offer even today at least some context-based authentication and authorization. One of them is Citrix. Given the number of installations of the Citrix Access Gateway they might even be sort of the leader in that market.

You might argue: A SSL Gateway is not a solution for context-based authentication and authorization. Yes - and no. No because a SSL Gateway without additional components is just a SSL Gateway. Yes, if you combine a Citrix Access Gateway with other things. At an Citrix Analyst Briefing yesterday, a Swiss bank talked about their approach for controlling access of remote workers. They use the Citrix Access Gateway together with many other Citrix technologies and with a NAP (Network Access Protection) tool from EPA factory.

This tool provides some information about the state of the clients. There is also some information about the device which is used and there might be some derived location information. That information about the context in which a user is acting is used at the Citrix Access Gateway. Policies control whether - and with which authentication requirements - authentication is done and what the user is authorized to do.

In the result this is nothing else than context-based authentication and authorization.

For sure there are shortcomings. You need tools from at least two vendors, even more for additional authentication technologies. It requires a Citrix environment (which is nothing bad - but not everyone has one). The location detection is probably not the best you could imagine. Some other factors which are relevant for context-based decisions like fraud analysis information aren’t included. Data from physical access control systems isn’t used. There might be a much more granular authorization. Currently it is decided whether someone is allowed to access an application or not - there might be a deeper integration with the applications.

It is not yet the perfect solution for context-based authentication and authorization. But it is a step in the right direction, combining Citrix’ access strategy with additional tools. The solution proves, by the way, that many vendors might deliver solutions for context-based authentication and authorization for corporate users with a limited effort, providing a higher level of security and reducing IT risks to the customers.

I’m convinced that there will be several types of technical solutions for context-based authentication and authorization, targeting the online business, remote workers, and other requirements. There are several places to integrate with - Web Access Management tools, SSO tools, and Access Gateways. I expect more solutions to show up in the context-based authentication/authorization market within the next 12 to 18 months, even while some of the won’t be defined as “context-based” but as “risk-based”, “physiscal/logical convergence” or “location-aware”. But over time there will be a market segment for these context-based solutions where all the vendors will position themselves, with more flexible solutions and a tight integration of the requirement components.

That leads to the obvious conclusion: There should be a much more common service understanding. There should be one BSM approach on the upper layer. BSM, as real business service management, should really address the business aspects like

• Defining services from a business point of view - like “manage a contract” including storage, access rights,…
• Mapping these business services to IT services
• Manage these services from a business perspective, e.g. accounting, controlling (do we need these services really?),…

The next layer are IT services, e.g. the more technical services IT provides to deliver a business service. These services can be managed with ITIL principles and - at least to some degree - with today’s so called BSM tools.

Whether the mapping of IT services to the IT implementations of business processes is part of the IT service layer or the business service layer is a matter of definition. I tend to place the description of business process at the business service layer and the implementation of business processes in IT - and thus, the relationship of these processes with IT services - at the IT services layer.

Anyhow, there is a layer below for the different types of IT services. Today, BSM focuses mainly on IT infrastructure services and provides mainly an ITISM (IT Infrastructure Service Management) - and not an ITSM (IT Service Management) or a real BSM (Business Service Management).

Besides the IT Infrastructure Services we have IT Application Services. These services tend to be more granular, down to web services and so on.

But regardless of the service you talk about: Each service can be managed with the same principles - and ITIL (and ISO 20000) is a good point to start if you focus on the principles for managing services. You can define, implement, run, optimize any type of service. Whether you look on high level business services or on low level application services, the way you should handle services is, from a conceptual view, the same. The business aspects like service accounting and controlling can be applied as well on every level.

Given that, a unified view on services and their management would bring a lot of benefits to IT - the reuse of management software, improvements in that software when the experiences of infrastructure and software change management are combined and influence the tools, the capability for an overall auditing and accounting of services, a consistent authorization management for services, their management and their use.

But that would mean that the siloes at the vendor side (where software management is in most cases another division than infrastructure management) disappear as well as the siloes in today’s IT organizations are opened for more cooperation.

I’ve been talking with a lot of users within the last few weeks. And what I’ve learned has proven that statement. The most important driver for IAM projects today is the need for defined, auditable processes around user and authorization lifecycle management. And that is about Governance, Risk Management, and Compliance.

To fulfill these requirements, you need a strong IAM foundation. But without a level above for a business-controlled authorization management, for layered attestation from the system up to the business level, for the management of business roles and for a business-centric auditing that won’t fulfill the needs.

Given this it is no surprise that several vendors either integrate more and more of these features in their IAM products, some of them on a high level (Völcker), while others have acquired specialized vendors in both areas (Oracle, SAP, Sun).

Today it is not necessary to buy the IAM and the GRC products from the same vendor, especially because the GRC solutions are in their early stage. And due to the fact that IAM tools always will focus more on the IT level whilst GRC focuses on the business level I’m not sure whether they shall be really integrated. But one thing is sure: You will need both levels of tools to fully support the business requirements which are driving IAM today.

But there is one thing to be considered regarding SaaS – most of the SaaS offerings are more or less unmanageable. The interfaces for identity management, event management and logging and other necessary functionalities are missing. Defined APIs for controlling and integrating the SaaS applications into the existing own IT infrastructure are missing in most cases – or they are so weak that they aren’t useful.

Even more, it is virtually impossible to get the own data back in an useful format. SaaS vendors seem to consider that every information which someone stores in their SaaS application is their data – but it is the data of the SaaS customer. This is some form of aggressive lock-in.

How weak the APIs of SaaS providers are today is visible when you look at approaches like myOneLogin (which is very interesting) – only three of roundabout 60 supported SaaS applications support federation. And virtually none supports an efficient approach for provisioning users from your own directories to the SaaS application. Or have you ever asked your SaaS provider about SPML (Service Provisioning Markup Language) support? The answer probably has been something like “SPML what???”.

The missing support for standards or at least a comprehensive set of APIs for accessing, integrating and managing SaaS is, from my perspective, the biggest risk for SaaS. At some point of time the customers will ask for these features. The vendors which still believe that the world ends at their own perimeter and who claim that every data which someone enters into their SaaS application belongs to them will be shaken out of the market.  For good reason.

There are some reasons why IRM isn’t adopted widespread today. One is the complexity of the concepts. Without understanding PKIs and Public Key encryption it is impossible to really understand IRM. Another reason are the somewhat limited implementations. Most of them are fine for a limited set of applications and environments. Microsoft’s Windows Rights Management Services are great for Windows and Office. They even work in a B2B environment with some trust between the partners. But they are mainly for Microsoft apps. How about CAD and blueprints? How about the other office apps? And all the other types of documents, starting from XML documents, which are sent and stored? There are some other solutions, but most of them are either from pretty small vendors or very limited in scope.

But the most important reason is, in my opinion, that the relevance of Information Rights Management isn’t fully understood. Even when I talk with IAM responsible, IRM seems to be amongst the best hidden secrets. But access control which is limited to data in a silo like a file server or a document management system isn’t sufficient. Data is read and used by users, attached to mails, transferred via FTP – the perfect way to bypass most security concepts [I had a very interesting conversation with Taher Elgamal from Tumbleweed some days ago – Taher has been responsible for “inventing” SSL at Netscape, and it is definitely worth to have a look at Tumbleweed’s approaches to minimize FTP risk] and so on.

But if you look on it the other way round, everything is fine. IRM works as well for data which is stored in silos. With other words: If you use IRM for any type of information there is no necessity anymore for the classical access control approaches. The best way to protect information is to do it directly at the level of the information – and not at the level of one of these many systems which might change, transport or store the information. Given that, it is really time for an industry-wide initiative for IRM standards which work on every platform and with every type of information and every application.

Within the Siemens IT Solutions and Services (SIS) there will be a unit “Identity Management and Biometrics” in which Siemens bundles its DirX and Biometrics activities.SIS will offer complete solutions including Smartcards, PKIs and security consulting around the products of this unit. Besides this the unit will work with VARs and plans to enlarge its set of partners beyond Siemens Enterprise Communications and some few other partners they currently have. There are also plans to extend the IAM portfolio through partnerships.

Even while we have to wait how well the new structure works, how successful SIS is in selling IAM projects up to a complete outsourcing and how the partner landscape around DirX will change – Siemens is now in an obviously much better position again. The new organizational structure is by far more logical than the placement in the healthcare department has ever been. We will observe how the new structure works in reality. But Siemens should be considered as a strong vendor again, even if you might haven’t done this for some time.

One of the things John mentioned was that Salesforce.com has allowed Google to be the authoritative source of identity assertion. In that relationship, Google is acting as identity provider. Besides the question whether Google is the best choice to trust on that leads to another question: There is no established identity provider in the so called “cloud” [By the way: Has the term "cloud" been chosen because everything out there is a bit "cloudy" in the sense of "fuzzy"?].

Yes, there are many. There are OpenID providers, there are some providers in the Infocard business, there are all these online providers and so on. But right now there is no trusted identity provider for the real online business, neither in the Identity 2.0 space nor in the area of business applications which are delivered as SaaS.

Covisint is probably the one which is closest to filling this gap, at least in some industries like automotive and healthcare. Their approach is to act as identity broker between suppliers and manufacturers or between different parties in the healthcare market.

Verisign is adressing this segment as well with their VIP strategy (Verisign Identity Protection), but from a technical perspective they have some way to go to support things like Infocards or SaaS authentication. [By the way: For sure, in the SaaS market there is as well the need that SaaS providers fully support federation and open up their apps for an easier external management.] Arcot Systems might become a player in that market as well, given their current business, the technology and the experiences they have.

But: Who will be *the* Identity Provider? It might be one of the companies I’ve mentioned. The online providers probably won’t fill the gap. It probably won’t be Google or some other big player - the trust problem there is the same like with Microsoft Passport some years ago. It might be Telcos or postal services for their regional markets. It might be the credit card organizations. Or it might be someone new in that market, who appears at some point of time, tells the best story and finds the grail. I personally believe that the leading trusted identity provider for business transactions might be sort of the next Amazon or Google - someone who becomes really big. Thus, it is time to start the quest for the grail. There are several players which might participate in that quest. Some have started, some think about it and some still don’t know that there will be a quest.

Let’s wait and see who is successful in that quest. Oh, you might argue that the idea of such a big identity provider is contradictory to the Identity 2.0 ideas. First of all, it is not contradictory to the needs of SaaS business. And with respect to Identity 2.0 - when it comes to transactions and not only interactions, you need someone to rely on. That might be some strong players, like in the credit card space. But it won’t be many because you won’t trust too many different parties for your transactions.

But: There is another layer of KRIs which has to be monitored. For example: How long does it take until an organizational change is known to the provisioning system? The provisioning process might be extremly fast - if it isn’t started, it is still far too slow.

Thus, I propose to define four layers of KRIs:

• Business KRIs
• Business-IT KRIs which measure the interaction of Business and IT
• High level IT KRIs like the orphaned accounts or the performance of provisioning processes
• System level IT KRIs for specific aspects of the single systems

That maps perfectly to my three layer view of Identity Management, with the GRC layer (Business to IT), the provisioning layer (High level IT), and the system level. KRIs on different levels can be combined for a complete view on risks. That is inevitable because, like mentioned above, there might be a low risk on one level but the overall risk might be still high.

In general, using KRIs is an interesting approach not only to know about risks but to measure and improve your organization - and not only IT.

The threat in personalization and profiling is to know what the person really wants (personalization) or is/has (profiling). The one who knows best is the person itself.

(Managed) infocards can transport virtually everything. They might provide profile information for personalization. A trusted identity provider might offer a service which stores profile information it retrieves from the users and provides it in a controlled way (the basic idea of user-centrism) to web sites which shall provide a personalized experience to the user.

Bring in things like U-prove and that site doesn’t need to know the exact data but can “ask” the Identity Provider about relevant aspects and retrieve a yes/no decision. For sure the service provider/relying party in that equation will know some things but the amount of this knowledge can be limited - and thus privacy can be maximized.

I’m convinced that there is a business model for Identity Providers. Users might pay for a trustworthy handling of privacy information. Relying parties might pay for the ability to personalize information. There might also be approaches where the service is for free but the privacy is limited - the relying party might pay more if she learns more about the user. Both approaches might work.

VRM fits perfectly into this. It is the use of these approaches for vendor relationships, providing information for buying decisions via Infocards. For me, VRM, infocards and technologies like U-Prove are the pieces of a puzzle which, when ready, shows personalization and profiling as the picture.

That seems to be pretty complex. How shall you ever manage file server ACLs from a central tool in an efficient manner? Or other tools? Yes, it isn’t that easy to solve. But bring in services and you’re much closer to a solution - not only for entitlement management, by the way.

Think about abstracting file server resources as services (which is, by the way, not that different from shares in the Windows world). Users will understand services - a service provides the ability to store and retrieve their contracts or their personal files or their blueprints or their drafts of new marketing materials or… A service is simple to manage from a security standpoint: No access, read, write, do everything - or something like that are the relevant rights.

Services are easy to handle in accounting. Their might be restrictions like quotas applied on the service level. And managing entitlements on that level is not that complex - that can be mapped to concepts in the Enterprise Authorization Management pretty easy.

You might argue that the file system still has to be locked down. No problem - as long as you can access it only through services. There might be different overlapping services for the same resources. Administrative shares in Windows are one example for that. If that isn’t sufficient, you can still use ACLs - and the services might act as specific operating-system services which bypass that security level or (like today in Windows) combine their security settings with the operating-system level settings. The latter is pretty complicated and somewhat overengineered. From my perspective, a consequent service approach might be sufficient.

To add some web services for file system access might be helpful - but it isn’t mandatory. A service is not necessarily a web service. In fact, everything you need for such an approach is available. Some things might be improved. But with a service-focus for file server services, security is easier to manage and to audit.

Yes, if you handle every trust separately. No, if there is sort of a trust broker for at least most of the web services which provides a standard trust with no specific configuration per web service. In that case even that concept might work - and federation-enabling web services could be done by the application these services run on.

But it can be done easier, in the context of Web Service Security applications or other approaches. My position is that a web service has to run in the context of the user’s identity. Usually the context will be derived, e.g. a role, a group or something else. A layer like the Web Service Security should be able to work with such a context, which might be provided within a SAML token. But, in general, it might be any type of claim - Kim Cameron’s concept of claim-based security fits in pretty well here.

In fact, the issue can be solved very easy: Take the information in a claim or assertion, transform it to a parameter and invoke the web service based with this parameter. Then the web service can return exactly the information which is relevant (or allowed to see) to the identity the parameter has been derived from. The application infrastructure has just to work as a special type of STS (Security Token Service) which transforms security tokens into parameters for web services.

With this approach, it is as well possible to completely implement the idea of claims into SOA security. The accounting of web services works as well, because the platform from which web services are invoked knows about the identity (or something derived from), because it knows the claim or assertion. And the web service itself can be fully identity- and federation-ignorant.

In fact, there is no reason not to implement a real end-to-end security, either with Federation and an efficient trust handling or with a claims-/assertion-/parameter-based approach like described.

What do I mean by that term? My idea is about applying the ideas of Identity 2.0 and especially of InfoCard to the business. Provide every employee with an InfoCard or even some of them and you are better suited to solve many of today’s open issues.

How to issue these cards

I have this in mind for a pretty long time. I remember that I had asked Don Schmidt from Microsoft about the interface between Active Directory and CardSpace some time before EIC 2007. Active Directory might be one source of these cards. Just provide an interface between AD and an Identity Provider for InfoCards and you are able to issue and manage these cards based on information which still exits in the Active Directory. For sure, any other corporate directory or meta directory might work as well.

Today these technical interfaces are still missing, at least in an easy-to-use implementations. But it won’t take that long until we will see them. Thus, it is time to start thinking about the use cases.

How to use these cards

There are at least three types of cards I have in mind:

• Virtual business cards: They are used when someone represents his company. How do you ensure today that every employee provides current and correct information when he registers with other web sites? How do you ensure that he acts in the web like you expect him to do? How do you ensure that he enters the correct title or the correct information about the size of your business when registering? InfoCards are the counterpart to your paper-based business cards today, but they can contain more information. And there might be different ones for different purposes.
• Virtual corporate cards: They are used for B2B transactions and interactions. Add information like business roles to the cards and you can provide all these claims or assertions which are required for B2B business. These cards can be an important element in Federation, providing current information on the role of an employee or other data required. For sure there can be as well several cards, depending on the details which are required for interaction with different types of business partners.
• Virtual employee cards: They are used internally, for example to identify users in business processes. Again, there might be a lot of information on them, like current business roles. You might use them as well to improve internal order processes, identifying the users who request new PCs, paper, or what ever else.

With these three types I might even have to extend the name for the cards, I assume. But I will stick with the term I have in the title of this post. The interesting aspect is the flexibility which (managed) InfoCards provide and the ability to manage them in context with a leading directory you have.

Due to the fact that you are the Identity Provider when applying these concepts you can ensure that no one uses these cards after leaving the company. You can ensure as well that the data is always up-to-date. That’s by far easier than with some of today’s equivalents for these future type of cards.

I will blog these days about two other ideas I have in mind in this context: The way the concept of claims Microsoft’s Kim Cameron is evangelizing will affect end-to-end security in business processes and SOA applications in general and the idea of using InfoCards for all these personalization and profiling ideas which have been discussed many years ago. I’m convinced that Identity 2.0 concepts like InfoCards and claims are a key element to solve these threats and bring these things to live.

There is a lot of business value in these concepts. And they will affect the way businesses cooperate, because they are much easier to implement and use than many other approaches.

The GRC market, on the other hand, appears today as a very fragmented market, with a broad range of solutions and tools. Without telling on everything my upcoming report on the structuring of the GRC market will include, there are at least two levels of distinction between the offerings in the market. The first is around the general level, where you find methodologies, pre-defined solutions (for example rule sets for specific applications and compliance regulations which can’t be applied easily to other threats) and tools.

Within the tools, there appear, amongst others, the vendors of role management solutions. I personally define five core functionalities for GRC tools:

• Analysis of entitlements and Reporting
• Attestation - should, by the way, be multi-layered
• Authorization Management, including SoDs (Segregation of Duties) and, in general a policy/rule definition and enforcement for entitlements 
• Risk Management, including Risk Modeling and Analytics
• Role Management

Within these functionalities, the management of roles is the centre, because the other features rely on this. Workflow features - best solved with the choice between internal and external workflows - are mandatory.

Currently there is no vendor who provides the entire big picture on a high level. But it is obvious that many vendors are working on this picture and are delivering more and more parts of the puzzle.

By the way - based on these tools there probably will be a solution market again which provides pre-defined implementations for specific industries or regulations.

This view gives as well an answer to the question whether GRC shall be limited to IAM. No, it is a broader market. IAM delivers to GRC solutions. But GRC is sort of a bracket across the entire IT infrastructure, building a bridge between IT and business. Thus GRC is going well beyond IAM, even while many of today’s IAM solutions can (help to) solve GRC threats and even while there won’t be a successful enterprise GRC implementation without a strong IAM foundation.

• The products
• The market development

Regarding the products, it is important to understand that there are other expectations in many European countries than in the US market. Germans tend to look for the perfect solution, very sophisticated and really fulfilling all their needs, while the Americans seem to accept more point solutions which help to solve an existing problem at least at the 80:20 level.

That doesn’t necessarily mean that you need other products for Europe. But US vendors shouldn’t raise expectations to high but be realistic and focus on the business values and quick wins there customers can really achieve. Even while this works in many situations there are market segments with very specific European approaches. Role management, for example, tends to be implemented in Europe with a much stronger methodological approach than in the US - and that is reflected in the products.

On the other hand, the strong adoption of products from US vendors in the IAM market proves that the different expectations, requirements and methodological approaches are no insuperable hurdle for success in the European market.

In general I believe that the way a vendor develops the European market and acts in it is the key success factor - and it is where many vendors fail. First of all: There is no success without investment.

There are two approaches to address the market which can (and, in the mid-term, should be combined): Through building an own structure in Europe or through local system integrators. I recommend to start with a small office which mainly focuses on business development in building partnerships with system integrators and really supporting them.

That allows to work with very few offices over Europe - and to deal with the fact that there is not one Europe but there are at least several regions which have to be addressed separately. There is the northern region, e.g. Scandinavia, there is UK and Ireland, there is the D-A-CH region (Germany, Austria, Switzerland), there is southern Europe, there is eastern Europe, there is France, there are the Benelux countries (Belgium, Netherlands, Luxembourg). Some might be addressed from one office. But it usually isn’t sufficient to rely only on one office in UK. The business development has to act more local.

Another hurdle is the best practice. Hundreds of customers in the US are not as valuable as one customer in Europe. That is a consequence of the different expectations customers have in the US and in Europe.

Another important aspect is customer support. The partnership with system integrators acting as first level of support solves many of the support issues. But there has to be as well the willingness to accept feature requests from Europe and to address them quickly as to have some technical experts travel to Europe to directly work with the customers in the more complex situations.

To build successful relationships with system integrators, the US vendors have to spend money to educate the system integrators as well as to support the system integrators in promoting their solutions. That should be very focused budgets for specific events, but without investing there won’t be any success. Interesting business models where system integrators really can earn money by selling licenses might help as well.

And, last but not least, the US vendor has to become visible. That includes press relations (again, specific for any country) as well as presence on the main events around IAM in Europe. If the vendor isn’t represented at these events the customer will doubt that the vendor is really a reliable partner in Europe. Besides this, these events are a good place to build up partnerships with system integrators.

All these initiatives will require some investment - and given the strong Euro these are even more costly for US vendors. On the other hand there are so many customers in Europe, especially in the mid-sized business, without IAM solutions that there is a good chance for a quick return on investment, given that the market entry and business development in Europe is done the right way.