Identities on multiple devices

As I said here, I want also to look at a second strange claim by Eve: 

On another issue, she noted that OpenID 1.0 has a vulnerability in that it leaves users’ identities open to possible correlation by unauthorized third-parties.

But that CardSpace has a vulnerability of an opposite but equally problematic nature. Given that each CardSpace is associated with a particular client device (i.e., a particular desktop, laptop, or mobile phone running Vista), and given the fact that each user might have multiple such devices, each with a multiplicity of cards running on them…that the more such devices, cardspaces, and i-cards multiply for a given user, the more difficult it will become for a particular user to correlate the various fragments of their identity across their own personal “space.”

This really strikes me as bizarre.  Maybe Eve was asleep while the entire world learned to copy mp3s onto their music players and carry them around?  Duh.  We know how to move files from device to device.  In fact there are probably many hundreds of millions of people who can do it better than either Eve or I can.

The idea that this is the big vulerability of CardSpace boggles my mind.  The whole criticism “Does not compute.”

Then again, I actually use Information Cards, and move them from device to device, so maybe that's why it's so clear to me how easy it is to do. 

Let me share the exact experience I have installing the Information Cards from my PC's CardSpace onto my mobile phone.

 Moving Information Cards from device to device

1)  I open up CardSpace and select Back Up Cards.  This will create a file containing my cards.  I decide to call it “cardset”.

2) I copy ‘cardset’ to my phone and click on it:

3) The phone asks for the password I used to protect my file

 

4) It verifies I'm importing the right cards

5)  And now I have the same cards on my phone device as on my PC.

How hard is that?  It would be the same process copying the file to some other device.  It works fine.  As easy as getting a word document or powerpoint or mp3 from one place to another.  Dongle anyone?  How about email?

Still, the uberpoint is this:  once Information Cards live on my phone, they go whereever I go. 

There are lots of ways phones can potentially talk to other devices.  So who says we have to copy our cards to all our devices once they live in a secure, personal device like a phone that we always have with us?

NOTE:  I want to point out that the mobile implementation of CardSpace I'm showing here is NOT a product.  It's a way of learning about the issues, and collaborating with colleagues in the world of telecom and secure portable devices.  But hey!  It's still a lot of fun.  More later.

Wrong-headed impersonation

James Kobielus's blog also includes a report on his interview with Eve Mahler.  I think there are two issues raised that deserve discussion.  The first concerns what Eve calls the “human absent” scenario:

“She focused on the centricity of the user in the data flow during a login attempt, distinguishing between the “human present” interaction mode (i.e., the actual human user/subject is online during the transaction, responding to prompts, selecting i-cards, deciding whether or not to disclose this or that personal attribute to this or that relying party), vs. the “human absent” interaction (i.e., the human user/subject is not actually online during the transaction on which they are a principal, but, instead, an identity software agent/intermediary or delegated other human user is selecting i-cards, disclosing attributes etc. on their behalf).

“She pointed out that most of the current crop of user-centric identity schemes (i.e, MSFT CardSpace, OpenID, etc.) focus primarily on the “human present” mode, which, as Eve stated memorably, means that the “user's policy is in their brain.” By contrast, she pointed out, Liberty's ID-WSF was developed to support both the “human present” and “human absent” modes.

