Security, Identity, and Business Drivers at EIC 2010

Earlier this month I attended the European Identity Conference in Munich. The conference is put together by Kuppinger Cole + Partner and they do a great job. As I’ve posted before each year it gets better, and this year was no exception.  This year there were great sessions with cutting edge content, really good food and beer, and vibrant interaction between vendors and customers. It all added up to a very productive week. Oh, and there was really good beer.

Last year, Martin Kuppinger and I led a workshop on cloud computing, and we did it again this year much more in depth – but that’s another post. This year, there was a whole content track devoted to the cloud. As I see it, cloud computing has evolved to become just “the cloud” and is a set of technologies and business models which have the requisite force to drive adoption of identity-based security.  So combining an identity conference with a cloud conference is a Very Good Idea.

I gave a keynote in the Cloud 2010 track. KCP were kind enough to post the video of the session . You can also download the presentation. One advantage of my occasionally-derided “Wall of Words” presentation style is that you can easily get the main points by scanning through the presentation. I took all the photos in the presentation in Munich a few days before the session, which made it more relevant and fun for me.

The concepts in the presentation have emerged in the last year while working on Novell’s Cloud Security Service . Supporting insights and statistics came from a survey initiated by our own Anita Moorthy. Basically the presentation covers how business drivers affect the security needs of enterprises, SaaS vendors and cloud providers.

Here’s a brief overview.

A survey of some current market forces and players:

  • We have seen many times how a disruptive force in information systems is departmental autonomy pulling in products and services under the enterprise IT radar. This is again a significant factor in the adoption of SaaS applications.
  • The adoption of SaaS applications is accelerating a shift by traditional hosting companies and telcos to IaaS and PaaS models, and they are increasingly moving to attract SaaS vendors in addition to enterprises.

The business and security interactions in the cloud involve enterprises, SaaS vendors, and cloud providers – each with different motivations. From this current cloudscape, I identified 3 trends and possible traps in each:

  • Identity-based security is increasing in importance. Cloud services are pushing enterprises to emphasize identity based security rather than network security
  • SaaS and IaaS are converging on PaaS. Infrastructure providers are moving up stack and applications need to be extensible… converging on platform services, including identity services.
  • Cloud providers are increasingly offering identity services – and becoming identity providers. Identity services provide much needed security, and stickiness. Application marketplaces are a powerful paradigm growing around identity provider hubs.

We concluded with some recommendations for enterprises, SaaS vendors and cloud providers.

For years, we have been working on standardizing, implementing, and deploying the identity provider model – which separates the sources of authentication and identity information from services that use identity information. It is clearly a better model for humans than separate accounts in every service. However, as Jeff Bohren succinctly said, “Change is hard. Passwords are easy.” More than ever I see trends in cloud computing that are finally providing the business model and incentives for enterprises, SaaS vendors, and cloud providers to move to the identity provider model. EIC 2010 further accelerated those trends.

I very much enjoyed the conference, working with the KCP team, and the interaction with customers, competitors and partners.

As always, I’d appreciate any feedback on the presentation, offers of presentation rewriting, coaching on public speaking, etc.

Cloud Computing Precipitates Identity-based Security

edge_of_cloudsNot for the first time, I have found a post by Gunnar Peterson to be very useful and insightful. This time, I followed his lead to a post by Chris Hoff.  It’s a piece called “Cloud Providers and Security ‘Edge’ Services – Where’s The Beef?“. I highly recommend the whole of both posts. Mr Hoff’s post is a discussion of what it might mean to integrate security services to the edge of the cloud, and his questioning about what the edge of the cloud could mean. The common answer is that it is securing from services in the cloud to the edge of an enterprise, location, or … something. Something inside a boundary that can be surrounded by some model of security that happens at the network level. Which leads to this statement:

None of the models are especially friendly to integrating network-based controls not otherwise supplied by the provider due to what should be pretty obvious reasons — the network is abstracted.

Chris Hoff, Gunnar and others have been decrying for years that network level security is insufficient. Sometimes the recognition that network level security is insufficient (and often counter productive) has pushed people to make a goal of ‘deperimeterization’, which is a cool word but certainly has not helped move the industry from it’s predilection for network level security. It is much more likely that the term that will finally precipitate a movement from network level security to identity-based security will be “Cloud Computing”.

In Mr Hoff’s post he emphasizes this point:

So here’s the rub, if MSSP’s/ISP’s/ASP’s-cum-Cloud operators want to woo mature enterprise customers to use their services, they are leaving money on the table and not fulfilling customer needs by failing to roll out complimentary security capabilities which lessen the compliance and security burdens of their prospective customers.

Gunnar’s commentary on Mr Hoff’s post makes some equally insightful points:

For access control purposes, security is fairly straightforward, its a game of subjects (like users, user agents, claims, and web services), objects (like resources, URIs, data, and service providers) and what Hoff calls metastructures (like identity and policy). Security is a word that is meaningless by itself, you always have to qualify it: data security, application security, network security and so on. So when people talk about “edge” security, what is it they propose to “secure” an edge device? That’s fine as far as it goes, but its important to note that providing security services to device on the edge doesn’t do much of anything to either side of the edge. Too often people assume that securing the edge means everything “inside” the edge is also “secure” but this is smoke and mirrors for auditors not security for your enterprise assets.

I think of that type of security (with subjects and objects) as identity-based security. An identity is what you apply policy to — it is the subject or object of an access control policy. It’s the base type of the concepts of subjects and objects. The metastractures are processes of authentication and authorization based on those identities. It’s much higher level than SSL and the network layer, but it’s much closer to what’s necessary for business processes and security needs in the cloud.

Gunnar concludes:

Whenever you evaluate security and especially Cloud security, its important to enumerate the subjects, objects and metastructures that you are extending security services to, instead of just describing some security service in the abstract. This problem is a pandemic in information security the whole point of SOAP is that it was a firewall friendly protocol designed to go through the firewall, that was 10 years ago, yet today information security still relies on SSL and network firewalls as primary protection mechanisms (what are they protecting?).

Indeed, what are they protecting? While network level security can enable a secure transmission of data from point A to point B, it does not prevent the vast leakages of passwords and personal information that have become common. Perhaps the growth of Cloud Computing will finally push the industry to systems in which users don’t have passwords, or at least systems which can securely serve their users without receiving their password or storing personal information. If a SaaS application doesn’t have the information, there’s one less place that it needs to be secured. Such identity services have been viable for some time, but have needed a push to get broader adoption. Cloud Computing.

We appear to be on the edge of a nervous breakthrough.

EIC 2009, and a New Focus on Identity in the Cloud

EIC 2009 at NightFrom May 5th to May 8th I attended the 3rd European Identity Conference (EIC). As a testimonial on the front page says, it was “a wonderful and informative event, well run and useful in so many ways.” (If I quote a page quoting me, is that recursion or delegation?)

I attended the first two EICs and, while I greatly enjoyed them, each conference has been better than the last. EIC strikes a good balance between providing a forward looking vision of what identity management technology should provide for business, and what practical solutions are available now.

In previous years I have noticed great contention about what identity system had the best design, had the correct name, was the most open, was favored by which group, etc. I asked other vendors why there seemed to be much less of that contention this year. All of them answered that there is not much to debate; there are valid use cases for the classic federation protocols, as well as OpenID, OAuth, and information cards — and all are open standards. So we’ve all been implementing products that use these protocols. However, as the products are deployed most system designers also recognize that we are far from done. What we have available now in open standards are valid systems that are a leaps forward, but are still not sufficient – there is still more to be done to make the systems more intuitive, more usable, more functional.

I presented my thoughts on these issues in an early OASIS session. The presentation was “Gaps and Overlaps in Identity Management Solutions”. The gist of the talk was that we don’t need to dumb down identity systems for people; we need to provide more intuitive, nuanced and contextual systems so that people can express the richness of relationships online. I illustrated this point with a stereotypical Granny who commonly handles delicate interactions with complex forms of indirect speech as she navigates many kinds of relationships in real life. We have too long focused on trying to make her use a single user name and password, rather than than allowing her to manage relationships. Our users do not need us to dumb down online identity systems – they need us to allow them to intuitively handle the richness of relationships. Online systems need to perform transactions within various contexts, unequal power levels, third party sources, etc. To bring the point home – so to speak – the presentation featured photos of my mom as the stereotypical Granny.

The tireless Felix saw the presentation and posted an interview with me about it.

Over the next few days there were many presentations and lively panel discussions, including the one led by Dave Kearns and discussed in his newsletter. I greatly enjoyed participating in 3 panels and moderated a 4th. One thing I really like that seems to happen frequently at EIC is that the audience participation with a panel can get quite animated and extend into the expo area after the session.

