Category: Identity Metasystem

Microsoft's Open Specification Promise

Today marks a major milestone for Mike Jones and myself. 

Microsoft announced a new initiative that I hope goes a long way towards making life easier for all of us working together on identity cross-industry.

It's called the Open Specification Promise (OSP).  The goal was to find the simplest, clearest way of assuring that the broadest possible audience of developers could implement specifications without worrying about intellectual property issues – in other words a simplified method of sharing “technical assets”.  It's still a legal document, although a very simple one, so adjust your spectacles:

Microsoft Open Specification Promise

Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification (“Covered Implementation”), subject to the following.  This is a personal promise directly from Microsoft to you, and you acknowledge as a condition of benefiting from it that no Microsoft rights are received from suppliers, distributors, or otherwise in connection with this promise.  If you file, maintain or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of such Covered Specification, then this personal promise does not apply with respect to any Covered Implementation of the same Covered Specification made or used by you.  To clarify, “Microsoft Necessary Claims” are those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification.  “Covered Specifications” are listed below.

This promise is not an assurance either (i) that any of Microsoft’s issued patent claims covers a Covered Implementation or are enforceable or (ii) that a Covered Implementation would not infringe patents or other intellectual property rights of any third party.  No other rights except those expressly stated in this promise shall be deemed granted, waived or received by implication, exhaustion, estoppel, or otherwise.

Covered Specifications (the promise applies individually to each of these specifications)

Web Services  This promise applies to all existing versions of the following specifications.  Many of these specifications are currently undergoing further standardization in certain standards organizations.  To the extent that Microsoft is participating in those efforts, and this promise will apply to the specifications that result from those activities (as well as the existing versions).
WS-Addressing
WS-AtomicTransaction
WS-BusinessActivity    
WS-Coordination
WS-Discovery
WSDL
WSDL 1.1 Binding Extension for SOAP 1.2
WS-Enumeration
WS-Eventing
WS-Federation
WS-Federation Active Requestor Profile
WS-Federation Passive Requestor Profile
WS-Management
WS-Management Catalog    
WS-MetadataExchange    
WS-Policy
WS-PolicyAttachment
WS-ReliableMessaging    
WS-RM Policy
Remote Shell Web Services Protocol
WS-SecureConversation
WS-Security: Kerberos Binding
WS-Security: SOAP Message Security
WS-Security: UsernameToken Profile
WS-Security: X.509 Certificate Token Profile
WS-SecurityPolicy
SOAP
SOAP 1.1 Binding for MTOM 1.0    
SOAP MTOM / XOP
SOAP-over-UDP
WS-Transfer
WS-Trust
WS-I Basic Profile
Web Single Sign-On Interoperability Profile
Web Single Sign-On Metadata Exchange Protocol

Note that you don't have to “do anything” to benefit from the promise.  You don't need to sign a license or communicate anything to anyone.  Just implement.  Further, you don't need to mention or credit Microsoft.  And you don't need to worry about encumbering people who use or redistribute or elaborate on your code – they are covered by the same promise. 

The promise is the result of a lot of dialog between our lawyers and many others in the industry.  Sometimes we developers wished progress could have been faster, but these are really complicated issues.  How long does it take to write code?  As long as it takes.  And I think the same notion applies to negotiations of this kind – unless one party arrives at the table with some pre-determined and intransigent proposal.  People on all sides of this discussion had legitimate concerns, and eventually we worked out ways to mitigate those concerns.  I thank everyone for their contribution. 

How have people from various communities reacted to the final proposal?

Lawrence Rosen, the lecturer at Stanford and author of, “Open Source Licensing: Software Freedom and Intellectual Property Law”, said:

“I see Microsoft’s introduction of the OSP as a good step by Microsoft to further enable collaboration between software vendors and the open source community.  This OSP enables the open source community to implement these standard specifications without having to pay any royalties to Microsoft or sign a license agreement. I'm pleased that this OSP is compatible with free and open source licenses.” 

Mark Webbink, Deputy General Counsel at Red Hat, said:

“Red Hat believes that the text of the OSP gives sufficient flexibility to implement the listed specifications in software licensed under free and open source licenses.  We commend Microsoft’s efforts to reach out to representatives from the open source community and solicit their feedback on this text, and Microsoft's willingness to make modifications in response to our comments.”