The essence here is her notion that “an identity software agent/intermediary or delegated other human user is selecting i-cards, disclosing attributes etc. on [the user's] behalf”.

On behalf of…

I'm going to make a categorical statement.  No one and no service should ever act in a peron's identity or employ their credentials when they're not present.  Ever.

It's not that there aren't use cases for which this might seem to be desireable.  For example, let's look at the problem of linkback spam, in which fake sites fill bloggers’ comment queues with garbage.  Suppose, one day, we come up with authenticated linkbacks.  Wouldn't you want the linkback service to be able to log in with your identity?

Another example – given to me by someone who thought it was really definitive – was that of the OnStar notification system.  Suppose you're driving, are involved in an accident, and lose consciousness.  You want your OnStar system to call on your behalf so help will be dispatched.  Clearly you can't participate.  Similarly, hospital scenarios provide all kind of grist for the “human absent” mill.  But should OnStar or a hospital system actually be acting “as you”?

Last-century systems supported exactly this kind of behavior.  We called it “impersonation”.  And anyone who has done practical security work will tell you how many problems this caused, and how wrong-headed it is.  If you give some service the ability to simply appear to be you, you are open to all kinds of attacks – and we've seen them all around us.

Put another way, I don't want OnStar to be be able to act on my behalf with respect to very many things.  I don't want it to be able to remove money from my bank account.  I don't want it buying gifts, or controlling my insurance, or doing anything else other than calling for help.

So what I really want is for OnStar to identify itself as Onstar, and for Kim to identify himself as Kim.  Then Kim can give OnStar a Delegation Coupon allowing it to call for help on my behalf.  The coupon should be very restrictive.  And if the service does something improper, that impropriety will clearly be associated with the service's own identity, not with Kim.

There is no user-absent scenario 

In otherwords, there is no user-absent scenario.  There is a user is present and delegates authority scenario.  After all, how can a user delegate authority if she isn't present???

CardSpace is built on this principle.  A delegated authority coupon is just a set of claims.  CardSpace facilitates the exchange of any claims you want – including delegation claims.  So using CardSpace, someone can build a system allowing users to delegate authority to a service which can then operate – as itself – presenting delegation tokens whenever appropriate.

This is the right way to do things from a security point of view.  We need to move beyond the idea of omnipotent services running behind the curtain, which is what we have come up with in the past, to a truly secure model where the user consciously delegates and systems demonstrate this in an auditable fashion.

Surely it is obvious this is the best way to reduce everyone's exposure and liability.  The user has less exposure because she controls what she delegates.  The service has less exposure because it operates under specific and explicit permissioning, and insider attacks are significantly mitigated.

As much as I think Liberty represented a step forward when it first stepped up to the plate, it needs to embrace the user-centric model and replace the more monolithic “on behalf of” mechanisms with a proper approach to delegation under the control of the affected parties.

 

WordPress 2.1.1 dangerous, Upgrade to 2.1.2

Any product that is really successful is going to be attacked.  Over time the attacks will become progressively more sophisticated.  Given how popular – and how good – WordPress is, it doesn't surprise me that it has attracted enough attention that someone eventually broke through. 

Guess what?  I'm running 2.1.1 in my test environment.  Good thing I haven't flicked the switch.  Anyway, here's the scoop as explained by WordPress:

Long story short: If you downloaded WordPress 2.1.1 within the past 3-4 days, your files may include a security exploit that was added by a cracker, and you should upgrade all of your files to 2.1.2 immediately.

Longer explanation: This morning we received a note to our security mailing address about unusual and highly exploitable code in WordPress. The issue was investigated, and it appeared that the 2.1.1 download had been modified from its original code. We took the website down immediately to investigate what happened.

It was determined that a cracker had gained user-level access to one of the servers that powers wordpress.org, and had used that access to modify the download file. We have locked down that server for further forensics, but at this time it appears that the 2.1.1 download was the only thing touched by the attack. They modified two files in WP to include code that would allow for remote PHP execution.

This is the kind of thing you pray never happens, but it did and now we’re dealing with it as best we can. Although not all downloads of 2.1.1 were affected, we’re declaring the entire version dangerous and have released a new version 2.1.2 that includes minor updates and entirely verified files. We are also taking lots of measures to ensure something like this can’t happen again, not the least of which is minutely external verification of the download package so we’ll know immediately if something goes wrong for any reason.

Finally, we reset passwords for a number of users with SVN and other access, so you may need to reset your password on the forums before you can login again. (More here…)

Am I ever relieved that I'm using Project Pamela's InfoCard plugin in the new environment!  I haven't written about it yet, since I've been evaluating the beta.  But thanks to Project Pamela, I will just have to download 2.1.2, and change one line in one WordPress file to get InfoCard login working with it.  Let's drink a toast to proper factoring!  I'll be writing about this amazing plugin soon.

By the way, I have good news for the old-fashioned.  I'll be able to turn on username / password for comments again, since version 2.1.2 gets over the registration vulnerabilities in my current version. 

The whole episode brings up the interesting question of how to secure a widely distributed software project.  The more desirable you are as a target, the better the tools you need.  One day I hope to talk to the WordPress folks about incorporating InfoCards into their development process.

 

New book on Cybercrime

Speaking of new ways for a vendor to win my loyalty, here's an email I got today:

Dear Amazon.com Customer,

We've noticed that customers who have expressed interest in The Digital Person: Technology And Privacy In The Information Age by Daniel J. Solove have also ordered Cybercrime: Digital Cops in a Networked Environment (Ex Machina: Law, Technology, and Society) by J. M. Balkin. For this reason, you might like to know that J. M. Balkin's Cybercrime: Digital Cops in a Networked Environment (Ex Machina: Law, Technology, and Society) is now available. 

You can order your copy for just $22.00 by following the link below.

Cybercrime: Digital Cops in a Networked Environment (Ex Machina: Law, Technology, and Society)
  

J. M. Balkin

Price: $22.00

Book Description

  • “Cybercrime is written by the leading academic experts and government officials who team together to present a state-of-the-art vision for how to detect and prevent digital crime, creating the blueprint for how to police the dangerous back alleys of the global Internet.”

    — Peter P. Swire, C. William O'Neill Professor of Law, the Ohio State University, and former Chief Counselor for Privacy, U.S. Office of Management & Budget.)

  • “A timely and important collection of materials from highly qualified authors. Cybercrime will provide a wealth of new insights both for general readers and for those who study and teach about the legal and policy implications of the internet.”

    –David Johnson, Visiting … Read more)