The expo also was expanded this year. What I particularly liked about Novell’s booth was that it highlighted customers and their innovative use of Novell products – it seemed much more interesting and less like a sales pitch. As always, it was good to get to meet my Novell colleagues there: Marina Walser, Ulrike Beringer, Klaus Hild, AleÅ¡ Kučera, et al. Marina gave a great keynote (which was much discussed over the next few days, especially the customer survey results) and also recorded an interview with the ubiquitous Tim Cole.

With Marina and Ulrike, I participated in some press interviews. Being a typical unilingual American, I can’t actually read some of the resulting articles. Nevertheless, they appear to be quite interesting based on the (sometimes humorous) automatic translations.

It was a very busy week. I sometimes could only listen to part of a session before going to another commitment. One of my favorite (unfortunately partial) sessions was “Access Control in the Cloud” by André Koot. Rather than theory of identity systems or analysis of protocol families, André focused on using claims and information cards as a basis for flexible and manageable access control from an enterprise or university to cloud based services.

There were many other great discussions and presentations by visionaries and curmudgeons. Apparently attending a conference in Europe is the only way to see Jackson Shaw these days – well worth the effort.

The final EIC highlight was particularly significant to me because it involved my new area of focus – identity and security services for Cloud Computing. On the last afternoon I led a workshop about Enterprise Identity in the Cloud. It had been a long and intense conference, so we expected light attendance and decided to keep it as just an open discussion. The best part about this was that we had a small, but tightly focused conversation with customers, systems architects, and representatives of a few vendors. It was particularly great to have Martin Kuppinger join us to share his deep insights into cloud computing, and provide some adult supervision.

Overall, I noticed three themes at EIC this year:

  1. Open standards-based multi-domain identity systems are shipping in real products from many vendors, and solving real problems.
  2. There is more to do to make identity systems rich enough for online relationship management.
  3. Cloud computing is an important concept, a valid trend, and it provides strong use cases for multi-domain identity systems.

I am left with one question: did the beer taste so good because I was in Germany, or was it just the beer?

Now that’s funny

I know people have widely varying humor styles and many may not agree with me, but, man, I find this XKCD comic to be very funny. I just keep chuckling to myself. Oh, and don’t miss the text that pops up if you mouse over the panels — if you read XKCD in a feed reader, it’s worth a trip to the site to see the mouse-over text.

First Identity Selector in a Linux Distribution: DigitalMe in OpenSUSE 11.1

As my last post shows, I’ve been thinking a lot lately about the evolution of identity services over time. I’m currently researching and thinking about how identity services should integrate with the emerging cloud computing paradigm. However, sometimes we get working in the daily grind, the months and years go by, and we can miss significant milestones, like this one:

geekoWhen OpenSUSE 11.1 was released on December 18th 2008, it included the DigitalMe identity selector in the main repository.

I guess it could be said that OpenSUSE 11.0 was the first Linux distribution to support an identity selector, but it wasn’t in the main repository when 11.0 was released, so I’m going with OpenSUSE 11.1.

digitalme logoWhat this means is that users of OpenSUSE 11.1 can install and run DigitalMe as easily as Firefox or Open Office or any other package. Just open up the package manager, search for digitalme and install. There are actually two packages that start with digitalme. One is the identity selector itself and the other is the Firefox addon. If you install the digitalme-firefox package, the selector is installed automatically. And you are automatically notified of updates!

Thanks to Andrew Hodgkinson for making DigitalMe happen, and getting it packaged for OpenSUSE!

(Andy, I think you may be due to update your blog. Your regular rate of one post every 1.5 years appears to have slowed.)

As always, thanks to the Higgins project for hosting most of the source code used to build digitalme, and for their support and collaboration.

Identity Services: Being vs Doing

Eric and Dave have recently written about their views of the waves of identity. Dave’s post gave me a wave of nostalgia since it mentioned both the NetWare Bindery and Novell Directory Services. Sometimes it feels like I’ve been around as long as Dave.

Mr Peabody, set the Wayback Machine for somewhere near 1990…

My first server-side coding assignment at Novell was to show that the Bindery could be separated from the core NetWare OS and into a loadable module (NLM) — thus showing that a directory services NLM could be developed by another team of engineers in parallel with the next version of NetWare. I think my prototype was initially done on the NetWare 3.0 codebase, but it was a long time ago. I do remember that, after my prototype worked, the task of doing it “for real” was assigned to a member of the core OS team, and they threw out my code. Sigh. Nevertheless, what became known as the “name services” interface in NetWare 3.1 enabled a team of misfits to start coding something called Global Directory Services. By the time it shipped it was called NetWare Directory Services, then Novell Directory Services, then eDirectory. I worked on that code for most of the 90s as it changed to support new upstart protocols like LDAP, and new platforms like Windows NT and Linux.

