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.

AOL and “63 Million OpenIDs”

First Microsoft's announcement with JanRain, SXIP and Verisign at RSA.  Now news that AOL has launched an experimental system and announced it will support the next version of OpenID. 

The world streams by at breakneck speed.  We're getting some real momentum on this convergence thing.  I hear the identity big bang coming towards us.  Here's a fascinating post by panzerjohn at dev.aol.com

Yesterday, I blogged about AOL's work-in-progress on OpenID. It generated a lot of positive commentary. I realized after reading the reactions that I buried the lead: There are now 63 million AOL/AIM OpenIDs. Anyone can get one by signing up for a free AIM account. This is cool.

To address Paul's concern in Please delete my aol OpenID: We definitely want the user to be in control of their online presence. At the moment, the OpenID URL at openid.aol.com redirects you off to an AIM Profile. That's not necessarily the long term experience, though I think it should be one of the default options. George Fletcher has pointed out that it would be even better if we could redirect people off to whatever page they wanted, as long as they could verify that they owned the page. My take is, if you don't actually use the OpenID URL, it doesn't really exist. The same way a Wiki page doesn't exist until you edit it. On the other hand, having people go in and kick the tires to uncover issues is exactly why we're talking about this. So let us know what you think.

Another important point is that you can point at the AOL OpenID service from any web page you own in order to turn its URL into an OpenID. The minimal requirements are basically that you have some AOL or AIM account, and that you add a couple of links to your document's HEAD:

link href=”https://api.screenname.aol.com/auth/openidServer” mce_href=”https://api.screenname.aol.com/auth/openidServer” rel=”openid.server” 

link href=”http://openid.aol.com/screenname” mce_href=”http://openid.aol.com/screenname” rel=”openid.delegate”

We added this to our blogs product in a few minutes minutes and it's in beta now. You can also support YADIS discovery which gives additional capabilities. See Sam Ruby's OpenID for non SuperUsers for a good summary.

The detailed status from yesterday's post:

  • Every AOL/AIM user now has at least one OpenID URI, http://openid.aol.com/screenname.
  • This experimental OpenID 1.1 Provider service is available now and we are conducting compatibility tests.
  • We're working with OpenID relying parties to resolve compatibility issues.
  • Our blogging platform has enabled basic OpenID 1.1 in beta, so every beta blog URI is also a basic OpenID identifier.  (No Yadis yet.)
  • We don't yet accept OpenID identities within our products as a relying party, but we're actively working on it.  That roll-out is likely to be gradual.
  • We are tracking the OpenID 2.0 standardization effort and plan to support it after it becomes final.

(I should clarify that I really work in the social networking / community / profile / blogging groups at AOL rather than the identity group per se. You can look to see what I actually do on a day to day basis over at my personal blog.)

This is amazing stuff.

Ignite Deux Seattle

Jackson Shaw knows as much about identity management as anyone.  I very much value his thinking.  If that weren't enough, there is that irresistable love of life that sweeps everyone into his energy field.  I think it comes through in his new blog:

No, it's not another French post from Jackson. Tonight I did something a bit different. I headed over to the Capital Hill Art Center in downtown Seattle to watch . There were 21 speakers scheduled including Scott Kveton the CEO of the folks behind . As you probably know, my buddy Kim Cameron is the man behind the curtain for Microsoft's CardSpace initiative ( I guess I should stop calling it an initiative – it is actually part of Vista now) and at the RSA conference Microsoft announced that CardSpace would be interoperable with OpenID.

I thought since Scott was going to present I might as well go over and see what all the hub-bub was about. The format of the evening was interesting in itself. Presenters had 5 minutes – only – to present their 20 slides! That's 15 seconds a slide. Scott was third presenter in the first volley of speakers. The first talk was from Matthew Maclaurin of Microsoft Research on Programming for Fun/Children/Hobbyists/Hackers. The second was from Elisabeth Freeman (Author in the Head First Series, Works at Disney Internet Group) on The Science Behind the Head First Books: or how to write a technical book that doesn’t put your readers to sleep. Then Scott was to speak.