I actually received this in my mail this morning.  I remember when I got my first email from Amazon, I started fuming.  My reaction was, “No!  This can't be! Not SPAM from Amazon!”.  It seemed incredible.

Then I read the message.  And guess what.  It wasn't SPAM.  Why?  By intersecting its knowledge of my interests with that of other people who share them, Amazon is able to make book suggestions that are just as cogent as most people I know.  This is what I call a relationship.  It isn't based on confinement or bombardment.  It's based on service.  The service is user-centric in a great way.

Now, moving down a level of abstraction, I think I'll buy the book.

Interesting summary by Kobielus

Despite the puns in his first paragraph, this piece by James Kobielus is very interesting, and sums up a lot of the conversations he has been having with people involved in the identity milieu:

“First off, I'd like to suggest that what we should be focusing on is not ‘user-centric identity’, per se, but ‘internet-scalable identity metasystems’ (a thought that Andre ping'd me on and Dick got me to take to hardt). What are the principles for making our identity metasystems truly internet-scalable? Could it be that user-centricity (however defined) is a necessary (but perhaps not sufficient) condition for internet-scalability?

“Now, let's look back to that previous post where I enumerated the main internet-scalability questions that Mr. Hardt laid out for our consideration:

  1. How do we scale up user-centric identity schemes, in which claims/attributes flow through and are forwarded by the user, so that they work on an open internet scale, not just within self-contained federations or circles of trust?
  2. How do we enable the free movement of claims from anywhere to anywhere?
  3. How do we extend lightweight identity management to the “long tail” of websites that don't and won't implement a heavyweight trust/federation model such as SAML or Liberty requires just to do chained/proxied authentication?
  4. How do we leverage the same core universal lightweight internet design patterns–i.e., REST using URIs and HTTP/HTTPS–to do internet-scale ubiquitous identity?

“Now I'm going to slightly shift the context for a moment to Kim Cameron's “laws of identity,” and then attempt to map that, plus Hardt's concerns, back to the notion of what it takes to make an identity metasystem truly internet-scalable. First, what I'll do is just republish Kim's actual written principles, but in a different order:

  • Consistent Experience Across Contexts: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
  • Pluralism of Operators and Technologies: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
  • Human Integration: The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.
  • User Control and Consent: Technical identity systems must only reveal information identifying a user with the user’s consent.
  • Minimal Disclosure for a Constrained Use: The solution which discloses the least amount of identifying information and best limits its use is the most stable long term solution.
  • Justifiable Parties: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
  • Directed Identity: A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

“Now, I'll reclassify/regroup/rewrite these principles into three higher-order principles:

  • Abstraction: An internet-scalable identity metasystem must provide all end- and intermediary entities (i.e., users, identity agents, IdPs, RP/SPs, identity brokers, etc.) with a consistent, abstract, standardized , lightweight, reliable, speedy, and secure experience/interface across all use cases, interactions, credentials, protocols, platforms, etc while enabling separation of identity contexts across myriad domains, operators, and technologies.
  • Heterogeneity: An internet-scalable identity metasystem must enable seamless, standards-based interoperability across diverse identity use cases, interactions, design patterns, credentials, protocols, IdPs, RP/SPs, platforms, etc.
  • Mutuality: An internet-scalable identity metasystem must ensure that all end- and intermediary-entities (i.e., human users, identity agents, IdPs, RP/SPs, identity brokers, etc.) can engage in mutually acceptable interactions, with mutual risk balancing, and ensure that their various policies are continually enforced in all interactions, including, from the human user’s point of view, such key personal policies/peeves as the need for unambiguous human-machine communication mechanisms, privacy protection, user control and consent, minimal disclosure for a constrained use, limitation of disclosures to necessary and justifiable parties, and so on and so forth.

“Now, how would conformance to these three wordy uber-principles contribute to internet-scalability? Well, abstraction is the face of the universal interoperability backplane of any ubiquitous infrastructure (be it REST, SOA, ESB, or what have you). And heterogeneity is the fabric of any hyper-decentralized, federated, multidomain interoperability environment. And mutuality (i.e., a balancing of rights, responsibilities, risks, restrictions, rewards, etc.) is essential for any endpoint (e..g, the end user, an RP/SP, etc.) to participate in this heterogeneous, abstract environment with any degree of confidence that they can fend for themselves and actually benefit from plugging in.

