NOVELL BANDIT

Here's a piece from Network World about Novell's new open-source identity initiative, called Bandit:

Novell has launched an ambitious open source identity management project, which aims to allow companies to integrate different identity systems and provide a consistent approach to securing and managing identity.

Called “Bandit,” the company quietly initiated the project earlier this year, and has been donating engineering resources and code to get things started.

Novell has a track record in identity management products and some credibility in the open source world, due to its acquisition of SuSE Linux, and is hoping that a freely available integration layer will mean more sales for the whole identity management market.

“Novell's initial sponsorship of the Bandit project is a natural extension of our leadership in both identity and open source, and we are gratified to see the groundswell of community support,” Novell Executive Vice President and CTO Jeff Jaffe said in a statement.

The company has lined up support for Bandit from a number of key industry players, including ActivIdentity, Eclipse, IBM, Liberty Alliance, Microsoft, Novacoast, Red Hat, Sun, Sxip Identity, Symantec and Trusted Network Technologies.

“The Identity Metasystem provides a model for identity interoperability across the industry. We're happy to see Novell playing an active role in helping realize the Identity Metasystem and look forward to working with them to ensure interoperability between our respective products,” said Kim Cameron, architect of Identity and Access for Microsoft, in a statement.

The Bandit services will work with existing industry standards such as the WS-* standards, Liberty Federation and Eclipse Higgins. Indeed Bandit has some overlap with the open-source Higgins effort, Novell has acknowledged, and Bandit's developers are planning a Higgins context provider based on Bandit's Common Identity service. The context provider is the way the Higgins framework accesses different identity repositories.

Ultimately, Bandit aims to provide an easier approach to problems such as secure, role-based access and regulatory compliance reporting, Novell said. The project's four main components are the Common Authentication Services Adapter (CASA), the Common Identity service, the Role Engine service and the Audit Record Framework service.

Industry analysts have said the initiative appears promising, given Novell's background and the apparent willingness of other heavyweights to participate.

“This is not the first open source identity management initiative, but the involvement of identity management heavyweight Novell is significant,” said Neil Macehiter, partner at analyst firm Macehiter Ward-Dutton, in a research note. “The fact that the project is focusing on higher-level identity management issues gives it added significance.”  

Dale Olds, the distinguished engineer behind the initiative, has shown a lot of leadership in the open source community by throwing Novell's support behind Information Cards.  He's a serious guy – serious about interoperabilility.

Dale's belief that identity can't have boundaries or borders is palpable.  We'll all benefit from his work.

LONG LIVE INFORMATION CARDS…

 Progress Bar says:

I have to gently disagree with Kim Cameron about the renaming of InfoCard. Personally, I thought it [InfoCard] was a fine name. Then again I am a Mac user and Keychain just makes sense.

Now, it has the Windows name in it. Why? Second, contains the word space, similar to namespace, which I think of in technical terms like an XML namespace and my unscientific interviews this morning produced much head scratching from regular people. Not a big deal in the grand scheme of things but still irks me.

Let me clarify things a bit. 

InfoCards don't go away – instead they are transformed into “Information Cards”. 

So from now on, I'll be writing about Information Cards.  I hope that one day Apple will have a way to use Information Cards.  Not to mention Linux and Unix and telephones and iPods.  I hope they all behave in a more or less recognizable way, just as we can all get into a car we've never seen before, look at the steering wheel and pedals, and know how to drive it – inspite of every car having its own character.

Our research shows the growing understanding of “InfoCards” will transfer just fine to “Information Cards.” 

In fact if someone kept calling them InfoCards or ICards or Cards the meanings would all still hold together. 

But as a name that reaches across the industry, it is best to have one that no one owns, and that we don't have to debate, because it is just a generic statement of purpose.

Meanwhile, we have the small detail of this implementation on Windows and the fact that it's going to ship soon.  Our implementation is a place where you can put your Information Cards.  So we're calling that your CardSpace.  We don't intend to Windows it to death – I expect it will normally be refered to as CardSpace once you are inside the Windows world.  Of course, I don't work for the Department of Naming and don't have my branding license.

For the last year, my friends and colleagues in other companies and organizations have been hard core about wanting me to better separate between the “Identity Metasystem”, the “cards” that stand for identity relationships, and the Microsoft Implementation of all this.  I think everyone wants to participate in the emerging identity metasystem.  But people don't want their participation to be seen as too closely mixed up with Microsoft's implementation. 

In the early days of the project I didn't understand all these complex issues so we ended up with the same name being used for all three purposes.