Now I work on Identity Services, including newfangled concepts like federation, information cards, OpenID, and OAuth, and projects like Bandit, Higgins, OSIS, etc.

I think I can see both Eric’s and Dave’s perspectives.

I don’t know how or if the waves should be divided up, but it seems to me that in the 90s we were working on Directory Services — i.e. a standard model for identity data (generally around x.500) and systems to access that identity data (LDAP, meta/virtual/directories). This roughly corresponds to Dave’s first 3 waves.  With the appearance of federation protocols and the Liberty Alliance, the industry started layering an Identity Provider Model on top of Directory Services. Information Cards and OpenID are more recent additions to that model.  This could be Eric’s first wave of Identity after 3 waves of Directory Services.

But what really matters to me is Eric’s point about identity state vs identity action. Right on. It  may be useful to make a distinction between Directory Services (which allow applications to access identity data), and Identity Services (which perform identity actions). The Identity Provider Model was necessary to get to identity services, if for no other reason than that it externalized authentication — but that’s a post for another day.

To do is to be – Nietzsche
To be is to do – Sartre
Do be do be do – Sinatra

The Bandit project has built an identity services interface layer called OTIS (Onramp to Identity Services). We have been asked how it differs from a virtual directory, and the answer is exactly relevant to this discussion. OTIS provides open interfaces to identity services (actions). A virtual directory gives access to identity data. Both have valid uses, and, in fact, identity services are generally layered on directory services (identity actions based on identity data).

So we have moved from Directory Services, to an Identity Provider Model. Now we need to determine what identity services are needed to enable network services to focus on doing useful things, rather than handling identity data, regardless of whether it’s wave 2 or 5.

Information Card breakthrough with Novell Access Manager 3.1

There have been a number of articles in the press over past few weeks about the release of Novell’s Access Manager 3.1. The articles by John Fontana at NetworkWorld and by Sean Michael Kerner at InternetNews.com are well worth reading. Both articles mention new features in the product, it’s interoperability with Microsoft products via open standards, and (my favorite) how code from the Bandit project relates to the product.

Yesterday, Dave Kearns posted his comments about Novell Access Manager 3.1 from his popular newsletter. Some excerpts:

The real breakthrough for me, at least in terms of Microsoft services, was Novell’s inclusion of Windows CardSpace as an authentication type for its multifactor authentication. Novell, through its sponsorship of the Bandit Project, has been in the forefront of information card technology, and this release of Access Manager makes it easy for identity technology managers to add this factor to their risk-based authentication schemes.

This may well be the first CardSpace implementation in a business-focused product by a non-Microsoft vendor. Now that is “ground breaking”.

A solid enterprise product, supported by a leading IAM vendor, and implementing open standards in conjunction with open source implementations — this does seem to me to be another significant step in moving to new-paradigm identity systems.

What are the next steps for 2009?

Gunnar’s Foresight on Google’s Security Hole

Gunnar Peterson is as prolific as he is knowledgeable. It seems like an old post now, due to his steady stream of great content, but a few weeks ago he made some prescient comments about the problems that come from custom security software. The post is humorous as well as insightful and explains why not enough IT budget is spent on software security.

Golfball

He makes a strong point that other security areas such as network security get the bulk of the IT budget, but that not enough is spent on ensuring software security. It’s just not taken seriously. Hence the name of the post, “Golf Driven Security”, referring to his estimation that the IT decision makers play golf with their network security product sales rep — and sign up for their renewals while determining that internal folks can roll their own software security.

Rolling your own custom code in software security is dangerous business.

At the end of the post, he says this:

People don’t write their own virus protection, but for some reason attempt to do their own input validation, it is the same exact problem. People routinely write their own authentication, authorization and audit. I could go on.

Gunnar’s post was written on Aug 24. A Few weeks later ZDNet published an article describing a security vulnerability in Google’s implementation of the SAML 2.0 Browser-based SSO protocol. The Google coders had rolled their own software security.

Personally, I found the original paper about the flaw rather heavy on formalism, but I can see that it makes an important point: if we can formally define such protocols and their possible attacks, we can automate analyses to find flaws in the protocols.

On the other hand, the flaws actually found so far seem very basic. For example:

Any authentication mechanism should not be transitive. If I authenticate to service A, service A should not be able to authenticate to service B as me. Of course, any system that accepts usernames and passwords can often do exactly that, which is one reason username/password authentication sucks at service provider sites. If service A is evil, it should not be able to impersonate me. The Google implementation essentially assumed that all Google services and their partners were good. That seems to be a little beyond even the Google code of conduct.

Kim had a strong reaction to the emphasis of the reporting – pointing out the importance of partitioning (which Google’s implementation disabled) as a defense against insider attacks. Many identity bloggers commented and offered helpful suggestions to the Google coders.

It wasn’t a flaw in the SAML 2.0 protocol, it was in Google’s implementation. They rolled their own security code and, in this case, omitted some important aspects of the protocol.

I found all this interesting because I have been working on a project for the past few years that specifically aims to build reusable open source components that provide solid authentication, authorization, and auditing capabilities to network services. I agree with Gunnar that it’s surprising that people don’t seem to care much about software security. Our approach is that, if we make it easy enough to enable applications with such capabilities – if it’s easier for developers to use Bandit code than to roll their own, we can avoid many security holes. And, for my employer, sell more identity management products.

Perhaps our project motto should be:

Don’t roll your own Authentication, Authorization, and Audit code. Steal it from others. Be a Bandit.

Gunnar’s “Golf Driven Security” post concludes with this statement:

I have rarely seen an industry so ripe for disruptive innovation as software security.

Indeed.

The Bandit Live Demo of User-centric Identity in the Enterprise

rsa08 near mosconeThe OSIS working group of the Identity Commons is completing their third interop. In OSIS-speak, an interop is a set of features and a time period where many projects and vendors test with others’ components to ensure that user-centric identity systems actually work together. Interops have always been concluded with one or more public demonstrations of the progress. It’s been greatly expanded this time with many more participants and test cases. We had demos for 2 days at the RSA conference, and will be showing more at the European Identity Conference in Munich next week.One part of this interop that I think is most significant is that we have are testing some features that are particularly useful in enterprise identity management scenarios. In my sessions and in discussing the OSIS interop at RSA, I found that many people were not aware of some of these capabilities.

rsa08 speakers dinnerFor example, managed information cards can be issued in auditing or non-auditing mode. In auditing mode, the identity provider knows who the relying party is and can control if and what data is securely sent to the Relying Party. In non-auditing (or privacy) mode the identity provider does not know where the data is to be sent — and hence cannot audit or change what data is sent based on that knowledge.

The capabilities of auditing and non-auditing cards exactly fit with some enterprise use cases I have experienced. It’s almost like they were designed with those use cases in mind. In fact, I remember hearing Kim Cameron and Mike Jones describe these modes at the very first Internet Identity Workshop in 2005, for just such use cases. Now it’s great to see them implemented and working — and it’s very cool to see it first in 100% open source implementations.

To see how auditing information cards could be used in an enterprise scenario, the Bandit project put together a live demo for Brainshare. It’s still operational and we continue to use these sites for OSIS testing. Check out the demo overview, instructions and links for more detail.

The quick overview of sites and services:

More information about Bandit Employee Cards, and Bandit Member cards from the demo information page about the Bandit Cards IdP:

This is an instance of the Bandit Identity Provider. It is the repository of user account information, and (for purposes of this demo) represents a corporate identity source. It issues a number of types of information cards:

  • An Employee Card. This card could be used to access information that should only be used in corporate approved sites, therefore Employee cards are issued in auditing mode. All uses of the card (each time a token is retrieved) are audited and the destination site for the token is recorded. If the card is attempted to be used at an unapproved site, no token is issued.
  • A Member Card. This card is not used to access sensitive corporate identity data, it can be used to get member discounts at various sites. It essentially conveys a token which states that the bearer is an member.

Another site is the Bandit Blog. The intent is that only holders of Bandit Employee Cards should be able to post to the blog.

We also instantiated an identity provider service that is intended to represent a community site, The Identity Paparazzi. It issues non-auditing cards to it’s members. They like to post photos to a hypothetically contentious photo sharing site called “Identerati Exposé“.

Hence, in our twisted little hypothetical minds we could see some scenarios.

(Note: use “view image” to see more detail in the following diagrams, and the photos above)

auditing card usage

We should be able to guarantee that the Bandit Employee card could only be used at sites approved by the identity provider (Bandit Cards). The data would not be rejected by the rogue Exposé site, so if the user attempts to present their Employee card at the Exposé site, the operation must rejected at the IdP/STS. However, a Bandit Employee card should allow the user to post to the Bandit blog site. All uses of the Employee card should be audited.