“User-centric identity got going as an industry concern when it became clear that federated identity environments are not always mutual, from the end user's point of view. In other words, under “traditional” federation, some “attribute authority” (not necessarily under your or my direct control) may be coughing up major pieces (attributes) of our identity to unseen RP/SPs (also not under our control) without consulting us on the matter. In other words, those RP/SPs can selectively deny us access to the resources (i.e., apps, data, etc.) we seek, but we often can't selectively deny them access to the resources (i.e., our identity attributes) that they seek. Doesn't seem like a balanced equation, does it?

“Now, tying all this back to Dick's key design criteria for the identity metasystem (in summary): open, free, lightweight, ubiquitous interaction patterns. Seems to scream for abstraction plus heterogeneity plus mutuality, which are necessary and, taken together, sufficient conditions for internet scalability.

“In other words, necessary for the identity metasystem to be universally feasible, flexible, interoperable, implementable, extensible, and acceptable.

I think James makes good points. 

Certainly one of the main things that will get us to the identity big bang is correcting the way earlier systems  “disappeared” the user.  You can see this in the enterprise domain-based systems, where the domain was all-powerful, and it was just assumed that a user was an artifact of one single administrative domain. We now realize we need more flexible constructs.

And you can see it in consumer systems as well.

Why did we all do this?  It depends on the context.  In the consumer space, I think, for example, it was assumed that customers would be loyal to the convenience of a “circle of trust” set up by portal operators and their suppliers.  There was nothing innately wrong about this, but it is just one scenario seen from one point of view. 

From the individual customer's point of view, the “circles of trust” should really have been called “circles of profit” between which they were supposed to choose.  As Doc Searls says, this isn't the only customer relationship which is possible!  Basically, we're talking very last-century stuff that didn't understand the restructuring impact of the web – and these ideas now have to grow into a much wider context.  This is a world of really deep relationships with customers, not of forced confinement.

So a big “correction” was in the cards, and the popularity of the “user-centric” view derives partly from this.  But there are other forces at play, too.  People can talk about “user agents operating on our behalf” as much as they want.  But who decides what “our behalf” really is?  We need as individuals to control those agents – delegate to them as James says – and keep them from getting “too big for their britches…” 

So my basic thesis is not that there shouldn't be agents and services operating on our behalf – or that I would support an architecture that made this impossible.  It is that all these services and agents must begin and end by being under the user's control, and we need a consistent technology to achieve that.

I totally buy the notion that a web site gets to decide who accesses it, and what the rules of engagement are for that to happen (“trust is local”).  So the user's control with respect to her interests do not diminish a service's control with respect to its interests.  Should we call this mutuality?  I think what we really have is a mutual veto – both the user and the site being visited can set whatever bar they want before they back out of the transaction.  To me, in a world of competition, this remains control.

 

Mixed signals?

Stephen Mcgibbon, senior director of Microsoft's European technology office, is in the midst of a lively identity discussion on the Danish blog Overskudsdanmark.  In a posting called, “What CardSpace enables, Vista prevents…“, Stephen quotes Stephan Engberg – who is on the international advisory board of Privacy International and other important organizations – as saying,

“I can easily see that Cardspace in itself COULD be a step in the positive direction, but MS is sending mixed signals by pushing the aggressive Live Id and “trusted” computing simultaneously with Cardspace.

“That might be ok if someone else had access to make usable solutions, but it is not my understanding that VISTA and Cardspace provide that access. What Cardspace enables, VISTA prevents.”

I guess there are several issues here.  I'll defer the discussion of how CardSpace provides openness until Stephan has had a chance to look around this blog – the “HelloWorld Card” series would probably help get a technology orientation.  Or just poke through the articles, or look at comments like this recent one from Dale Olds at Novell.  While that's happening, I'll try to get more up to speed on his criticisms of Live ID and Vista.

Perhaps I can move the discussion forward by sharing some high level information about the current Windows Live ID service.

It's quite a bit different, conceptually, than Passport was – even though it is a technical evolution of that system.  At core, Live ID sees itself as part of a very distributed and multi-centered world, whereas Passport was centralized and technologically monolithic.

You can get a sense for this by looking at the most recent Windows Live ID Whitepaper.  Let me pass on a few quotes which I hope will entice you to read more of the paper:

How Does Windows Live ID Participate in the Identity Metasystem and Work with “InfoCard”?