Now, we've tried to do what our colleagues have been asking for.  The name of the “big idea” – Information Cards – is generic and belongs to the industry and the world.  The Identity Metasystem is something each of us contributes to in our own way.  Windows CardSpace is Microsoft's implementation of an identity selector on the Windows client. 

I will be working with colleagues from other companies on a common logo that can be displayed wherever Information Cards are accepted.

I should have made all of this clearer when I first blogged about it.  But thanks to the miracle of the Blogosphere it's possible to see when you haven't been clear about what you are doing.  So, I hope this helps.

MIKE BEACH ON FEDERATION AND USER CENTRIC IDENTITY

Here is more fallout from James McGovern's intervention about InfoCard as a “consumer” interest. 

It's a posting from Mike Beach – an identity pioneer all of us in the enterprise world respect, and who was one of the first to get an inter-corporate federation system off the drawing board and into production. 

His thinking has the benefit not only of vision, but of a lot of real experience.  Whatever he says, pro, con or neutral, I always start by assuming he is speaking to us from the future:

I agree with Kim that the Infocard/Identity Metasystem (or some other form of user-centric identity implementation) will find its way into the corporate world and help to solve some interesting problems. I have recently been mulling the potential impacts to both privacy and federation.  

In the privacy space a colleague of my shared an interesting perspective. Most corporations, especially in the B2C space, have considered user/customer identity data to be an asset. Knowledge about their users that could be leveraged for any number of marketing opportunities. With the rising concerns and increasing regulations around privacy this perspective is, or should be, starting to change. This “asset” is now becoming a liability. Data about people (corporate people and consumer people) is always going to be required to do business, but how do we get that while at the same time minimizing liability? Enter the Infocard concept. It would seem we now have a means to establish authoritative data about the user, but give it to the user for safe keeping.

Relative to B2B federation it also appears the Infocard concept can add value.

Today many federations are established by corporations “on behalf” of their employees.

Consider the many corporate benefits providers that are establishing SSO federations with their clients. The employees are at the mercy of their employer and the benefits providers to ensure security and privacy, and typically have no choice in the matter. I realize the federation standards provide for “opt-in” federation, but I don’t see that fleshed out in products and implementations.

Again enter the Infocard concept. The potential for eliminating the magic, invisible, mandatory federation of today. The corporations can issue Infocard credentials to employees that can be used at benefit provider sites – or not. Employees have visibility, control, and choice. I can imagine the Infocard concept becoming the new federation user experience.

This phrase haunts me, and should haunt the industry:  “The magical, invisble, and madatory federation of today.”

I tend to believe that if anyone knows what the gotchas are, it's Mike.  So having him in this conversation is essential.  Hey Mike, it's time to blog…

DEPERIMETERIZATION AT 1 RAINDROP

Seems like Gunnar Peterson of 1 raindrop finds the intersection of InfoCard and Federation as interesting as I do.  And in resonance with my recent post on enterprise identity management, his taxonomy includes the fascinating “deperimeterization” – I see that while I wasn't working he's done a whole much of good work on this.

Ping is set to demo its new Infocard authentication + federated SSO at Catalyst.

A user authenticates to a healthcare portal leveraging a self-asserted InfoCard. The user’s credentials are validated by a Java InfoCard Server built by Ping Identity. PingFederate is then used to enable federated single sign-on to a remote Web site without a redundant user authentication.

Pinginfocarddemo

 

There are a number of interesting aspects here including proving out Identity Law 5, which is, of course, Pluralism of Technologies and Operators, jacking InfoCards assertion into the federation network through the WS-Trust backplane, and the ability of InfoCards to help to strengthen the authentication process, for example through a smart card and then have that assertion carried through the system, Brian Snow:

Consider the use of smartcards, smart badges, or other critical functions. Although more costly than software, when properly implemented the assurance gain is great. The form factor is not as important as the existence of an isolated processor and address space for assured operations – an “Island of Security” if you will.

An island of security in a networked world, now there is a future worth inventing.

Is it really an island?

TIARA.ORG – A MAJOR IDENTITY SITE

O.K.  I've hit a gold mine.  It's called Tiara.org.  Who or what is Tiara?  “A PhD student in the Department of Culture and Communication at NYU, studying social technology from a feminist perspective.”  Go to her “About me” page and it has everything except… a name – at least in a form straightforward enough to come up in a search engine.  So for me she's just Tiara.