First, I was shocked to walk into this “art space” that was packed to the rafters with people. Was I in the wrong place? Apparently not. On the website they stated the space would hold 400 people and it was jam packed. I had this vision of a few people sitting around some tables chatting. Not so! It was pretty cool; folksy; kinda out there but very engaging. Second, what was I going to get out of a 5 minute talk? Well, the speakers kind of had the pressure on them to make their points. The ones that I saw all got to the point quickly and they all engaged the with the audience, did their thing and got off.

Check out my photos on Picasa if you want to see the shots I took which included many from Scott's talk. So, what did I learn from Scott's talk?

  • OpenID is single sign-on for the web
  • Simple, light-weight, easy-to-use, open development process
  • Decentralized
  • Lots of companies are already using it or have pledged support
  • 12-15M users have OpenIDs; 1000+ OpenID enabled sites
  • 10-15 new OpenID sites added each day
  • 7% growth every week in sites

Scott predicts that in 2007 there will be 100M users, 7,500 sites, big players adopt OpenID and that OpenID services emerge. Bold predictions but something that is viral, like OpenID has a shot at it.

I have to say I was impressed. Scott finished up with a call to action that included learning more about OpenID at openidenabled.com. I'm definitely heading over there to learn more.

I'll report back.

p.s. Here's an interesting read:

Jackson just “gets” the potential for contagion into the enterprise – assuming we can use OpenID in the proper roles and with the right protections.  Corroborates for me the possible “charging locomotive effect”.   People shouldn't be caught looking the wrong way.

As for the numbers Scott threw out, I think they are very achievable.

HelloWorld Information Cards Part III

To understand this discussion, start here and then follow the continuation links until you return to this posting. Click on the images below to see a larger and more readable version.

In the demo, as shown in the following screen shot, only the HelloWorld card is illuminated – all the other cards were “greyed out” as inappropriate:

This happened because in the Information Card login page,  the “relying party” expressed a requirement that a HelloWorld card be presented.  This was done by embedding “policy” in the “object tag” that tells the browser (and through it, CardSpace) what Information Cards will be accepted.  To drill into this, let's look again at the login page:

Here's the HTML that created it:

You'll see that one of the PARAMs in the OBJECT tag is “tokenType”.  It's set to a completely arbitrary value – one I made up to show you can do whatever you want – of http://kcameron11/identity/helloworldToken,  Since I specified this specific token type, only Information Cards that support it will illuminate at selection time when you go to this web page.  Further, the other PARAM specifies “requiredClaims”.  Only Information Cards that support these values will be possible candidates.

The InfoCard Web App and Browser Guide has more information about the OBJECT tag.

In the next installment, I'll explain how the Identity Provider works, and you'll be able to examine the code.

 

New Information Card Profile V1.0 Technical Reference

These new documents are too low-level to be of interest to people working on the practical issues of deploying Information Cards on their Web sites.  

But they may be of interest to students, researchers and the intrepid souls who really want to get their hands dirty and understand the nitty-gritty of the underlying technical elements.

The latest and most accurate version of “A Technical Reference for the Information Card Profile V1.0” is available for download here.  In addition, I've posted a new version of “A Guide To Interoperating with the Information Card Profile V1.0” since it had a few grammatical errors and an inaccuracy in one of the examples – the URI of the self-issued IP claims was incorrect.

HelloWorld Information Cards Part II

To understand this discussion, start here and then follow the continuation links. Click on any of the images below to see a larger and more readable version.

When you pressed the “Install” button on the “try it” page, you would have seen the normal “Open or Save” dialog:

If you then clicked “Open”, CardSpace would have brought you the standard “Reputation and Privacy” dialog, showing the certified details of the HelloWorld identity provider, and asking if you want to install its card:

Armed with your new card, you would have begun the “usage” demo by going to the HelloWorld information card login page:

Clicking on the InfoCard image to log in, CardSpace would have shown the “Relying Party Reputation and Privacy” page for Identityblog.  (If you normally use InfoCards at Identityblog, you won't see it.  In order to avoid “clickthrough syndrome”, it only shows up when you start a new relationship with a relying party.)

Once you approve starting the identity relationship, you are taken to your CardSpace card selector, and your HelloWorld card will be illuminated, since in this demo, the relying party has asked for that kind of card:

When you click on the card, you can preview what will be sent to the relying party should you opt to proceed. To get any information out of the HelloWorld identity provider, you need to authenticate to it. The first version of CardSpace supports four ways to do this (more in a later piece). This demo uses the simplest mechanism – entering a password within the protected CardSpace environment:

Now you'll have a chance to review the contents which will be sent from the identity provider to the relying party:

The contents include “favorite snack” – an attempt to show the elasticity of the contents. If you decide to proceed, the HelloWorld token is transfered to the relying party, which displays it verbatim:

For those who are multi-tasking as they read this, I'll show the token full size to make sure the format and contents are as clear as possible.

In the next episode I'll start looking at what goes on under the hood. Continue here

What is meant by “token independence”?

I don't want to get sidetracked into a discussion of the nuances the SAML protocol and token independence, but imagine readers will want me to share a comment by Scott Cantor – one of the principal creators of Shibboleth.  He knows something about SAML too – since he was the editor of the Version 2.0 spec.  He is responding to my recent post about why communications protocol, trust system and token payload must become three orthogonal axes:

SAML doesn’t have the problem Kim is referring to either. Both trust model and token format are out of scope of SAML protocol exchanges. The former is generally understood, but the token issue is the source of a lot of FUD, or in Kim’s case just misunderstanding SAML. This is largely SAML’s own fault, as the specs do not explain the issue well.

It is true that SAML protocols generally return assertions. What isn’t true is that a SAML assertion in and of itself is a security token. What turns a SAML assertion into such a token is the SubjectConfirmation construct inside it. That construct is extensible/open to any token type, proof mechanism, trust model, etc.

So the difference between SAML and WS-Trust is that SAML returns other tokens by bridging them from a SAML assertion so as to create a common baseline to work from, while WS-Trust returns the other tokens by themselves. This isn’t more or less functional, it’s simply a different design. I suppose you could say that it validates both of them, since they end up with the same answer in the end.

An obvious strategy for bridging SAML and OpenID is using an OpenID confirmation method. That would be one possible “simple” profile, although others are possible, and some have been discussed.

I'm not sure I really misunderstand SAML.  I actually do understand that the SubjectConfirmation within SAML offers quite a bit of elasticity.  But SAML does have a bunch of built-in assumptions within the Assertion that make it, well, SAML (Security Assertion Markup Language).  These aren't always the assumptions you want to make.  I'll share one of my own experiences with you.

CardSpace supports a mode of operation we call “non-auditing”.  In this mode, the identity of the relying party is never conveyed to the identity provider.

The identity provider can still create assertions for the relying party, sign them, and send them back to CardSpace, which can in turn forward them to the relying party.  If done properly, using a reasonable caching scheme, this provides a high degree of privacy, since the identity provider is blind to the usage of its tokens.  For example, one could imagine a school system issuing my daughter a token that says she's under sixteen that she could use to get into protected chat rooms.  In non-auditing mode  the school system would not track which chat rooms she was visiting, and the chat room would only know she is of the correct age.  This is certainly an increasingly important use case.

My first instinct was to use SAML Assertions as the means for creating this kind of non-audited assertion.  But as Arun Nanda and I started our design we discovered that SAML – even SAML 2.0 – just wouldn't work for us. 

In the specification (latest draft), section 2.3.3 says a SAML Assertion MUST have a unique ID.  It must also have an IssueInstant.  When that is the case, the identity provider can always collaborate with the relying party to do a search on the unique ID or IssueInstant, so the desired privacy characteristics dissipate.

Being a person of some deviousness who just wants to get things done, I said to Arun, “I know you won't like this, but I wonder if we couldn't just create an ID that would be the canonical ‘untraceable identifier’?”  I hesitate to admit this and do so only to show I really was trying to get reuse.

But within a few seconds, Arun pointed out the following stipulation from section 1.3.4: 

Any party that assigns an identifier MUST ensure that there is negligible probability that that party or any other party will accidentally assign the same identifier to a different data object.

I could have argued we weren't reassigning it “accidentally”, I suppose.  But there you are.  I needed a new “Assertion” type – by which I'm referring to the payload hard-wired into SAML. 

It isn't that there is anything wrong with a SAML Assertion.  The “ID” requirement and “IssueInstant” make total sense when your use case is centered primarily around avoiding replay attacks.  But I had a different use case, and needed a different payload, one incompatible with the SAML protocol.  And going forward, I won't be the last to operate outside of the assumptions of any given payload, no matter how clever.

I have looked deeply at SAML, but am convinced that protocol, payload (call it assertion type or token type, I don't care) and trust fabric need all to be orthogonal.  SAML was a great step forward after PKI because it disentangled trust framework from the Assertion/Protocol pairing (in PKI they had all been mixed up in a huge ball of string).  But I like WS-Trust because it completes the process, and gets us to what I think is a cleaner architecture.

In spite of all this, I totally buy Scott's uberpoint that for a number of common use cases SAML and WS-Fed (meaning WS-Trust in http redirection mode) are not more or less functional, but simply a different design. 

OpenID? Huh?

In a posting called “OpenID? Huh?“, Francis Shanahan, whose job it is to worry about high value financial transactions and strong assertions about molecular identity, wonders why OpenID is nothing more than a reinvention of the WS wheel.  

“I don't understand OpenID [LINK].  I'm sorry.  I've tried to understand it but I just don't get it.

“The spec is confusing but thankfully Phil Windley has translated it into a diagram for us mere mortals [LINK].

“The idea of OpenID is to provide “an open, decentralized, free framework for user-centric digital identity.” 

“And here's how the flow works (at least one of the scenarios).  Note I've taken Phil's explanation and augmented it with my own understanding:

  1. User is presented with OpenID login form by the Consumer
  2. User responds with the URL that represents their OpenID (for example “FrancisShanahan.myIDServer.com”). Now the Consumer needs to determine if I actually “own” the URL I've specified.
  3. Consumer canonicalizes the OpenID URL and uses the canonical version to request (GET) a document from the Identity Server.
  4. Identity Server returns the HTML document named by the OpenID URL
  5. Consumer inspects the HTML document header for tags with the attribute rel set to openid.server and, optionally, openid.delegate. The Consumer uses the values in these tags to construct a URL with mode checkid_setup for the Identity Server and redirects the User Agent.  {fs: Said differently, the consumer directs the user to login at their ID server.}   This checkid_setup URL encodes, among other things, a URL to return to in case of success and one to return to in the case of failure or cancellation of the request
  6. The OpenID Server returns a login screen.
  7. User sends (POST) a login ID and password to OpenID Server. {fs: I assume you can authenticate how ever your OpenID server likes}
  8. OpenID Server returns a trust form asking the User if they want to trust Consumer (identified by URL) with their Identity
  9. User POSTs response to OpenID Server.
  10. User is redirected to either the success URL or the failure URL returned in (5) depending on the User response
  11. Consumer returns appropriate page to User depending on the action encoded in the URL in (10)

“Ok, makes sense but there's an obvious problem as Kim Cameron correctly points out in this post [LINK].

“If you assume the Consumer is evil, they can take the openID URL from step 2 and instead of directing the user to that legitimate URL, they can substitute it with their own faker site. This site'll look EXACTLY like the one the user's expecting. The user unwittingly enters their credentials and the scenario continues as normal. The user's never aware that they were phished.

“Clearly there's a piece missing that Kim claims can be provided by the CardSpace ID selector. By integrating OpenID with CardSpace you can avoid malicious redirections and phishing in the protocol. But then what've you actually achieved? You've just re-invented the WS-* wheel all over again using redirects and a browser? So what's the point?

“I don't get it but this is dark mojo and I'm probably missing something somewhere.”

Let me clarify what really happens.  Let's go back to step (2) above.  We know Francis by his blog URL – http://www.francisshanahan.com.  So if he was going to leave comments on my blog, he would most likely use his own blog URL as his OpenID.

Note that his blog URL isn't an identity server.  So in step (3), the consumer doesn't contact an identity server – it requests and gets Francis’ actual web page (or, at least, its header).  As explained in step (5), the header contains a “link” element telling the consumer who to trust as the identity provider for this page.

Now, in steps (5) through (10), the user is redirected to the identity server, enters his credentials, and picks up a coupon that he gives back to the consumer after another redirect.  Behind the scenes, the consumer then sends the coupon back to the identity provider (using a backchannel) to see if it is valid. (There is a potential optimization that can be used here involving exchange of a key – but it is only an optimization).

So let's think about this.  Where is the root of trust?  In conventional systems like PKI or SAML or Kerberos, the root of trust is the identity provider.  I trust the identity provider to say something about the subject.  How do I know I'm hearing from the legitimate identity provider?  I have some kind of cryptographic key.  The relevant key distribution has a cost – such as that involved in obtaining or issuing public key certificates, or registering with a Key Distribution Center.

But in OpenID, the root of trust is the OpenID URL itself.  What you see is what you get.  In the example above, I trust Francis’ web page since it represents his thinking and is under his control.  His web page delegates to his OpenID identity provider (OP) through the link mechanism in (5).  Because of that, I trust his identity provider to speak on behalf of his web page.  How do I know I am looking at his web page or talking to his identity provider?  By calling them up on DNS.

I'm delving into the details here because I think this is what gives OpenID its legs.  It is as strong, and as weak, as DNS.  In other words, it is great for transactions that won't attract criminal attack, and terrible for those that will.

This now brings us face to face with the essence of the metasystem idea.  We don't live in a one-size-fits-all world.  Identity involves different – and even contradictory – use cases.  Rather than some monolithic answer, we need a metasystem in which the cost (in complexity or money) of using identity is proportional to the value of the asset being protected.  OpenID cannot replace crypto-based approaches in which there are trusted authorities rather than trusted web pages.  But it can add a whole new dimension, and bring the “long tail” of web sites into the identity fabric.

The way I see it, there is a spectrum with DNS-based technology at one end and hardware-backed crypto technology at the other.  If we can get this continuum structured into a metasystem, the dichotomy between RESTful and Web Services approaches can be changed from a religious war to simple selection of the right tool for the right task.  That's why I want to see OpenID as an integral part of a metasystem providing a common experience while respecting the economics of identity.

This having been said, Francis is right for asking whether we've “just re-invented the WS-* wheel all over again using redirects and a browser?”.  While I think it is known I'm a strong supporter of SAML as a step forward for identity, I've been an equally vocal advocate of separating communications protocol, trust, and token payloads.  OpenID has a different token payload and trust system than SAML, but if the three axes had been properly disentangled, you could imagine OpenID as a very simple SAML profile.  Because of the entanglement, that can't be the case.

WS-Federation (possibly misnamed…) doesn't have this problem.  It can carry any token, and use any trust framework.  OpenID would work inside the WS-Federation protocol patterns, and would be able to retain its payload and trust structure.  So could SAML for that matter.  So there is the “theoretical possibility” of merging all these things.  Will it happen?  Someone would have to pass out large quantities of pain killers, but there is a possible future in which, over time, they converge.