Microsoft is working with others in the industry to create an identity metasystem that brings existing and future identity providers into a connected identity ecosystem and empowers end users to control the use of their identities. The Windows Live ID service will participate in the identity metasystem as one identity provider among many, able to accept claims from other identity providers and transform them so they can be used within Microsoft online services. This participation will include acceptance of self-issued and managed “InfoCards.” It will thus provide full support for the “InfoCard” identity model.

Roles of the Windows Live ID Service in the Identity Metasystem

Microsoft has published its vision of a universal identity solution that is inclusive of a plurality of identity operators and technologies—the identity metasystem. In such a metasystem, identity providers, relying parties, and subjects can select, request, transfer, transform, and consume identities through a suite of well-defined and open Web Services (WS-*) protocols. Microsoft is working to implement components of the identity metasystem, as are many other companies in the industry. As a result, various building blocks for the metasystem are being developed. Some of these components will be delivered to end users in the form of software installed and running locally on their computers and devices, while others will be online services.

The design philosophy of the identity metasystem is not to replace the existing identity systems in use today, but instead to bring these existing systems together by enabling interoperation among subjects, relying parties, and identity providers through industry standard protocols. The Windows Live ID service will participate in the identity metasystem as a “managed” identity provider already at Internet scale. Windows Live ID will bring a large base of end users and relying parties to the metasystem, taking us one step closer to Internet-wide identity federation and doing our part to help the industry move beyond the “walled garden” paradigm.

The Windows Live ID service will play several essential roles that are strategic for Microsoft. The service:

  • Is an Internet-scale identity provider intended primarily for users of Microsoft online services, which are all relying parties of the Windows Live ID service.
  • Is open and issues claims in a form that can be consumed by any relying party, any device, and any other trusted identity authority.
  • Serves Microsoft online services as a “claims transformer,” allowing those services to accept identities issued by third-parties. Third-party identity providers include other Internet service providers and managed-identity providers, such as the planned Active Directory Security Token Service (STS).
  • Will be the identity provider and federating authority for third party services and software built on top of the Microsoft online services platform

In short, I see Windows Live ID as the identity component for the MSN properties, which speaks standard protocols, and is trying to be open and do business with the other parties who want to engage.  This is all a new model – not only for Microsoft, but for the industry as a whole.  There are many business details to be worked out, as there are elsewhere in the industry.  But I see a progressively deeper committment to putting privacy first, and think my Live ID colleagues deserve a lot of credit for that.  In fact, we have invited Stephan's Privacy International colleague Simon Davies to review and criticize our structures and initiatives, and have tried to act on his recommendations just as we would act on the recommendations of world-renouned security experts or other leading thinkers.

So I'm interested in the disconnect Stephan and I have in our perceptions.  Is it because Microsoft hasn't communicated broadly enough? Or is there something substantive here?  I would really like to understand. 

In terms of Stephan's comments about Vista being controlling in some way, I just don't understand at all.  It's the opposite of what we were trying to do.

Not everything about Vista is perfect, but we have been very hard core about putting our customers totally in control.  User-centriic is a big deal for me, and for everyone I know.  So are open interfaces and protocols.  I don't understand his objection to our “trusted computing” effort. 

So Stephan, let me know what you're thinking, and let's try to figure this out.

 

Identity Selector Permutations

Check out this interesting set of Identity Selector Permutations posted by Paul Madsen on his ConnectID blog.

In trying to make sense of the various combinations of OS, browser, plugins etc for enabling a client with a Cardspace compatible identity selector, I created the following graphic (click to enlarge…)

Caveat: It's almost certainly wrong in places, and doesn't account for Higgins.  

 

Update: Neil Macehiter adds some details.

  • Chuck's extension appears to require Firefox 2
  • XMLDAP requires Java 1.5
  • CardSpace on XP requires .NET Framework 3
  • #1 is the all Microsoft scenario
  • #2 ties Firefox into the Cardspace identity selector through the selector from Kevin Miller.
  • #3 ties Firefox into Cardspace through Kevin's plug-in, but allows for the scenario of a user choosing to use a different identity selector than Cardspace
  • #4 is Chuck Mortimer‘s Firefox plugin as an alternative identity selector to Cardspace.
  • #5 is a non-Cardspace identity selector for Safari.

 

Bandit and Higgins hit interop milestone

I was so snowed under trying to work against time for the OpenID annoucement at RSA that I missed blogging another imporant milestone that has been reached by the identity community.  This report on progress in the Higgins and Bandit side of the house is great news for everyone:

The Bandit and Eclipse Higgins Projects today announced the achievement of a key milestone in the development of open source identity services. Based on working code from the two projects and the larger community of open source developers, the teams have created a reference application that showcases open source identity services that are interoperable with Microsoft’s Windows* CardSpace* identity management system and enable Liberty Alliance-based identity federation via Novell® Access Manager. This reference application is a first-of-its-kind open source identity system that features interoperability with leading platforms and protocols. This ground-breaking work will be demonstrated at the upcoming RSA Conference in San Francisco.

“There are two basic requirements for translating the potential of recent identity infrastructure developments into real-world benefits for users: interoperability and a consistent means of developing identity-aware applications,” said Jamie Lewis, CEO and research chair of Burton Group. “First, vendors must deliver on their promise to enable interoperability between different identity systems serving different needs. Second, developers need a consistent means of creating applications that leverage identity while masking many of the underlying differences in those systems from the programmer. The Bandit and Eclipse Higgins interoperability demonstration shows progress on the path toward these goals. And the fact that they are open source software projects increases the potential that the identity infrastructure will emerge as a common, open system for the Internet.”

The Bandit and Higgins projects are developing open source identity services to help individuals and organizations by providing a consistent approach to managing digital identity information regardless of the underlying technology. This reference application leverages the information card metaphor that allows an individual to use different digital identity ‘I-Cards’ to gain access to online sites and services. This is the metaphor used in the Window’s CardSpace identity management system that ships with the Vista* operating system.

“Windows CardSpace is an implementation of Microsoft’s vision of an identity metasystem, which we have promoted as a model for identity interoperability,” said Kim Cameron, architect for identity and access at Microsoft. “It’s rewarding to see the Bandit and Higgins projects, as well as the larger open source community, embracing this concept and delivering on the promise of identity interoperability.”

The open source technology developed by Bandit and Higgins enables initial integration between a non-Liberty Alliance identity system and a Liberty Alliance-based federated identity system provided by Novell Access Manager. Specifically, these technologies enable Novell Access Manager to authenticate a user via a Microsoft infocard (CardSpace) and consume identity information from an external identity system. It will further show that identity information from Novell Access Manager can be used within an infocard system. This is a significant step forward in the integration of separate identity systems to deliver a seamless experience for the user as demonstrated by the reference application.

“The Liberty Alliance project fully supports the development of open source identity services that advance the deployment of Liberty-enabled federation and Web Services as part of the broader Internet identity layer,” said Brett McDowell, executive director of the Liberty Alliance. “The open source community’s embrace of Liberty Alliance protocols is validation of the benefits this technology provides, and we salute the Bandit and Higgins teams for their role in making the technology more broadly accessible.”

Higgins is an open source software project that is developing an extensible, platform-independent, identity protocol-independent software framework to support existing and new applications that give users more convenience, privacy and control over their identity information. The reference application leverages several parts of Higgins including an identity abstraction layer called the Identity Attribute Service (IdAS). To support a dynamic environment where sources of identity information may change, it is necessary to provide a common means to access identity and attribute information from across multiple identity repositories. The IdAS virtualizes identity sources and provides a unified view of identity information. Different identity stores or identity management systems can connect to the IdAS via “context providers” and thus provide interoperability among multiple systems.

“Many groups have been working towards the goals of Internet identity interoperability,” said Paul Trevithick, technology lead for the Higgins project. “This milestone represents a major step in having multiple open source projects work together to support multi-protocol interoperability.”

The Bandit project, sponsored by Novell, is focused on delivering a consistent approach to enterprise identity management challenges, including secure access and compliance reporting. The Bandit team’s contributions to the reference application include the development of multiple “context providers” that plug into the Higgins Identity Attribute Service (IdAS) abstraction layer to provide access to identity information across disparate identity stores. It also showcases the role engine and audit reporting capabilities in development by the Bandit community.

“The development of this reference application would not have been possible without the collaboration and contribution of the wider Internet identity community,” said Dale Olds, Bandit project lead and distinguished engineer for Novell. “This is the first of many milestones we are working towards as both the Bandit and Higgins communities strive to enable interoperable, open source identity services.”

So congratulations to Bandit, Higgins and everyone else who made this happen – this is great stuff, and the identity big bang is one step closer for it.

Understanding Bandit

There's so much going on around identity these days, that it's easy to lose track of how the different pieces fit together.  Here's a posting by Novell's Dale Olds that tells us all about Bandit.

There has been a huge flurry of activity in the Internet identity space in recent months mostly around convergence, working code, and actual deployments.

Since I am an unashamed Bandit, I am sometimes asked “where does the Bandit project fit in all this?” I think that it fits in three ways:

First, Bandit supports the above mentioned projects and convergence points.

We participate in the community as much as we can, and we are one of the few projects I have seen that will actively contribute code to other projects. We NEED this stuff to work coherently and we work to accelerate convergence where possible.

