The Clay Feet of Giants?

Over at Craig Burton, the marketing guru who put Netware on the map and later formed the Burton Group with Jamie Lewis lets loose with a passionate fury that couldn&#39t care less about who has deployed what:

It’s been a week since Microsoft announced that it was never going to release the next version of CardSpace. The laughable part of the announcement is the title “Beyond Windows CardSpace” which would leave you to believe that Microsoft has somehow come up with a better architecture.

In fact Microsoft announced its discontinued development of CardSpace with absolutely no alternative.

Just further evidence of just how irrelevant Microsoft has become.

The news that Microsoft had abandoned CardSpace development is not news to those of us who watch this space, Microsoft hasn’t done Jack with CardSpace for over two years.

It’s just that for some reason Microsoft PR decided to announce the matter. Probably so the U-Prove group could get more press.

Well, that&#39s a bit harsh. Identity selectors like CardSpace only make sense in the context of the other components of the Identity Metasystem – and Microsoft has done a lot over the last two years to deliver those components to customers who are doing successful deployments on a massive scale all over the world.  I don&#39t think that&#39s irrelevant, Craig.

Beyond that, I think Craig should look more closely at what the U-Prove agent actually does (I&#39ll help by putting up a video). As I said here, the U-Prove agent doesn&#39t do what CardSpace did. And the problems CardSpace addressed DO remain tremendously important.  But while more tightly scoped, for the crucial scenario of sensitive claims that are privacy protected the U-Prove agent does go beyond CardSpace.  Further, protecting privacy within the Identity Metasystem will turn out, historically, to be absolutely relevant.  So let&#39s not hit on U-Prove.

Instead, let&#39s tune in to Craig&#39s “Little History” of the Identity Metasystem:

In early 2006, Kim Cameron rolled out the Laws of Identity in his blog. Over next few months as he rolled out each law, the impact of this powerful vision culminating in the release of the CardSpace architecture and Microsoft’s licensing policy rocked the identity community.

Two years earlier Microsoft was handed its head when it tried to shove the Passport identity initiative down our throats.

Kim Cameron turned around and proposed and delivered an Identity Metasystem—based on CardSpace—that has no peer. Thus the Identity Metasystem is the industry initiative to create open selector-based digital identity framework. CardSpace is Microsoft’s instantiation of that Metasystem. The Pamela Project, XMLDAP, Higgins Project, the Bandit Project, and openinfocard are all instantiations in various stages of single and multiple vendor versions of the Identity Metasystem.

Let me clear. The Identity Metasystem has no peer.

Anything less than a open identity selector system for claims-based digital identity is simply a step backwards from the Identity Metasystem.

Thus SAML, OpenID, OAuth, Facebook Connect and so on are useful, but are giant steps back in time and design when compared to the Identity Metasystem.

I agree that the Identity Metasystem is as important as Craig describes it, and that to reach its potential it MUST have user agents. I further agree that the identity selector is the key component for making the system user centric. But I also think adoption is, ah, essential… We need to work out a kink or two or three. This is a hard problem and what we&#39ve done so far hasn&#39t worked.

Be this as it may, back at Craig&#39s site he marches on in rare form, dissecting Vendor Speak as he goes.  Mustering more than a few thrusts and parries (I have elided the juicier ones), he concludes:

This means there is an opening for someone or some group with a bit of vision and leadership to take up the task…

But mark my words, we WILL have a selector-based identity layer for the Internet in the future. All Internet devices will have a selector or a selector proxy for digital identity purposes.

I&#39m glad to finally see this reference to actual adoption, and now am just waiting for more discussion about how we could actually evolve our proposals to get this to happen.

 

A “change in user behavior”

Farhang Kassaei is lead architect for platform and systems at eBay Inc and blogs at Software For All Seasons.  He makes a great point about one key factor that blocked CardSpace deployment:

Having worked on a authentication concept with MSFT for eBay sellers, I had mixed feelings about this [Microsoft&#39s decision not to ship CardSpace 2.0 – Kim]. On one hand I was on the record not supporting the use of CardSpace for eBay sellers (or buyer). On the other hand I am concerned that technical community discounts the significance of Claim Based identity altogether and concludes that “FaceBook Conncet” is all we&#39ll ever need.

There is a good reflection (from an insider&#39s point of view) on Card Space here. (courtesy Gunnar Peterson)   My personal view (and the reason I didn&#39t support the adoption of Card Space at eBay) though centers around the challenges of “Change of Behavior” required by Card Space.

Basically, CardSpace failed b/c it requied uses to change their behavior. See, the “User name and password” protocol (a simple challenge and response) IS a protocol, one where a human being (a normal user) is a participant in. It has taken about 20-30 years (depending on how you count) to train users what to do when they see a “login panel” , the “login panel” contract is so widely understood that despite all of its short coming is the most viable remote authentication protocol we have today. It is flawed, it is costly, it is not secure, but it is a widely understood by users on the other end of the protocol. CardSpace, despite all its advantages, was not understood, would (and did) make people confused, they did not know what to do when the CardSpace screen popped up … a technology whose adoption depends on change of a strongly learned behavior is unlikely to succeed (or at least I didn&#39t think eBay sellers – not the early adopters of technology – would learn and accept it).

It also didn&#39t help that a lot of browsers didn&#39t support it (installing a plug-in does not count), and the fact that developers didn&#39t know how to issue cards (or validate, update or revoke them).

Having said that, I did like the idea of decentralized identity provider and not having any one identity provider to be THE identity provider that everyone else had to rely on (putting user in control of their own identity). Compare this with a world where one identity provider (be it facebook or Google or twitter or anyone else) is the dominant identity provider because it is easy for RPs to embed a simple button  and for users to click on it.

Reading Farhang&#39s post, here&#39s what I find most interesting.  It was never that users decided they didn&#39t want “a change of behavior” around passwords.  Instead it was web properties like eBay (and a thousand others) who came to this conclusion.  Many of the people designing those properties worried that providing users the option of changing their behavior was too dangerous – especially since it was not essential… 

In the history of computing there have actually been plenty of cases where users DID change their behavior – even though at first only a few people could understand or use the new alternatives.  But those “early adopters” were able to try the new inventions on their own.  They didn&#39t need anyone else to approve something or decide they would like it first.  Once convinced, they could show the new ideas to others.

When Visicalc appeared, I don&#39t know how many people in IT would have bet that every accountant in the world would soon be throwing out his pencils and starting to use spreadsheets for things no one can even now believe are possible!  The same is true for a thousand other applications people came to love. 

But because authentication doesn&#39t stand on its own, users never got the chance to start using Information Cards “just because they felt like it”.  They needed web sites to make the same bet they did by implementing Information Card support as an option.  

Web sites didn&#39t want to bet.  They wanted to keep to “the matter at hand” and prevent their users from getting lost or distracted.  The result: a preemptive chill settled over the technology, and we never really got to see what users would make of it.

My conclusion:  regardless of what new features they support, user centric identity solutions need to be built so they work with as many existing web sites as possible.  They can&#39t require buy-in from the all the big web sites in order to be useful. 

I think we should have included a way for Information Cards to support password-based sites.  It was possible.  I personally avoided it because I was worried it would be unreliable and not work at all sites.

Yet a lot of password managers do this, and Dick Hardt&#39s SXIP system combined this approach with support for new protocols.  I think that aspect of his work was probably right.

 

Change will come: the present is untenable.

Gunnar Peterson at 1 Raindrop adds his own thoughts about CardSpace and Claims:

The official announcements from Microsoft on Cardspace have led to a lot of reflection in the identity community. From the core team, Mike Jones described what he considered some of the important barriers:

  • Not solving an immediate perceived problem: In my extensive experience talking with potential adopters, while many/most thought that CardSpace was a good idea, because they didn’t see it solving a top-5 pain point that they were facing at that moment or providing immediate compelling value, they never actually allocated resources to do the adoption at their site.
  • Not drop-dead simple to use: Users were often confused by their first encounter with CardSpace; many didn’t succeed at the task at hand. Indeed, many saw it as something complicated getting in the way of what they were actually there to do.

The first of these issues is one I am always trying to be cognizant of. From the 90s, a Bill Joy quote that stuck with me was when he described why JINI never took off – “we were solving problems that people did not know they had yet.” Its an every day occurrence to manage this reality-perception gap in infosec both from a business risk standpoint; as well as given the myriad of architectural opportunities for improvement (aka problems) which ones and where do you want to invest your time in strengthening your systems?

But from an industry perspective, there is a positive way to look at Bill Joy&#39s quote – the word “yet.” Just a few years after JINI failed to launch, Web services took off like gangbusters and there is no end in sight.

As Howard Marks says in investing, sometimes being early is indistinguishable from being wrong, but that is a temporary thing, and a longer term view is in order. Jeremy Grantham (GMO) got out of tech stocks in the 90s bubble, his clients thought he was crazy and he lost half his business. Grantham called this taking career risk.

Another great value investor, Jean Marie Eveillard said about this episode – I would rather lose half my clients than lose half my client&#39s money.

Everyone could see the tech bubble was out of control in the 1990s but very few investment managers were willing to take the career risk to themselves to protect their client&#39s assets. 

Today everyone can see that our Internet identity technology is woefully inadequate, but very few are willing to push through comprehensive approaches towards addressing them.

Being early is not necessarily being wrong, but when coupled with a new usage paradigm, its more problematic. Farhang Kassaei discussed what the view looked like from the point of a consuming company looking to develop on Cardspace.

The Cardspace team has many talented people and freely published more in depth thinking on identity than anyone else in the industry. These lessons won&#39t be forgotten and the future for Claims based access control is bright, in fact its just beginning. We may look back in a few years time and think of Cardspace like JINI and see tidal wave stack of CBAC/ABAC/Selectors/U-Prove that powered up huge new parts othe industry the same way Web services played out.

In fact I bet that we do. 

What&#39s the other option? Living with a ridiculous patchwork approach to identity?

No one writes there own crypto, security people are good at getting this message across – but what do you bootstrap your crypto off of? Identity! And people write identity, authN, authZ, provisioning, from scratch all the time – where is the logic? 

Gunnar continues with an interesting reference to the behavioral economist Dan Ariely before concluding:

There is too much fraud, crime, malfeasance and threats to keep rolling out the same old same old identity. Change will come if for no other reason than the present is untenable.

Cardspace was like the first Marines trying to take the beach and some got cut down, but much has been learned in the process and the beach has to be taken; there are waves of identity and access improvement coming right now.

Rest in Peace Cardspace. Long Live Claims Based Access Control!

From CardSpace to Verified Claims

Last week Microsoft announced the availability of Version 2 of the U-Prove Technology Preview.

What’s new about it?

The most important thing is that it offers a new, web-oriented user experience carefully tailored to helping people control the release of “verified claims” while protecting their privacy.  By verified claims I mean things that are said about them as flesh-and-blood people by entities that can speak, at least in certain contexts, with authority. By protecting privacy I mean keeping information released to the minimum necessary, and ensuring that the authority making the claims – for example a government – is not able to track and profile the way your information is used.

The system takes a number of the good ideas from CardSpace but is also informed by what CardSpace didn’t do well. It doesn’t require the installation of new components on your computer. It works on all the major browsers and phones. It roams between devices. Sites don&#39t have to worry about users “getting a card” before the system will work. And it allows claims providers and relying parties to shape and brand their users’ experiences while still providing a consistent interface for claims approval.

In other words, it represents a big step forward for protecting privacy using high value credentials to release claims.

A focused approach

When it comes to verified claims, the “U-Prove Agent” goes beyond CardSpace.  One way it does this is by being highly focused and integrated into a specific type of identity experience. I’ll be posting a video soon that will help you get a concrete sense of why this works.

That focus represents a change from what we tried to do with CardSpace.   One of the key goals of CardSpace was to provide a “generalized solution” – an alternative to the “patchwork quilt” of what I called “identity kludges” that characterize peoples’ experience of identity on the Internet.

In fact I still believe as much as ever that a “generalized solution” would be nice to have. I would even go so far as to say that a generalized solution is inevitable – at some point in time.

But the current chaos is so vast – and peoples’ thinking about it so fractured – that the only prudent practical approach is to carve the problem into smaller pieces. If we can make progress in some of the pieces we can tie that progress together. The U-Prove Agent for exchange of verified claims is a good example of this, making it possible to offer services that would otherwise be impossible because of privacy problems.

What about CardSpace?

Because of its focus, the U-Prove agent isn’t capable of doing everything that CardSpace attempted to do using Information Cards.

It doesn’t address the problem of helping users manage ALL their identities while keeping them separate. It doesn’t address the user problems of password fatigue, phishing and pervasive “secret questions” when logging into consumer web sites.  It doesn’t solve the famous “home realm discovery problem” when using federation. And perhaps most frustrating when it comes to using devices like phones, it doesn’t give the user a simple way to pick their identities from a set of visual representations (icons or cards).

These issues are all more pressing today than they were in 2006 when CardSpace was first proposed. Yet one thing is clear: in five years of intensive work and great cross-industry collaboration with other innovators working on Apple and Linux computers and phones, we weren’t able to get Information Cards onto the radar of the big web properties users depend on.

Those properties had other priorities. My friend Mike Jones put it well at Self-Issued:

“In my extensive experience talking with potential adopters, while many/most thought that CardSpace was a good idea, because they didn’t see it solving a top-5 pain point that they were facing at that moment or providing immediate compelling value, they never actually allocated resources to do the adoption at their site.”

Regardless of why this was the case, it explains why last week Microsoft also announced that it will not be shipping CardSpace 2.0.

In my personal view, we all certainly need to keep working on the problems Information Cards address, and many of the concepts and technologies used in Information Cards should be retained and evolved. I think the U-Prove team has done a good job at that, and provides an example of how we can move forward to solve specific problems. Now the question is how to do so with the other aspects of user-centric identity.

Over the next while I’m going to do a series of posts that explore some of these issues further – drawing some lessons from what we’ve learned over the last few years.  Most of all, it is important to remember what great progress we’ve made as an industry around the Identity Metasystem, federation technology, and claims-based computing. The CardSpace identity selector dealt with the hardest and most forward-looking problems of the Metasystem:  the privacy, security and usability problems that will emerge as federated identity becomes a key component of the Internet.  It also challenged industry with an approach that was truly user centric.

It&#39s no surprise that it is hardest to get consensus on forward-looking technologies!  But meanwhile,  the very success of the Identity Metasystem as a whole will cause all the issues we’ve been working on with Information Cards to return larger than life.

 

Issuing Information Cards with ADFS 2.0

When  Microsoft released Active Directory Federation Services V2 recently, we indicated we were holding off on shipping CardSpace 2.0 while figuring out how to best integrate Minimal Disclosure Technology (U-Prove) and create maximum synergy with the OpenID and OAuth initiatives.  Some feared the change in plan meant Microsoft was backing away from the idea of Information Cards and a visual identity selector.  Nothing could be further from the truth – the growth in adoption of federation and the shift toward cloud computing both make Information Card technology more important than ever.

This new announcement from Technet identity blog will therefore come as good news:

Today, Microsoft is announcing the availability of the Information Card Issuance Community Technology Preview (CTP) to enable the following scenarios with Active Directory Federation Services 2.0 RTM:

  • Administrators can install an Information Card Issuance component on AD FS 2.0 RTM servers and configure Information Card Issuance policy and parameters.
  • End users with IMI 1.0- or IMI 1.1 (DRAFT)-compliant identity selectors can obtain Information Cards backed by username/password, X.509 digital certificate, or Kerberos.
  • Continued support for Windows CardSpace 1.0 in Windows 7, Windows Vista and Windows XP SP 3 running .NET 3.5 SP1.

We have also added two new mechanisms for interaction and feedback on this topic, an Information Card Issuance Forum and a monitored e-mail alias ici-ctp@microsoft.com

 

Not Invented Here

There&#39s a new comic strip about software with the, um, mysterious title, Not Invented Here (I just caught the preposterous domain name:  http://notinventedhe.re)…   The strip deals with issues like security, and comments posted by readers say things like, “I DEMAND you take the bug out of my company&#39s conference room immediately!” and “Wow, it is as if you have a mole in our office!”.   So, with the authors’ permission, here&#39s a taste.

It all starts off innocently enough:

Wait.  I think I&#39ve met these people.

Yikes.  Maybe I am these people!

And if you&#39re in the business, you can&#39t miss this one, which will take you over to the NIH site.

If you&#39re wondering where this can possibly come from, the strip is by Bill Barnes and Paul Southworth.  I don&#39t know Paul yet, but readers may know Bill&#39s work from Unshelved, which has been making librarians guffaw for years (an  easy task?)  The truth is, Bill knows a lot about what goes on with software – in fact one of his gigs was herding cats during the first version of CardSpace.  Now he&#39s totally dedicated to his strips – should be a lot of fun – and enlightening too. 

Project Geneva – Part 3

[This is the third installment of a presentation I gave to Microsoft developers at the Professional Developers Conference (PDC 2008) in Los Angeles. It starts here.]

Microsoft also operates one of the largest Claims Providers in the world – our cloud identity provider service, Windows Live ID.

It plays host to more than four hundred million consumer identities.

In the Geneva wave, Live ID will add “managed domain” services for sites and customers wanting to outsource their identity management.  With this option, Live would take care of identity operations but the sign in/sign up UX can be customized to fit the look of your site.

But in what I think is an especially exciting evolution, Live IDs also get access to our cloud applications and developer services via the gateway, and are now part of the same open, standards-based architecture that underlies the rest of the Geneva Wave.

Microsoft Services Connector

Some customers may want to take advantage of Microsoft’s cloud applications, hosting, and developer services – and have Active Directory – but not be ready to start federating with others.

We want to make it very easy for people to use our cloud applications and developer services without having to make any architectural decisions.  So for that audience, we have built a fixed function server to federate Active Directory directly to the Microsoft Federation Gateway.

This server is called the Microsoft Services Connector (MSC).   It was built on Project Geneva technology.

Since it’s optimized for accessing Microsoft cloud applications it manages a single trust relationship with the Federation Gateway.  Thus most of the configuration is fully automated.  We think the Microsoft Services Connector will allow many enterprises to start working with federation in order to get access to our cloud, and that once they see the benefits, they’ll want to upgrade their functionality to embrace full federation through Geneva Server and multilateral federation.

Through the combination of Geneva Framework and Server, Microsoft Services Connector, Live ID, the Microsoft Federation Gateway – and the ability to use CardSpace to protect credentials on the Internet -millions of Live and AD users will have easy, secure, SSO access to our cloud applications and developer services.

But what about YOUR applications?

OK.  This is all very nice for Microsoft&#39s apps, but how do other application developers benefit?

Well, since the Federation Gateway uses standard protocols and follows the claims-based model, if you write your application using a framework like “Geneva”, you can just plug it into the architecture and benefit from secure, SSO access by vast numbers of users – ALL the same users we do.  The options open to us are open to you.

This underlines my conviction that Microsoft has really stepped up to the plate in terms of federation.  We haven&#39t simply made it easier for you to federate with US in order to consume OUR services.  We are trying to make you as successful as we can in this amazing new era of identity.  The walled garden is down.  We want to move forward with developers in a world not constrained by zero sum thinking.

Configure your application to accept claims from the Microsoft Federation Gateway and you can receive claims from Live ID and any of the enterprise and government Federation Gateway partners who want to subscribe to your service.  Or ignore the MFG and connect directly to other enterprises and other gateways that might emerge.  Or connect to all of us.

Crossing organizational boundaries

If this approach sounds too good to be true, some of you may wonder whether, to benefit from Microsoft&#39s identity infrastructure, you need to jump onto our cloud and be trapped there even if you don&#39t like it!

But the claims-based model moves completely beyond any kind of identity lock-in.  You can run your application whereever you want – on your customer&#39s premise, in some other hosting environment, even in your garage.  You just configure it to point to the Microsoft Federation Gateway – or any other STS – as a source of claims.

These benefits are a great demonstration of how well the claims model spans organizational boundaries.  We really do move into a “write once and run anywhere” paradigm. 

Do you want choice or more choice?

For even more flexibility, you can use an enterprise-installed “Geneva” server as your application&#39s claim source, and configure that server to accept claims from a number of gateways and direct partners.

In the configuration shown here, the Geneva server can accept claims both hundreds of millions of Live ID users and from a partner who federates directly.

Claims-based access really does mean applications are written once, hosted anywhere.  Identity source is a choice, not a limitation.

You get the ability to move in and out of the cloud at any time and for any reason.

Even more combinations are possible and are just a function of application configuration. It’s a case of “Where do you want to get claims today?”.   And the answer is that you are in control.

In the next installment of this presentation I&#39ll tell you about another service we are announcing – again a claims-based service but this time focussing on authorization.  I&#39ll also link to the demo, by Vittorio Bertocci, of how all these things fit together.

The Identity Metasystem and its Identity Selectors

Paul Madsen at ConnectID makes a good point in his “Could someone hand me that hammer please?

I have a dead horse here that needs some beating.

Does  ‘identity metasystem’ not imply “a pluralism of operators and technologies”? Isn&#39t this even almost a law?

If so, should a TC focused on a single (albeit important) identity technology claim within its name the ‘meta’ scope?

The OASIS Identity Metasystem Interoperability (IMI) Technical Committee will work to increase the quality and number of interoperable implementations of Information Cards

The IMI TC&#39s mandate respects the ‘pluralism of operators’ required by the metasystem definition, but not the other piece.

NB: Any comment that includes any combination of  ‘forgot SAML token’ will be summarily rejected.

 

Metasystem and Identity Selector

Paul is completely right that the Identity Metasystem is a unifying model intended to bring together many contributing technologies – including Kerberos, PKI, browser-only federation protocols like SAML, WS-Security, WS-Trust and lightweight protocols like OpenID.  And in fact, reaching across this diversity is the most important thing about it.  Breadth is what allows us, as an industry, to create “one identity model” in terms of application development, deployment and most important, user experience.

To make this vision a reality, we need a component of the metasystem that has been missing: a common “Identity Selector”  (early examples being CardSpace and DigitalMe). 

Clearly such an important component needs to evolve in the context of an international standards body, so the announcement of the new OASIS Technical Committee dedicated to Information Cards and their interoperability is an important milestone:

Boston, MA, USA; 23 September 2008 — OASIS, the international open standards consortium, has formed a new group to enable the use of Information Cards to universally manage personal digital identities. The OASIS Identity Metasystem Interoperability (IMI) Technical Committee will work to increase the quality and number of interoperable implementations of Information Cards. A rapidly-developing, Web 2.0-friendly method for shared light authentication, Information Cards let people authenticate themselves on multiple web sites without maintaining passwords for each site.

But back to the name 

While I think Information Cards are beneficial to the whole metasystem, they are not themselves the metasytem, and don&#39t encompass all aspects of its interoperability. 

For this reason, I don&#39t personally think the OASIS committee&#39s name is currently quite right.

I&#39ve never personally participated in OASIS or any other standards body (I have great respect for those who do.)  So I have no idea whether it is possible to tweak a name once a committee is formed.  If it didn&#39t turn into a major time-waster, I think doing so would show everyone&#39s respect for all the other contributions being made to the metasystem.  I would prefer a name that is more technically specific, like the OASIS Identity Selector Interoperability Technical Committee (ISI).

The people who put in the effort to set up the committee and come up with a name will rightly say, “I wish you had given us that feedback earlier” – and I accept that criticism.  Maybe I have missed my opportunity to provide feedback.  Basically, I was sufficiently excited about the emergence of the committee, and convinced that the Identity Selector did contribute to Metasystem Interoperability, that the potential issues with the name didn&#39t jump out at me. 

And now to Occam

And now for something completely different.  In a recent post Paul also reveals the origins of the third law of identity, and makes a great connection:

“William of Occam was a 14th century English philosopher, best know for his ‘principle of parsimony‘ in comparing different explanations for some phenomena.

entia non sunt multiplicanda praeter necessitatem

“When translated and applied to identity, it&#39s clear that Kim&#39s Law 3 was preempted by some 700 years

entities must not be multiplied beyond necessity

HealthVault moves forward with OpenID

Via Mike Jones, here&#39s a blog post on identity issues by Sean Nolan, chief architect of Microsoft’s HealthVault service:     

My plan had been to blog about this when the feature goes live later in the week. But there&#39s been some online discussion already, and I&#39m sitting here at the horse show in waiting mode anyway, so it seems like now is as good a time as any to join the conversation.

The deal is — as of our next release in the next few days, users will have a new way to identify themselves to HealthVault. In addition to Windows Live ID, they will be given the option of using OpenID accounts from Verisign or TrustBearer.

As we&#39ve always said, HealthVault is about consumer control — empowering individuals with tools that let them choose how to share and safeguard their personal health information. OpenID support is a natural fit for this approach, because it allows users to choose the “locksmith” that they are most comfortable with.

You can certainly expect to see more such options in the future. For example, we are in the process of building in native support for Information Cards, which provide some unique advantages, in particular around foiling phishing attempts.

But why just two providers? When we were making our plans here, Chris on our partner team asked me, “Isn&#39t this more like sort-of-OpenID?” The same question has come up online as well.*** Really, there&#39s a very simple answer here. OpenID is a new and maturing technology, and HealthVault is frankly the most sensitive relying party in the OpenID ecosystem. It just makes sense for us to take our first steps carefully.

Both TrustBearer and Verisign have taken their obligations very seriously with their OpenID implementations. Beyond basic must-have safeguards like SSL, each offers a variety of second-factor options that provide a step up over traditional passwords — through the use of physical tokens or, in Verisign&#39s case, the ability to associate an Information Card with an OpenID. This isn&#39t meant to imply that there aren&#39t other great providers out there — there are. This is just a start.

As we learn more, and as OpenID continues to mature, we fully expect to broaden the set of providers that work with HealthVault. We believe that a critical part of that expansion is the formalization and adoption of PAPE, which gives relying parties a richer set of tools to determine if they are comfortable with the policies of an identity provider.

This is exciting stuff — in a geeky way perhaps, but anything that begins to put strong identity technology in the hands of real users is a good thing, not just for those users, but for HealthVault and the Internet overall. Woo hoo!

*** BTW, I am clearly all about being cool and buzzword-compliant! :)

It&#39s great to see an architect like Sean, who lives in Internet time and has a thousand other things on his mind, paying so much personal attention to identity issues.  He&#39s showing leadership through his commitment to phishing resistant solutions (like OpenID&#39s PAPE and Information Cards).  And he clearly embraces giving people choice. 

The privacy requirements of the information he is protecting mean he HAS to do everything possible to protect peoples’ privacy.  It makes complete sense to move incrementally.  I hope the other OpenID providers who have clearly demonstrated their committment to strong security see the wisdom in this approach.  He&#39s opening doors.  And this is the beginning of a process, not the end. 

How to set up your computer so people can attack it

As I said in the previous post, the students from Ruhr Universitat who are claiming discovery of security vulnerabilities in CardSpace did NOT “crack” CardSpace.
 
Instead, they created a demonstration that requires the computer&#39s owner to consciously disable the computer&#39s defenses through complex configurations – following a recipe they published on the web.

The students are not able to undermine the system without active co-operation by its owner. 

You might be thinking a user could be tricked into accidently cooperating with the attack..  To explore that idea, I&#39ve captured the steps required to enable the attack in this video.  I suggest you look at this yourself to judge the students’ claim they have come up with a “practical attack”.

 In essence, the video shows that a sophisticated computer owner is able to cause her system to be compromised if she chooses to do so.  This is not a “breach”.