bandit non-audit card usage

A Bandit Employee, on their own time, should be able to be a card carrying member of the Identerati Paparazzi and post photos to Identerati Exposé. Identerati Paparazzi cards should allow the user to post photos to the Identerati Exposé site, but be rejected if used to post to the Bandit Blog site.

All of these demo systems are in place and have been working in many instances for months. When you actually start using the cards as described, it’s rather intuitive.

Try it out!

Anyone can be a Bandit Employee — just create an account in Bandit Cards and issue yourself an employee card (when getting a card there is a drop-down list of card types). Unfortunately, being a self-asserted Bandit employee does not mean you get paid. Likewise you can be an Identerati Paparazzi.

So feel free to try it yourself, but please be aware that is software under active development. Some things are bound not to work. For more information or help we have mailing lists, IRC channels, bug reporting systems.

Getting to practical user-centric identity systems

Earlier this year there were a number of interesting comments from Eric Norlin and Dave Kearns about the term “user-centric”. Since reading those comments I have become more aware of some ambiguous meanings ascribed to the term. I definitely agree that “user-centric” is unproductive as some sort of vague mantra — though I also believe that we should be aware of what values are enabled or enforced by the code we produce. What would be most useful now would be to focus on what user-centric identity systems actually do for users and companies.

brainshare light cloudsAlong those lines, at Novell’s Brainshare conference there was a panel discussion about “Open Source and User-centric Identity in the Enterprise”. The discussion was moderated by Carolyn Ford, and included Kim Cameron, Pamela Dingle, Patrick Harding, and myself. A video of the session is available (though there are technical difficulties and the guy on the far right looks like a complete dork).

Before we could discuss how user-centric identity systems may or may not be useful in the enterprise, we needed to get some idea of what we mean by “user-centric”. That was the opening question to the panel. Since audio is not clear in the recording, I thought I would write up some of what I may have said.

I see three possible ways that an identity system could be thought of as “user-centric”.

1. User as source of identity data

The user is the authoritative source of self-asserted identity data. Duh. This may sound circular, but it is helpful to contrast it with the next statement. Network services are not authoritative for self-asserted data — yet they currently often handle such data as if they were.

I have read articles where this meaning for user-centric identity is used to explain why it is of no value to the enterprise. The conclusion is that self-asserted data is of no value in enterprise systems. The implication sequence is: self-asserted => ability to lie => untrustworthy => low assurance => no business value. But this reasoning is overly simplistic. Users are authoritative for some information, e.g. their password, or their home address, or any information related to their intent as an employee within a business transaction.

Note that authoritative depends on the context. A self-asserted shipping address may be good enough for some network services and not others. Anything that a user puts in forms now is self-asserted data and currently accepted as authoritatve within that context. I hate forms and I want a system to help me with them.

So user-centric could mean helping users manage self-asserted identity data.

2. User as control point for release of identity data.

In this perspective, the user may not assert the identity data — but has a vested interest in where it is released. I may not determine my social security number, or my credit score, but I care to whom that information is given. In this view, identity data is more like a controlled substance and the user is an active participant in it’s distribution.

brainshare dark cloudsFor example, information card systems allow for assertions of identity data to be securely transmitted from an authoritative source to a network service in such a way that the user cannot tamper or see the data, yet is a control point for the release of the data.

Managed information cards can also be issued in auditing or non-auditing mode. In auditing mode, the identity provider knows where the identity data is to be sent and can control if and what data is securely sent. In non-auditing mode the identity provider does not know where the data is to be sent, which also has valid use cases. In either case, the identity provider is authoritative for the information, but the user in the center has a valid interest in controlling where the data is released as well.

So user-centric could mean helping users appropriately manage the dissemination of information about them.

3. User as center of their identity world

Yet another aspect is that user-centric could mean that only the user can corelate all of their accounts. In this view, user-centric is opposed to a central repositories for general identification of users. Only the user knows she is LacrosseMom to one service, acct 345678 in another service, and Sally in a third service.

So user-centric could mean the user is only point of linkage between some identity sources.

brainshare nightAll of these perspectives are useful, and they are all useful within the enterprise, outside of the enterprise, and especially when crossing such boundaries.

For me, I think the 1st and 3rd perspectives are important, but the 2nd perspective is the most interesting and significant for current system development.