In some ways the Bandit project is much like our close ally, the Higgins Project. Both projects write open source code that glues together existing and future systems. Neither project pushes a particular protocol family or identity system. Higgins provides a framework that supports a common interface to multiple identity systems and protocol families. Bandit needs such a framework, so we contribute to Higgins to help it get done faster. We work with Higgins on other shared components as well.

We are also excited to work with the new Pamela Project. It fills a very important need for consistent relying party code that is usable, robust, and handles evolutionary accounts from existing silos to the emerging identity systems. Relying parties need consistent user experience too.

Most projects that we work with are open source. I personally would want my identity information handled by open source software. I also think that open source development is particularly good at interoperable components of distributed systems — like identity systems.

.
Second, Bandit adds a layer of open source components for consistent authentication, authorization and audit capabilities.

You might say that accelerating convergence, contributing code to other projects, and some authentication code is necessary before we can build effective authorization and audit components. We need a cohesive, distributed identity system. But we also know that when we get such a system, some critical issues involving authentication, authorization, and audit will surface.

Bandit focuses on simple, reusable components for authentication, authorization, and audit. These capabilities are most recognized as needed in enterprise identity systems, but I think they will be needed in other places as well. The recent experiences of the Bandit team and others are confirming this. Once applications or services (web based or otherwise) start to actually be used by more than a few users and sources of identity, they immediately find they need a general, scalable solution for authorization and audit.

Authorization means determining whether a particular user can perform an operation. Most network services really support authorization based on something like a role. For example, a wiki may have a notion of an administrator, an editor, and a reader. The Bandit Role Engine will allow a sysadmin great power and flexibility in how to map security tokens, claims, and other information into the native roles of the system.

Auditing is needed to provide an record of who did what. In the case of most of the emerging Internet identity systems we are particularly interested in providing a record for the user of what a service has agreed to do for them. Think of it (in the insight of Bob Blakley) as the receipt from a Relying Party. Audit records are also needed (like a cash register receipt log) to help a service prove compliance with various accounting regulations.

Bandit is not limited to these components or use cases, but they illustrate the point. From the main project page:

Bandit is a set of loosely-coupled components that provide consistent identity services for Authentication, Authorization, and Auditing.

Third, the Bandit Project is a conduit between developers and those who make these systems work in real deployments.

The Bandit Project works with Novell product teams, other vendors, current and future customers to determine what still needs to be done to make these identity systems work in real deployments. This will be an increasing emphasis of the Bandit Project this year.

 

Mozilla Links interview with Kevin Miller

Here is the Mozilla Links interview with Kevin Miller on his CardSpace selector, which will be included as an extension for Firefox 3. 

CardSpace, is Microsoft’s identity management system, a way of reducing the hassle of having as many identities (username/password credentials) as services we use and is already listed as a requirement for Firefox 3

Kevin Miller who has released Identity Selector, a Firefox extension that adds CardSpace support, tells us what his extension does and what identity management in general is about and what can users expect from this and other alternatives currently in development. For the record, Kevin notes he doesn’t work for Microsoft.

Mozilla Links: What exactly CardSpace is and how it works?
CardSpace is the method of implementing what Kim Cameron calls an Identity Metasystem. I would describe an Identity Metasystem as a protocol definition, or a pattern for secure identification on the internet trying to solve three problems:

  1. Phishing attacks
  2. Lack of trusted identity
  3. Proliferation of personal information

I don’t think we need to discuss phishing attacks. By now everyone should be familiar with them.

The second point, lack of trusted identity, is a bit more difficult. Web sites seeking to authenticate users have very few good options. They may require credit card numbers, which are verifiable. However, most users are reluctant to give their credit card numbers to just any site on the net. They may require a digital certificate, but these are difficult for the average user to maintain and verify.

For consistency with the documentation, I will refer to web sites as Relying Parties (RPs). I will refer to the users as users, although the Microsoft documentation calls them subjects. Please keep in mind that the users could be individuals, companies, or other computer systems. The RP need not be a web site. It could be a Windows client, a web service, or nearly anything.

The third point, proliferation of personal information, is a side-effect of the second point
first two items, and also contributes to identity theft. Because the RPs require users to register, they typically ask for a large amount of personal information, whether they need it or not. They may be selling this information, or they may be using it for marketing purposes. Or, they may just be collecting it because everyone else is and they think they might need it in the future. The problem for the users comes either from the sale of this information, or in the compromise of the servers (or laptops) on which this information is stored.