And from RL “Bob” Morgan, Chair of the Middleware Architeture Committee for Education, and a major force behind Shibboleth:

The Microsoft Open Specification Promise is a very positive development.
In the university and open source communities, we need to know that we can implement specifications freely.  This promise will make it easier for us to implement Web Services protocols and information cards and for them to be used in our communities.

So there it is folks.  I'm impressed that such a short document embodies so much work and progress.

Upcoming DIDW

I hope everyone's going to Digital ID World (DIDW) next week. We'll start on Monday with an Identity Open Space Unconference (don't worry, Virgos, they're unstructured, but not without shape and self-revealing purpose). Once this gives rise to the main event, there are a number of sessions that look fascinating for identity afficionados – like “What Do the Internet's Largest Sites Think About Identity?”, a panel moderated by Dan Farber and featuring representatives of the large sites and a new presentation by Dick Hardt. There will also be an OSIS meeting – and of course, the endless hallway conversation.

I'm pairing up with Patrick Harding (from Ping Identity) on a Wednesday session called “Understanding InfoCards in an Enterprise Setting“. It will include a demo that I think will really help show the concrete benefits of InfoCards inside the enterprise. What can you expect? 

First, you'll see the latest version of Ping's InfoCard server, now featuring both Managed IdP as well as Service Provider capabilities. Ping's goal is to show how to seamlessly chain passive and active federation – allowing for on-the-fly privacy context switching.  They'll use real-world use-cases where passive federation gives way to active and vice-versa.

According to Andre Durand, Ping Identity's CEO:

“The Digital ID World demo will show two scenarios to depict how passive federation (via SAML 2.0 Web SSO Profiles or WS-Federation) and active federation (via CardSpace) can both play a role in enabling a seamless user experience for accessing outsourced applications. The plan is to demonstrate how passive and active federation work together to enable a myriad of different business use cases when chained together in different situations

“Scenario 1:

“An enterprise employee leverages her internal employee portal to access applications that are hosted externally. In the first case we show how SAML 2.0 Web SSO (passive federation) is used to enable seamless access into the SF.com web site. The user accepts this as part of her employment contract – the employer has deemed that the use of SF.com is critical to their business and they want no friction for their sales force in entering information for forecasting purposes.

“In the second case we'll show how CardSpace is used to ‘optionally’ enable seamless access into the employees Employee Benefits web site. As the Employee Benefits web site is made up of a mixture of personal and corporate information (i.e. 401k, health and payroll) the employee is given the choice of whether to enable SSO via the use of CardSpace. The Employee Benefits web site is enabled with CardSpace. After the user clicks on the ‘Benefits’ link in their corporate portal, she is prompted with different Cards (Employer and Benefits) which she can then choose between for accessing the Benefits web site. If she chooses ‘Employer’ then she will be enabled with SSO from the Corporate Portal in future interactions.”

By the way, Andre, please tell me there's some way for her to change her mind later!

“Scenario 2:

“An enterprise employee is traveling and loses her cell phone. She uses her laptop to access her corporate cell phone provider in an effort to have the phone replaced immediately. The employee would normally access this web site via SSO from her corporate portal. The cell phone provider web site is enabled with Card Space to simplify the IdP discovery and selection process. The employee is prompted to use her Employer card to authenticate to her employer's authentication service. The cell phone provider web site leverages CardSpace to handle IdP Selection rather than having to discover this themselves. Once the user has authenticated to her employer the returned security token contains the relevant information to service the employee's request for a new cell phone.”

It all sounds very interesting – amongst the first examples of what it means to have a full palette of identity options.  Ping is emblematic of an emerging ecology – many of us, across the industry, moving us towards the Identity Big Bang.

Doc Searls will be doing the closing Keynote.  I'm really looking forward to that and to seeing you in Santa Clara.

The virtualization of crime

I love this piece by Scott Adams:

Imagine.  The Internet has no way of knowing who you are dealing with.  What environment could be more convenient for the criminally inclined?

Since starting to work on the Identity Metasystem I've learned more and more about the hoists being pulled off in the context of virtual reality.  Over time, we have seen the attacks become more professionalized, and ultimately linked to well organized international syndicates.  Part of the basic equation is that the international nature of virtual reality makes it especially hard to deal with the type of organization that is emerging at the boundary of its interface with the brick and mortar world.