Tiara has assembled a spectacular identity bibliography.  I'm going to ask if she'll let me put it up on identityblog – with credit to her, of course.

It turns out Tiara had blogged about the Times’ Facebook story over the weekend.  Somehow through the miracles of ping-backs this floated past my desktop:

Kim Cameron, the architect of MS’ Infocard Identity Metasystem, which I’m not at all a fan of, writes a great post on Facebook and the globalization of identity, based on the NYT article I blogged over the weekend.

Wow.  Such a smart person is not a fan of the identity metasystem.  I need to find out more about this.  None the less, we seem to agree when it comes to some of the issues raised in the Facebook article.  After quoting my piece, she continues:

Beautiful point: Facebook (& MySpace) are extremely performative communities, where the values being espoused– being cool, being “hard”, being sexy, being transgressive, being resistant– are those of mythical teenage worlds. There’s not just a generation gap between teens/young adults and their future possible bosses, there’s a culture gap between the “professional world”, where we’re not really supposed to have any sort of interesting personal lives (witness the furor over academic blogging), and the “online world”, where we’re supposed to be larger-than-life (microcelebrity again!).

I also like Cameron’s point about companies not being “invited” into these worlds. I definitely feel that Facebook is a private community, and I don’t go poke around looking for my undergraduate students, because it’s none of my business what they do in their private lives. But, again, as I said the other day, there are no regulations about searching social networking sites (or even just Google) , and there aren’t likely to be. The justification that it’s public information trumps the contextualization argument.

I talked to someone else recently who said that their local sheriff’s office uses MySpace as a first resource whenever they are looking for something or bringing someone in — of course it’s a young receptionist who does the searching. And universities like UC Santa Barbara are formulating specific policies to discipline students based on their Facebook information. So although I agree with Cameron, it’s really irrelevant. As long as sites like MySpace and Facebook are viewed as public information, they will not enjoy any type of protection from authorities or employers.

It's not really irrelevant.  There are a lot of issues buried here, and I'm not about to give up the ghost on them. 

One question I have is whether it is possible for an operator to provide access to a site for specific reasons – and prevent it for others.  In other words, is it possible to require those entering a site to sign a binding statement of use?  Can liability be associated with breaking such an agreement? 

Let's go further.  Is it possible to prevent usage of a site for commercial purposes, or purposes of employment, or in the interests of an employer? 

I'm going to be at the identity mashup hosted by Berkman Center for Internet and Society at the Harvard Law School next week.  I'll should probably be able to find a few (hundred) lawyers there.  I'll try to find out more about these issues. 

But as Tiara says in her own interesting post on the matter:

So what’s “the solution”? I’ve heard three:
1. Young people should stop putting content online.
2. Recruiters and employers shouldn’t use Google or Facebook to research potential candidates (don’t hear this one very often, although you’d think in a country where it’s illegal to ask people to include a snapshot with their resume, there might be potential room for legislation here).
3. We just have to wait until there’s no longer a divide between your “work” persona and your “life” persona. I know this sounds stupid, but I heard it from the CEO of Facebook.  (Tiara heard it from the CEO of Facebook??? – Kim)

And here’s what’s actually happening: People are obfuscating personal data by using pseudonyms that can only be identified within situated, contextual networks, or by using services which allow them to restrict who can view their personal information. This is really the only one of these solutions which makes any sense.

O.K.  So we totally agree.  Contextual separation is one of the main concepts behind the identity metasystem.  I suspect she has impressions of what we are trying to do that just aren't accurate.

In truth, InfoCards and the metasystem have been designed to enable privacy while still being able to make provable assumptions.  For example, the system can be used to allow you to limit access to your site to full-time students – and recognize them when they return – without actually knowing their names or exposing their identities to the digital grim reaper.  The very problems Tiara worries are not solvable, are actually some of those addressed by this system.

And in truth, they have to be addressed if the resulting infrastructure is to be consistent with the “third law of identity”.  Identity information should only be available to relevant parties.  As an industry we need to think about how the virtual fabric will work and offer people separation of context – or there will be a further and terrible erosion of confidence in cyberspace by those who constitute its future inhabitants.

ENTERPRISE AND INDIVIDUAL IDENTITY

James McGovern over at Enterprise Architecture: Thought Leadership has a nice post where he poses questions for a bunch of his blogrollers.

It's not that the questions are wicked.  He asks Dan Blum:

Would it be possible for you to figure out creative ways for others to observe the client/analyst dialog in a more public fashion? What would it take for you to start blogging more frequently?