Now, the Identity Metasystem goes the distance on resolving all these issues.

  • Users now have easy-to-manage cards (InfoCards), instead of difficult to manage certificates.
  • The RP can ask for information relevant to the security level of the site.
  • For simple web sites, they may allow a self-generated card. This might be typical for many news sites where the company only asks users to register. Instead of typing the information into a form on the website, the user can self-generate a card and use it at multiple sites.
  • If the RP requires real authentication, they may accept cards from a number of valid Security Token Servers. These are third parties that host cards for users. The third parties must be trusted by both the user and the RP. This is similar to the concept of escrow. The user and the RP do not need to trust each other as long as they trust the third party.
  • The RP publishes the claims required for access.
  • The user decides what information to deliver. If the RP is asking for too much, the user can decline.
  • The user doesn’t have to fill out endless web forms.
  • The RP can customize the InfoCard request.
  • The user can customize the InfoCard response.
  • The RP can choose any available server implementation.
  • The user and site can agree on any Security Token Server.
  • The user can choose any Identity Selector.

All of these components can be provided or consumed in any language, browser,
or operating system, as long as they support the necessary components of the
Identity Metasystem.

This system directly answers points two and three, above, and indirectly reduces phishing attacks. It is also hoped that the trend will be for users to hand out less information, and the RP to ask for less. For example, consider two companies sharing information.

  • Company A has an information library that Company B wants access to.
  • Company B is willing to pay for the information, but doesn’t want to have to administer a list of user accounts. They also don’t really want to tell Company A the names of the employees accessing the data.
  • If Company A and Company B can agree on a common Security Token Server, Company B can simply provide valid InfoCards that indicate the user is an employee of Company B. The user can have access to Company A’s library without divulging any other information.

This is a bit of a contrived example. A real-world example may be a bar. The bar must make sure that you are of legal age to get in. The mechanism that most use now are driver’s licenses. In addition to your age, the license contains medical conditions, name, address, and description. Add to this the fact that some bars are now photographing licenses and storing the data. This means that now you are at risk of identity theft just to enjoy a night on the town. In an InfoCard world, you could simply provide an InfoCard validated by the government STS, and the bar would know that you are of legal age. No further information given or at risk.

Mozilla Links: How does CardSpace compares to OpenID, an open source identity management proposal?

There is only the most superficial comparison with OpenID. They both use third party sites to validate users. CardSpace, however, is all about authorizing and authenticating the user. OpenID provides only a unique ID (based on a URI). It does allow the third party to provide a variety of information, but does not provide the user an easy way to preview the information prior to each transaction. OpenID also relies on the honour of the implementers. There are no checks and balances to recover from a rogue provider.

CardSpace is designed to give both sides of a transaction (one or both of which may behave poorly given a chance) a way to verify the information requested and provided. Now, CardSpace won’t force an eBay seller to put your iPod in the mail, but at least you could get validation that you are dealing with a specific user.

Mozilla Links: What does your extension, Identity Selector, do?

My extension really does only a couple of things.

  • It parses the parameters representing the required and optional claims, and other key parameters.
  • It invokes CardSpace (or an alternative, such as Chuck Mortimer’s Identity Selector)
  • It passes the parameters from the web page back to CardSpace.

There’s a fair amount of validation, and some interfaces to allow developers to provide alternative implementations, but those three functions are the key pieces of the extension.

Mozilla Links: Why does Firefox need an extension to support CardSpace?

An extension is required in order to get the appropriate information from the browser and invoke CardSpace. Without the extension, Firefox has no mechanism to invoke CardSpace. We could theoretically generate some SAML code based on a web interface and hand that back to the relying party, but it would provide little benefit, at a large cost of effort.

CardSpace is hardened against attacks, provides a simple mechanism for choosing cards, and allows the user to verify the relying party. CardSpace also provides all the “plumbing” for handling and reading certificates, basic encryption, and writing SAML.

Mozilla Links: How much support does CardSpace have currently?

I’m not sure how many pages support this at the moment. The three I’m familiar with are the xmldap.org site, Kim Cameron’s sample page, and the official CardSpace sandbox (which, unfortunately, only supports IE 7. I’ve talked to some folks about sorting that out).

Essentially, xmldap.org allows you to create a managed card (or select a previously used one from the site), and then use that card to log in. If you’ve logged in correctly, you get a page that displays the SAML code sent, and displays the claims in the InfoCard. It doesn’t look very flashy, but trust me, the code underlying all this is very cool, and exciting to us security types.

Thanks to Kevin. If you want to learn more visit CardSpace web site.

CardSpace is still pretty bleeding edge, but the software is starting to get out there.  Having Firefox support is great for users, since the identity selection experience is consistent across IE or Firefox or “desktop” applications.  With respect to OpenID, clearly my view is that OpenID and CardSpace have a lot of synergy, and the identity community is working hard to maximize this.