But recently, we've seen more highly focused attacks that are essentially artisinal.  It seems to be a case of “think globally, act locally.”  Some of the schemes put in place depend on intimate knowledge of the workings of specific sites, and even specific communities and indvidiuals.  This is no longer generic targeting.  It's highly individualized, the work of community professionals of a special kind, who may draw upon internationally organized resources as necessary.

And of course this all makes sense.  Computerization has progressively worked its way through the various professions and industry sectors and nooks and crannies of our society, and we've reached the point that a growing number of criminals are no more likely to function without computers than are accountants (not to cast judgement on whether some accountants are or are not ciminals…)

As the level of familiarity with technology grows and increasingly wider swaths of the population become aware of the opportunities that await us in virtual reality, it is obvious that more and more criminals will find their place there. 

I walked into my local Office Depot a few days ago and amazingly, almost all the stationary goods and high class pens and filing contraptions and things that have always made such places interesting, had basically disappeared into a distant corner, while the whole center of the store consisted of computers, printers, electronic cash registers and cameras.  A further indication of the growing virtualization of which cyber criminalization is just a natural a part.

But to keep any balance at all, we really do need to fix the fundamental architectural problem of the internet: having a way that we can, when we want to, be sure who we are connecting with.

In other words, we need to put in place an Identity Metasystem.

Phil Becker on Identity's First Big War: a history lesson

Phil Becker is getting us ready for the DIDW in Santa Clara this September 11:

It's been half a decade since the first, and biggest, “identity war” ended. It is worth revisiting what happened (and what was learned) in light of how identity technology is gaining traction and beginning to face related challenges that could lead to similar issues arising again.

History has a way of looking inevitable in hindsight, like it really couldn't have turned out any different than it did. Those who lost can easily seem like they were just shortsighted, venal or stupid while others look unnaturally aware and smart. The truth is usually somewhat different, and if we are to benefit fully from the lessons of history, we must review it as objectively as possible.

“You could start a consultancy with what you learn at this conference.” -Katarina Kreutzfeldt, Managing Director, KOGit, GMBH

Before I begin, however, I want to remind all my readers our annual Digital ID World conference is just two weeks from Monday. It's August, and easy to think that it's further away than that. I wouldn't want you to miss out because you didn't get that two week advance air fare discount, or plan time to attend until too late. This year's conference is shaping up to be our best ever on several fronts. Check out the conference web site at http://conference.digitalidworld.com/2006 and when you register be sure you don't forget the $200 off discount code in the ad above.

I'm also doing a webinar next Thursday, August 31, exploring the convergence of physical and logical identity through deployment experience. As you can see from our conference schedule, I believe that deployment experience is the best way to understand identity technology. This webinar looks at this subject through a deployment experience, a subject that has been mostly talk but which is now becoming reality . You can register for that free webinar at: http://www.actividentity.com/didwebinar

The first identity war didn't start out as a war at all. It began when Microsoft, who had fully committed to web services long before anyone else, realized that an internet scale authentication infrastructure was required before those services could truly gain the traction they had envisioned.

As a company, Microsoft tends to look at computing problems through the lens of the user experience. In the case of the internet, this led them to see (earlier than most) the tremendous friction that requiring a user to log in to each web site with separate credentials created. In 1999, they began to address that problem with Passport, which they felt that they could grow to become an internet scale authentication system.

Here is the Schedule and here are the Exhibitors.

Brian Arbogast, then VP of .NET Core Services, summarized this in 2001 when he said, “Back in 1999, Microsoft looked at the Internet landscape. More and more, when people went to Web sites — to shop, retrieve news stories, download software or participate in chats — they had to log in, giving their name, password and, often, additional information. There are so many user names and passwords that people have to remember today that it can create a pretty frustrating experience; in fact, most people write that information down on paper — which is not a safe or secure way to store this information. Authentication services like Microsoft Passport are designed to help transform today's Internet and computing experience by enabling single sign-in to multiple sites and services with one secure password.”

Note how all of this is framed from the perspective of the user experience, with no recognition of how centralizing authentication might create side effects that people would be unhappy with. It is this framing of the problem that led Microsoft to miss those implications that would ultimately launch the first identity war. This view also led most of those involved in identity management at that time to view it narrowly as an exercise to achieve single sign-on.