Pat Patterson gets this one:

What would it take for you to get Liberty Alliance to embrace the WS-Federation specification? Having federation capabilities built directly into an operating system is liberating…

And for me:

I would love it if you could start talking about identity from a corporate perspective and not stay exclusively focused on consumer-centric identity. You can leave the consumer stuff to Dick Hardt…

It's true I've been dealing a lot with user-centric identity.  But James, the future of the corporation will unfold largely in the virtual world.  What will then be more important to a corporation that its relationships with its “consumers”?  The lack of a reliable grid for dealing with the individual in the digital world is, in the big picture, the most urgent corporate identity issue of our time. That's one of the reasons I was led into the problem area.

The most important thing about the identity metasystem the way it creates a unified infrastructure reaching between the corporation (or organization) and the individual (aka consumer).

What are we going to have?  One set of precepts that faces towards the inside of the corporation, and another completely different set that faces the outside?  That doesn't compute, and my work on this blog applies to both sides of this boundary.

The whole evolution of business is towards a more open mesh of interconnecting organizations in which individual relationships are key.  So empowering the individual within the organization will increasingly become the most important aspect of empowering the corporation.  The dichotomy you propose is a false one.

One of the most interesting trends I've seen is that of enterprises “kicking their employees out of the firewall”.  This isn't a good strategy in all cases, for sure, but I've seen a bunch of studies of companies that have slashed IT expenditures by treating their own employees as external individuals (factors of 10)!  More than one of these just tell their employees to buy their own PCs outfitted with various programs “off the street” and expense them back to the company – and still get order of magnitude savings.  They only keep there line of business apps remain behind the firewall.

I'm not proposing this as a direction forward – simply reporting on trends I see.

Reliable identity-based collaboration between individual users which also integrates with organizational identity will empower them both the users and the organizations.  Making progress on this front is the most important single thing we can do right now to help the corporations we work for benefit from technology.  That is the big picture.

One key takeaway from your request is that I should explain where I'm coming from a lot better.  On a related theme, I'm getting ready to spend more time on the challenges of being “the relying party” in identity transactions, so I'll try to build these notions into what I'm writing.

You probably know that metadirectory, self-management and provisioning of identities all form an interconnected cluster of passionate interests for me.  Note to self:  start writing about these issues too.

GUIDANCE AND TEST PLAN FOR RELYING PARTIES

I got a note recently from federation master Mike Beach – a man with a great deal of experience in terms of how users react to security:

Is it just me or does your site have an invalid cert.  When I attempt to
login using my new Infocard in IE7 I get the infamous “warning, go back, do
not enter, danger ahead” and things go all red (really more pink).

Given the primary drivers of Infocard are to save us from all the web evils
of today it would seem this is contrary reinforcement when I must ignore all
the security warnings to log in.

I thought, “That's weird.  I don't get that problem.”  – you know, the ancestral “That's funny.  It doesn't happen on MY box.”  But of course it really was happening to Mike, so I wrote back and asked if he could send some screenshots.  It turned out this wasn't necessary – he had already figured out the problem.

He had been visiting identityblog using this URL:  http://identityblog.com/.  

When he clicked on Login he was redirected to https://identityblog.com/wp-login.php.  

But my certificate is limited to http://www.identityblog.com/.  Therefore IE (correctly) saw Mike's identityblog.com and the certificate's www.identityblog.com as being different – resulting in the redish bar.  It looked like this:

 

That's enough to confuse anyone.  So clearly, redirecting to something that isn't consistent with your certificate is a no-no.  I was setting up an experience that would undermine my user's understanding of what was happening to her, breaking law six.  I should have been checking and redirecting to www.identityblog.com even if the user didn't supply the “www”.  Strangely, I had done the Dashboard link correctly – it was only the Login link that had the error.

All of which goes to show there are a set of gotchas that we have to nail down in terms of establishing prescriptive guidance for how a site should deal with these issues in order to be consistent.  We need a checklist – or better still, a test plan.  A wiki would be a good way to elaborate this.

Another big takeaway is that an identity 2.0 relying party has an obligation to make sure it doesn't do things that send mixed signals (in my case, nice InfoCard experience but big red warning bar in IE).  Everyone has to co-operate with the goal of not confusing the user.

It's worth pointing out that none of this is primarily an InfoCard problem.  The same considerations apply to any use of https.  But in the InfCard case we want to make sure we have the deployment practices nailed down to a higher level than has previously been the case.

PERSONAL INFOCLOUD