In March of 2001, Microsoft took Passport to the next level, announcing Hailstorm, a way to use web services to create a unified identity experience on the internet. Announcing Hailstorm on March 19, 2001, Bill Gates said, “The .NET vision encompasses the idea of having your information wherever you want to go. This includes the future cell phones, your TV set, your tablet form factor PC, your desktop PC. Wherever you are, and whatever role you're in, whether you're working, you're acting as a family member, you're acting on behalf of some other group you belong to, your information will be there available in the context that's most appropriate for what you're trying to get done.”

Examining that sentence reveals that on one level, Microsoft understood precisely where the internet was going and what identity would have to provide to get it there. It is a classic example of how visionaries can see something so clearly that they miss (or drastically underestimate) the implications. Microsoft felt that the internet was just one centralized authentication system away from its “big bang” of value creation, and missed the devil that lurked in the details.

On stage that March day was Ray Ozzie, the person that Bill Gates is now turning Microsoft strategy over to. At that time Ozzie was CEO of Groove Systems, and said “what it's really about is enabling individuals out on the Internet who need to work together the ability very quickly, very spontaneously, to get together, to share information, to interact with one another directly over the Net — even across firewall boundaries. We believe that the services that are inherent to ‘HailStorm’ provide for a much richer user experience, and in general put the user in control of information that formerly has been in the control of apps of various types.”

Again, you see the focus on enabling a user experience, including the need for the user to feel in control of the identity transactions and information. At the same time, there was little or no understanding of the implications of the architecture chosen for the identity infrastructure. But those implications weren't missed by the public and the real “storm” was one of fear that Passport/Hailstorm just might work, with the result that Microsoft would end up controlling the identity information of the internet. The rumblings that would lead to the first identity war had begun.

In 2001, enterprise was also realizing it needed a way to unify its authentication infrastructures. It was being seen that directories just couldn't grow big enough to centralize all authentication without becoming projects that cost far more than they were worth, and that the cultural impact of centralizing all of the processes behind managing the data they held was unreasonable. In 2001, this pressure led to the SAML protocol efforts. These efforts to create a standard way to share authentication information across domains advanced very quickly and several demonstration projects with the proposed protocol occurred.

One of the first articles I wrote for the Digital ID World web site in 2002 was:  The Digital ID Wars Intensify…

In that article I wrote “last September marked the real beginning of the Single Sign On wars, and this is currently the hottest battlefield in the Digital Identity struggle (although there are many other battlefields that will show their faces as the struggle continues.)” The reference was to the formation of the Liberty Alliance in September 2001. That group formed specifically to find an alternative way to achieve single sign on without creating a centralized identity system. Liberty proceeded to build on the foundation of SAML, create their ID-FF protocol, and release it by July 2002. The word federation entered the identity conversation and the concept of networking decentralized identity domains using standardized protocols began gaining acceptance.

Under the pressure of the first identity war, Liberty Alliance did its job so rapidly and well that it has largely been forgotten how significant it was. The ID-FF protocol was incorporated into SAML 2.0, and the sub-battle over how federation would occur has largely been put to rest. The first identity war officially ended when Microsoft quietly shelved the renamed Hailstorm project, MyServices.

This first identity war deeply affected how identity technology has evolved since then. It is useful to revisit it because several large internet sites are again in the midst of deciding whether their identity systems should be open or closed, and how they should be architected. If they don't pay attention to what Microsoft learned in the first identity war, we can expect to see some bad experiences again.

Following the first identity war, Microsoft, deeply impacted by the experience, came to realize that *how* identity was implemented had far more implications than they initially imagined. In response they put more effort into the WS-* protocols to create far richer capabilities than just single sign on and allow greater flexibility in how those capabilities could be architected. In recent years, Kim Cameron has worked on defining a WS-* identity meta-system that allows interoperability between different identity infrastructures while creating an identity based user experience to be part of the forthcoming Microsoft CardSpace in Vista. Nearly all identity management systems today acknowledge that decentralization will grow, that federation is a required mode, and several competing user-centric identity architectures are vying for acceptance.

There are many more lessons to be drawn from the first identity war, among them being that understanding what is needed functionally is quite different from understanding how it should be provided or the implications of different approaches on how users will accept or reject the result. Identity is complex because it carries tremendous power — power to accomplish the desired goals, and power to create unanticipated side effects.

This is why gaining a good identity-centric perspective of computing is so essential to success in IT today. It is also why you are seeing identity unifying technology from the network layers through the application layers. Without an identity perspective, IT security and infrastructure tends to take on a “Whack-a-Mole” nature where the solution to one problem only seems to create two more problems.

I'm sure it will come as no surprise that I would tell you that the *very best* way to gain such a deep identity-centric perspective is by attending the Digital ID World conference. No one who attends will leave without gaining a deeper understanding and broader perspective of the place of identity in computing, how technology is evolving, the best practices that lead to success, and how each identity technology applies to the overall set of tasks at hand based on real world experience.

Identity is a Whack-a-Mole phenomenon?  Top that, Thurcydides and Emerson!  Meanwhile, I hope to see everyone, especially Phil, at DIDW in Santa Clara.

Radia Perlman on PBE

The ever-interesting James McGovern posted about Encryption Based Encryption a while ago, wondering if Microsoft and Sun might add it to their product suites.

I was so busy travelling that I got swept away by other issues, but Sun's Pat Patterson persisted and recently posted a cogent note by Radia Perlman, one of his colleagues, which I thought hit a lot of the issues:

Identity based encryption.
Sigh.

This is something that some people in the research community have gotten all excited about, and I really think there's nothing there. It might be cute math, and even a cute concept. The hype is that it makes “all the problems of PKI go away”.

The basic idea is that you can use your name as your public key. The private key is derived from the public key based on a domain secret, known to a special node called the PKG (private key generator), which is like a KDC, or an NT domain controller.

Some of the problems I see with it:

a) public key stuff is so nice because nobody needs to know your secret, and the trusted party (the CA) need not be online. The PKG obviously needs to be online, and knows everyone's secrets

b) If Alice is in a different trust domain than Bob, she has to somehow securely find out Bob's PKG's public parameters (which enable her to turn Bob's name into a public key IN THAT DOMAIN).

c) Bob has to somehow authenticate to the PKG to get his own private key

d) There is no good answer to revocation, in case someone steals Bob's private key

e) There is no good answer to revocation, in case someone steals the PKG's domain secret.

I've seen hype slides about identity based encryption saying “which identity is easier to remember?

In PKI: 237490798271278094178034612638947182748901728394078971890468193707
In IBE: radia.perlman@sun.com

This is such ill-conceived hype. In PKI no human needs to see an RSA key. The RSA key is not your identity. Your identity is still something like radia.perlman@sun.com