Somehow I tumbled into Personal InfoCloud today.  It's a thought provoking site by Thomas Vander Wal, with all kinds of nooks and crannies that lurch off into explorations, from many points of view, of how information and technology could be restructured from the vantage point of the individual.  You should poke around yourself to get a sense for how these ideas hold together;  but here's part of a post on the Come To Me Web:

The improved understanding of the digital realm and its possibilities beyond our metaphors of the physical environment allows us to focus on a “Come to Me” web. What many people are doing today with current technologies is quite different than was done four or five years ago. This is today for some and will be the future for many.

When you talk to people about information and media today they frame it is terms of, “my information”, “my media”, and “my collection”. This label is applied to not only information they created, but information they have found and read/used. The information is with them in their mind and more often than not it is on one or more of their devices drives, either explicitly saved or in cache.

Many of us as designers and developers have embraced “user-centered” or “user experience” design as part of our practice. These mantras place the focus on the people using our tools and information as we have moved to making what we produce “usable”. The “use” in “usable” goes beyond the person just reading the information and to meeting peoples desires and needs for reusing information. Microformats and Structured Blogging are two recent projects (among many) that focus on and provide for reuse of information. People can not only read the information, but can easily drop the information into their appropriate application (date related information gets put in the person's calendar, names and contact information are easily dropped into the address book, etc.). These tools also ease the finding and aggregating of the content types.

As people get more accustomed to reusing information and media as they want and need, they find they are not focussed on just one device (the desktop/laptop), but many devices across their life. They have devices at work, at home, mobile, in their living space and they want to have the information that they desire to remain attracted to them no matter where they are. We see the proliferation of web-based bookmarking sites providing people access their bookmarks/favorites from any web browser on any capable device. We see people working to sync their address books and calendars between devices and using web-based tools to help ensure the information is on the devices near them. People send e-mail and other text/media messages to their various devices and services so information and files are near them. We are seeing people using their web-based or web-connected calendars to program settings on their personal digital video recorders in their living room (or wherever it is located).

Keeping information attracted to one's self or within easy reach, not only requires the information and media be available across devices, but to be in common or open formats. We have moved away from a world where all of our information and media distribution required developing for a proprietary format to one where standards and open formats prevail. Even most current proprietary formats have non-proprietary means of accessing the content or creating the content. We can do this because application protocols interfaces (APIs) are made available for developers or tools based on the APIs can be used to quickly and easily create, recreate, or consume the information or media.

People have moved from finding information and media as being their biggest hurdle, to refinding things in “my collection” being the biggest problem. Managing what people come across and have access to (or had access to) again when they want it and need it is a large problem. In the “come to me” web there is a lot of filtering of information, as we have more avenues to receive information and media.

The metaphor and model in the “I go get” web was navigation and wayfinding. In the “come to me” web a model based on attraction. This is not the push and pull metaphor from the late 1990s (as that was mostly focussed on single devices and applications). Today's usage is truly focussed on the person and how they set their personal information workflow for digital information. The focus is slightly different. Push and pull focussed on technology, today the focus is on person and technology is just the conduit, which could (and should) fade into the background. The conduits can be used to filter information that is not desired so what is of interest is more easily identified.

It's exciting that Thomas has already had the identity aha.  I think a framework like the one he proposes – based on attraction – is probably an early harbinger of the identity big bang.

 

WHAT INFOCARD IS AND ISN'T

Computer Security Alert has done a nice frontpage feature on “What InfoCard is and isn't” in its May 2006 issue.  The Alert is normally only available to members, but Robert Richardson has given me permission to let you download and reprint the PDF version, complete with sidebars – or you can read the main part of the story here: 

There’s little doubt that the Microsoft marketing engine will get itself geared up to tell the public at large what InfoCard “is,” but in the meanwhile, getting a handle on the next major security-related software introduction is remarkably difficult. It’s a slippery topic.

The place to start, however, is with the diagram below from an overview of the “Identity Metaverse” by Microsoft’s identity guru Kim Cameron.

The box at the very bottom of the diagram is you, the subject. If you go to a Web site or an application that requires you to establish that you’re authorized to use its services (where in the past you’d have been challenged for a username and password), you’ll instead be shown an interface where you can choose from what appear to be traditional “ID cards.” Simply put, that interface is InfoCard. That’s it.

Or, at least, that’s how to draw a line around it that differentiates it from everything else. Obviously, there’s more to it than that. For one thing, it’s running in a different security context than the rest of your applications on whatever operating system you happen to be running. It’s supposed to be completely cordoned off in terms of memory access and the like. Other applications (and, say, viruses that have installed themselves unbeknownst to you) can’t see memory that’s being used by the InfoCard interface.

Cameron does note that “if you get a rootkit, you’re in trouble. But Vista makes it much less likely that you’ll get one, because you almost always run in your own context (e.g. not at ‘root’ privilege). A virus caught in your user context cannot see your InfoCard screen or memory.” There are other security gains as well, Cameron notes: “InfoCard protects against keyloggers because typing of shared secrets becomes obsolete. And social engineering attacks are mitigated because Web sites no longer control the user experience. Finally, sensitive information like a credit card number is never stored on the PC, or visible to a virus running there.”

InfoCard presents your various credential possibilities to you in the form of “cards,” so not too surprisingly there’s also a mechanism for generating your own self-signed InfoCard and then issuing encrypted tokens when the card is used (in other words, there’s a tool for making yourself into an ID Provider, which Microsoft’s documents often refer to as an IP, but which we’ll call an IDP in the hopes of not creating confusion around the already overloaded “IP” acronym)—this too is part of InfoCard.

Finally, there’s a strong sense that this is what Microsoft thinks every operating system’s authentication interface should look like: an isolated page where you pick from your various ID cards. This really isn’t about Redmond wanting everything to look like a version of Windows—in fact InfoCard is trying to look a bit different than the rest of the Windows Vista operating system. Rather, it’s supposed to look different from everything else altogether, so that you the user realize you’ve entered one of those transitional moments where you may be handing over some of your personal information.

But other than these pieces, everything else in the identity management universe is something other than InfoCard. The part where the InfoCard interface talks across the network and exchanges information isn’t InfoCard, but the WS-Trust standard. The server that creates a token that attests that you’ve got authorization to use a certain service isn’t InfoCard either, but something like a certificate authority (CA) or perhaps something a little more old-fashioned like a Kerberos server. The primary thing that InfoCard does is allow you to choose which of several identities you want to use in a given situation where you’ve been challenged for ID.

The “cards” represent your various identities. The “cards,” it’s vital to note, don’t contain information about you, per se. You won’t find your name and address or your social security number stored in one of your cards. Instead, enough metadata is stored that when the appropriate moment arrives, InfoCard can communicate to the IDP to say who you’re supposed to be. The IDP will confirm this by challenging you in one way or another (doesn’t matter to InfoCard what that way is—it’s completely agnostic in this important respect—but it may very well matter to the Web site that is requesting the information).

So the IDP plays an important role in this, but as we mentioned above, may in some cases actually be you, as self-provider of a card (this is the situation you’ll find yourself in at a Web site that asks for a login name or e-mail address but otherwise doesn’t care who you are). The other player (besides you, the user of all this splendor) is the Web site that wants to know who you are in the first place. In today’s pre-InfoCard world, this site would normally challenge you for a username and password and check up on your assertion that you are in fact you on its own steam. With InfoCard, this site becomes a Relying Party (RP) and actually gets its assurance that you are you by way of the IDP.

There are early releases of InfoCard in the hands of developers, and blog reports so far make it clear that it’s pretty fragile just yet—it takes just the right combination of operating system release, Explorer browser preview and InfoCard code to make the thing work. It does work if you get it all right, but would seem that there are only a handful of non-Microsoft people in the world who’ve managed to InfoCard their way into a site (such as Cameron’s identityblog.com). As Cameron puts it, “it’s new, it’s evolving quickly, and it hasn’t stabilized yet.”

What happens bat game time

So with the various pieces in place, we can walk through the mechanics of an InfoCard transaction. We’ll talk here about going to a Web site, but clearly there are other use cases, such as internal applications that directly invoke the InfoCard interface to authenticate the user with an intranet application, perhaps built on a service-oriented architecture.

Arriving at the site

I’m an InfoCard-enabled user and I arrive at my bank, which has now implemented support for this interface. My arrival causes a page to be sent to my browser, as would always be the case. Indeed, the page my still contain all the usual paraphernalia for a traditional login.

Triggering the InfoCard process

What’s also in the HTML page that is sent to my browser, however, is an HTML OBJECT tag. The browser, which also has to be up-to-date, recognizes that this object has a “type” parameter that identifies it as an InfoCard request. It therefore triggers the InfoCard dynamic link library (DLL) module. The stage is set and the screen dims (I’m not kidding, it really does dim—another way of differentiating this process from normal computing activities as well as a way of making the process harder to spoof).

InfoCard gears up

Among the parameters passed to the DLL from the OBJECT tag are the claims about the user that need to be proven. These might be things like the user’s name, but on the other hand, the Web site may only need to know some anonymous piece of information, such as that the user is older than 21. Generally, the site should only have requested what it needs to know. The DLL compares the claim requests to the user’s InfoCards to see what claims can be met by which cards, and then displays those that can meet the request (others are visible but grayed out).

The user picks a card and is challenged

This is an important moment if you think about it. The user may use any card that meets the requirements of the Web site’s request. A user might maintain different personas with different sets of proofs for different contexts. With the selection made, the DLL contacts the IDP via WS-Trust. The IDP then does whatever it needs to do to authenticate the user. Possibly it asks for a username and password; possibly a one-time password must be used or some biometric proof supplied.

A secure token is issued and reviewed

Assuming the user successfully authenticates with the IDP (not the Web site, which is the RP in this scenario, it’s important to keep in mind), the IDP places the appropriate claims into an XML document and then uses the RP’s public key to encrypt them. This is sent not to the RP but back to the user’s InfoCard process, which displays the claims that are about to be sent so that the user can review them.

The approved claims are forwarded

If the user is comfortable with passing the information in the claims along to the Web site, they press a Submit button and the encrypted token is forwarded to the RP, which will now grant access to the user. The Web object in more detail Jumping back a step, notice that the mechanism for invoking the InfoCard interface really is pretty much as simple as it sounds. A snippet of HTML code is added to the rest of the material in the Web page, as in this example from Andy Harjanto’s Infocard Weblog.

Notice that this example shows a Web site that requires a SAML assertion for authentication. The RP may not get to dictate that I’ll provide my credentials or that I’ll provide a specific credential if there are several that meet the need, but it does get to dictate what kind of credential must be provided if it’s to be considered sufficient. Specifically, the RP can make requests concerning:  

  • The issuer;
  • The type of token that will be returned;
  • What claims must be vouched for by the token;
  • Requirements regarding the kind of proof used (symmetric, public key, etc), the size of the key used in authentication and other such details as might be required for high-security scenarios.

It’s worth underscoring that the RP only receives proofs of the specific claims it requests, not access to any kind of full profile of data about the individual. The user (or, at any rate, not the RP) gets to choose where data used for this particular user’s authentications are stored. This ability to separate authenticated claims from specific identities is potentially a huge gain for Internet privacy. This would be true even in relatively small ways: one can imagine being able to post comments at a blog site anonymously, but only after proving that one had the reputation (from actions at other sites) of never posting spam. Anonymity is preserved while the social good of keeping out bad actors is upheld.

On the other hand, we shouldn’t overstate how much may be gained in the real world—RP’s may still very well want a full complement of information, including name, address and credit card numbers, before selling you their products. And once they’ve got the information, they may well decide to store it, even insecurely.

As an aside, Microsoft has taken the interesting step of essentially not providing any kind of normal application/programming access to InfoCards. They are stored in their own little world; there is no API to access them. The effect of this is that cards don’t get deleted or modified or added without the user’s direct involvement, because these steps must be taken through the InfoCard interface.

For the InfoCard interface to be invoked, of course, there has to be some software resident on the user’s system. At present, it gets there by way of a purpose-built software file (a DLL file) that has to be expressly loaded along with Internet Explorer 7. These things will be part and parcel of Microsoft Vista, when it’s released next year, but users who stick with XP will have to download these pieces in order to use InfoCard.

Given that migration to Vista is bound to take place at a measured—perhaps even downright reluctant, depending on the vicissitudes of the market—pace, one question is whether the requirement for additional specialized software will make Web site developers reluctant to get involved. Obviously, they can use pre-existing login routines for users who don’t have InfoCard capability on their machines, but having two systems will just complicate life. Cameron says it’s not all that much more complicated, however: “We’ve taken this into account so the changes to a Web site are absolutely minimal.”

Organizations may or may not decide that dealing with InfoCard is worth the trouble—it will have to move beyond its current proof-of-concept stage before anyone can decide—but one thing organizations don’t have to do, should they opt to use InfoCard, is run Windows servers. From the “Microsoft’s Vision for an Identity Metasystem” white paper:

    Non-Microsoft applications will have the same ability to use “InfoCard” to manage their identities as Microsoft applications will. Non-Windows operating systems will be able to be full participants of the identity metasystem we are building in cooperation with the industry. Others can build an entire end-to-end implementation of the metasystem without any Microsoft software, payments to Microsoft, or usage of any Microsoft online identity service.

Just to prove that this is so, Cameron, who’s in charge of the InfoCard project, moved his identityblog.com over to non-Microsoft software (completely so: he’s running the classic, open-source LAMP stack). The blog is running on WordPress (also open source) and he’s written his own PHP scripts to handle the InfoCard login process. By Cameron’s own admission, it’s still a bit buggy and it lacks a certain degree of polish:

    Some of the user experience is still pretty “basic”. Like what happens if you click on InfoCard login and don’t have InfoCards installed. When I have some time I’ll make that take you to a page that tells you what InfoCards are, how they work, how to install them, and that sort of thing. But for now, the behavior should appeal to lovers of cryptic error messages.

So at least in theory, the Linux and Macintosh systems of the world could implement compatible identity selectors, RPs and IDPs that were all compatible with InfoCard. And, really, it’s only that it’s Microsoft doing the developing that makes it seem like InfoCard is the driving force here. In point of fact, InfoCard’s mission is to work with WS-Trust, an open standard (we could quibble about how open it is, but at least there’s nothing preventing anyone from using it). So the open standards for identity, such as WS-Trust, are really the driving force behind InfoCard. In any case, identity management seems to be entering something of a 2.0 phase, and there’s no question that InfoCard will play a significant role in whatever that turns out to be. — R.R.

METRICCON 1.0 – CALL FOR PARTICIPATION

This sounds like the best thing since sliced bread:

Ever feel like Chicken Little? Wonder if letter grades, color codes, and/or duct tape are even a tiny bit useful? Cringe at the subjectivity applied to security in every manner?

If so, MetriCon 1.0 may be your antidote to change security from an artistic “matter of opinion” into an objective, quantifiable science. The time for adjectives and adverbs has gone; the time for numbers has come.

MetriCon 1.0 is intended as a forum for lively, practical discussion in the area of security metrics. It is a forum for quantifiable approaches and results to problems afflicting information security today, with a bias towards practical, specific implementations. Topics and presentations will be selected for their potential to stimulate discussion in the Workshop.

Workshop Format

MetriCon 1.0 will be a one-day event, Tuesday, August 1, 2006, co-located with the 15th USENIX Security Symposium in Vancouver, B.C., Canada. Beginning first thing in the morning, with meals taken in the meeting room, and extending into the evening.

Attendance will be by invitation and limited to 50 participants. All participants will be expected to “come with opinions” and be willing to address the group in some fashion, formally or not. Preference giventothe authors of position papers/presentations who have actual work in progress.

Each presenter will have 10-15 minutes to present his or her idea, followed by 15-20 minutes of discussion with the workshop participants. Panels may be convened to present different approaches to related topics, and will be steered by what sorts of proposals come in in response to this Call.

Goals and Topics

The goal of the workshop is to stimulate discussion of and thinking about security metrics and to do so in ways that lead to realistic, early results of lasting value. Potential attendees are invited to submit position papers to be shared with all. Such position papers are expected to address security metrics in one of the following categories:

– Benchmarking
– Empirical Studies
– Metrics Definitions
– Financial Planning
– Security/Risk Modeling
– Visualization

Practical implementations, real world case studies, and detailed models will be preferred over broader models or general ideas.

How to Participate

Submit a short position paper or description of work done/ongoing. Your submission must be no longer than five(5) paragraphs or presentation slides. Author names and affiliations should appear first in/on the submission. Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be submitted to MetriCon AT securitymetrics.org.

Presenters will be notified of acceptance by June 15, 2006 and expected to provide materials for distribution by July 15, 2006. All slides and position papers will be made available to participants at the workshop. No formal proceedings are intended.

Location

MetriCon 1.0 will be co-located with the 15th USENIX Security Symposium (Security ’06).
Cost

$200 all-inclusive ofmeeting space, materials preparation, and meals for the day.

Important Dates

Requests to participate: by May 15, 2006
Notification of acceptance: by June 15, 2006
Materials for distribution: by July 15, 2006

Workship Organizers

Andrew Jaquith, Yankee Group, Chair
Adam Shostack, emergentchaos.org
Gunnar Peterson, Arctec Group
Elizabeth Nichols, ClearPoint Metrics
Pete Lindstrom, Spire Security
Dan Geer,Verdasys

Funny, I was just at a conference today arguing that the truth is in the quantitative studies.  There are some wonderful people putting this together – it seems full of promise.