So, it looks like IBE gives with one hand (sender can create a public key without the recipient's involvement) but takes much more away with the other (key secrecy, PKG has to be online, revocation issues). I guess there is no such thing as a free lunch…

Let me put the same points just a bit differently. 

IBE is very interesting if you think everyone in the world can trust a single authority to hold everyone's secrets. 

OK, now let's move on.

When you do have multiple authorities, you need a way to discover those, so you need a secure email-to-authority mapping and lookup.  Yikes.  The only way to do that which is simpler than public key itself, is to use mail domains as the authority boundary combined with some kind of secure DNS.

But in that case, your mail server can decrypt anything you receive, so it's no better than a conventional edge to edge encryption scheme (e.g. where mail from me to Pat gets encrypted leaving the Microsoft mail system and then decrypted when entering the Sun mail system). 

Edge encryption is pretty well what everyone's building anyway, isn't it?  So what's the role for PBE?

My vision is that one day, Information Cards will be used to convey the information needed to do real end-to-end encryption using asymmetric keys – without the current difficulties of key distribution.  This said, signing interests me a lot more than end-to-end encryption in the short term.

More about this some other day.

One more Paul on the federation and user centrism demo

Incredibly, I just came across a comment by another Paul.  I guess I spoke to soon about my success communicating with Pauls, since Paul Madsen seems to be a doubting Thomas – which in this case adds some variety, so I'm pleased to see it: 

Kim Cameron has a screen cap movie of a demo created by Ping ID.

Kim asserts that the demo illustrates (paraphrasing) “user-centric technologies like Information Cards are not in any way counterposed to federation technologies”.

I completely agree with the sentiment, but question whether the scenario portrayed by the demo actually demonstrates it.

In the demo, a user authenticates to a portal using CardSpace. Once authenticated, they are presented with a list of applications available to them for which SSO is possible (this presumably dependent n which I-Card they selected). For Kim, the user-centric piece (CardSpace) somehow ends at the portal, and from then on federation (SAML etc) takes over.

So, user-centric and federated technologies are shown as working together – but not at the same time. The user-centric piece hands off to the the federation piece. Federation is presented as a lower-level piece of infrastructure (which it can be) that doesn't seem to touch the user.

Hmmm.  What I'm really saying is that in the demo being shown, the user has a relationship with the portal, which offers a nice array of services.  So in terms of technology, the identity relationship is user-to-portal, not user-to-individual-service.  One could also say the “services” can be “outsourced” by the portal – and are dealing with users as proxies for the portal.  Once the user has entered the portal, there is a “magic carpet” that takes her from service to service. 

But note:  The portal could also take the user to a service with which she would have a completely independent identity relationship.  In this case, the user would again see the Cardspace interface and select her identity through it.

Paul (three) continues:

This interpretation is reinforced by Kim:

To my way of thinking, you have two more or less orthogonal technology efforts – that oriented around federation issues, and that oriented around the user’s experience.

This ignores the possibility for SAML-based technologies to provide the very same user-experience (i.e. real-time identity sharing control, IDP selection etc) that I-Cards enables. Is SAML's Enhanced Client or Proxy (ECP), as it enables similar control mechanisms, then user-centric?

Probably not, as Kim also hilites the common UI of Cardspace and its relevance

Should my experience therefore be totally discontinuous as I move from one portal to another, being organized by the portal rather than by my own system

Exactly.  Maybe I was more successful at communicating with Paul Masden than I initially thought – I think he sees my point. 

The portal just cannot know all my identity relationships (unless I were to find myself in some hiddeous “total environment” where everyone knows everything). 

So the portal, simply by virtue of the role it plays in the system, cannot organize my perception and use of identities across the board.  This is one of the key points I'm trying to make, and explains why you need user centric technologies and they are orthogonal to federation technologies even though in both cases you have claims being asserted and relied upon.

Finally, Paul asks:

If the phone manufacturers (or those of set top boxes) were to come together and agree on user-interface standards – would that be user-centric?

If they allow users and relying parties to represent and select between their multiple identities then yes, sure, exactly.  But it's not just a question of user interface (UI), it's a question of capabilities that are represented through UI.  I don't know why people reduce this to UI.

The fact that phones could deliver these new capabilities is why it makes perfect sense to put Information Cards on phones, music players, and other devices.  I first proposed putting them on computers because I happen to work in that industry.  But I know a lot of people who are interested in getting the same identity relationships to appear across all kinds of devices.

Demo gets good reviews

Paul Toal over at Identity, Security and Me posted this to encourage you to check out the demo I put up recently.  (Just in case any of you are busy, it's only 3 minutes long!)

Picture of Britian's Paul ToalKim Cameron has posted a really good video here explaining how user-centric identity and federation can work together. His blog and associated demonstration is shown using Microsoft CardSpace and Ping Federate from Ping Identity.

I have worked with Ping Identity for some time and was happy with the product and how it, and federation works generally. However, like Paul Squires here, I was struggling to see how it fitted within a user-centric architecture. Whilst I saw the two as complimentary, I didn’t see the link.

This video has clarified this for me and shown that there is a clear interaction between the two.

As usual Kim, thanks for a great demo! If you haven’t seem the demo yet, you HAVE to view it.

Then, following Paul Toal's link to Paul Squires at Here, Now, I came across his additional comment:

This [demo…] is well worth seeing for anyone with an interest in where digital identity is going. The demo itself shows cardspace (if there’s anyone who hasn’t seen it yet!) along with interoperability between a number of applications. The guys at Ping have done a great job with this and I’d hope this brings together these various strands of identity management (it’s certainly helped me, not least from an architectural point of view). Things are starting to look very exciting!

Update: Never one to miss out on a bit of vanity, the second open tab in the browser during the demo looks very familiar!

Gee, I'm on a roll.  Just like my horoscope said, I seem to be communicating well with people named Paul.

As for Paul two's “update”, looking closely I also can see that I had been reading one of his posts the day I captured the demo.  Just think.  Some people are worried there will be no fingerprints in the digital world.  It ain't true.

Ping's Identity Metasystem demo

Ping Federate with InfoCardEarlier this summer, just before the Burton Group Catalyst conference, Andre Durand and Ashish Jain of Ping Identity really surprised me with a lovely Identity Metasystem demo that combined use of Information Cards and federation technology.

I don't think anything I've seen demonstrates more concretely why “federation” and “user centricity” are different and yet complementary.

The demo is built around Ping Federate, which speaks four protocols for transporting SAML tokens around:  SAML 1.0, SAML 1.1, SAML 2.0, and WS-Federation.  Since it speaks all these federation dialects, it can talk to any federating system regardless of its dialect – for example WebSphere, Presentation Server, Windows 2003 and .NET, Tomcat, SAP, Web Logic, Salesforce.com, SiteMinder, CoreID, etc.

But even better, the user has a rational experience as well – just seeing this circle of trust as being accessed through an Information Card.

To play the demo:

Use Windows Media Player.  (You will need the Techsmith Screen Capture Codec (TSCC).  If your system complains it doesn't have the right codec, pick it up here.)  If you want to watch this and don't have any way to see it with Windows Media Player, let me know and I'll make a version for Quicktime.

The demo lasts 3 minutes and takes up 4 megs.  Download here.

As always I sound a little earnest as I rush you towards the finale.  But I think you'll like what these guys have done anyway.

Federation and user-centricity

Conor Cahill picked up on a discussion I recently relayed to identityblog readers – part of an ongoing dialog between Brett McDowell and Dick Hardt.  Conor says:

I think the issue causing the disagreements here is the interpretation of the term “federation” when discussed in an identity context.

Certainly federation can mean groups of businesses working together and this is the traditional meaning of the term in the business community. This meaning would fit with Kim's statement above.

However, in an identity context (as in “identity federation” — the stuff the Liberty Alliance has been working on since its founding) the term federation was used to describe the sharing of identity information from party A to party B. Party A is usually some party representing the user (acting on the user's behalf) such as an Identity Provider or an Attribute Provider. There is nothing that says whether Party A is an entity operated by the user or by some 3rd party.

In fact, in the Cardspace solution, the process of sending data through an Infocard instance to a relying party would be considered taking place under identity federation, whether the infocard instance was rooted in a local data source or a remote data source.

Ultimately, I would say that federation can be used in both user centric and non-user centric solutions. Federation is a technology/protocol and user centric is an implementation philosophy. When designing a user centric solution, you almost always have to include some form of identity federation, but give the user great control over its use. The converse is not required to be true (although I wouldn't object to it if it was true in any environments in which I played).

I like a lot of Conor's thinking.  I agree that use of a managed card in Cardspace should be considered a form of “federation” between the relying party and the identity provider – federation approved by the user.

But I don't quite buy that “federation is a technology/protocol” wherease “user-centric is an implementation philosophy”.  I doesn't compute given a great deal of work I've been doing lately.

It's clear to me that good “user-centric” experience isn't just an automatic or natural by-product of some other “technology/protocol”.  In fact, it requires just as much study, just as much thought, just as much coding, and just as much experimentation as protocols do – probably more. 

What I'm try to say here is that it requires technology.   In the past we've had a lot of technology that failed miserably at organizing, integrating and rationalizing the user's experience.  I've been working on software that I think does a lot better job at this.  Why wouldn't Conor call that a technology?

To my way of thinking, you have two more or less orthogonal technology efforts – that oriented around federation issues, and that oriented around the user's experience.

As a user, when I go from portal to portal to portal, it's likely they will have relationships with different identity providers.  Should my experience therefore be totally discontinuous as I move from one portal to another, being organized by the portal rather than by my own system?

In Cardspace (and with Information Cards running on other devices and platforms) we postulate that the user can benefit from computerization of his or her own identity experience – just as enterprises benefit from computerization of theirs.

Through Information Cards users can benefit, to the extent the technology is adopted, from the same well-understood experience as they move between unrelated portals which do not share identity relationships.   

I see Cardspace as providing a palette of identity relationships (Information Cards) that work for me as a user and make sense from my point of view as an individual with a complicated life. 

I think Dick Hardt, and others like Paul Trevithick at Higgins, share a number of the same notions as I do, though each of us is concentrating on different aspects of the problem.

So that's why I'm saying that there are two legitimate technology areas, orthogonal in the sense that you can have either one without the other, but synergistic in that together you get a number of critical new scenarios.

To make this more concrete, my next post will be  a demo of Andre Durand and Ashish Jain's work in showing how this can look in practice.