Category: Windows Cardspace

Reactions to Credentica acquisition

Network World's John Fontana has done a great job of explaining what it means for Microsoft to integrate U-Prove into its offerings:

Microsoft plans to incorporate U-Prove into both Windows Communication Foundation (WCF) and CardSpace, the user-centric identity software in Vista and XP.

Microsoft said all its servers and partner products that incorporate the WCF framework would provide support for U-Prove.

“The main point is that this will just become part of the base identity infrastructure we offer. Good privacy practices will become one of the norms of e-commerce,” Cameron said.

“The U-Prove technology looks like a good candidate as an authentication mechanism for CardSpace-managed cards (i.e., those cards issued by an identity provider),” Mark Diodati, an analyst with the Burton Group, wrote on his blog. 

In general, the technology ensures that users always have say over what information they release and that the data can not be linked together by the recipients. That means that recipients along the chain of disclosure can not aggregate the data they collect and piece together the user’s personal information.

[More here…]

Eric Norlin has this piece in CSO, and Nancy Gohring's ComputerWorld article emphasizes that “U-Prove is the equivalent in the privacy world of RSA in the security space.”  Burton's Mark Diodati covers the acquisition here.

Gunnar Peterson from 1 Raindrop notes in That Was Fast: 

…the digital natives may be getting some better tooling faster than I thought. I am sure you already know there is a northern alliance and Redmond is U-Prove enabled. I fondly remember a lengthy conversation I had with Stefan Brands in Croatia several years ago, while he patiently explained to me how misguided the security-privacy collision course way of thinking is, and instead how real security is only achieved with privacy. If you have not already, I recommend you read Stefans’ primer on user identification.

Entrepreneur and angel investor Austin Hill gives us some background and links here:

In the year 2000, Zero-Knowledge acquired the rights to Dr. Stefan Brands work and hired Stefan to help us build privacy-enhanced identity & payments systems.  It turns out we were very early into the identity game, failed to commercialize the technology – and during the Dot.Com bust cycle we shut down the business unit and released the patents back to Stefan.  This was groundbreaking stuff that Stefan had invented, and we invested heavily in trying to make it real, but there weren’t enough bitters in the market at that time.  We referred to the technologies as the “RSA” algorithms of the identity & privacy industry.  Unfortunately the ‘privacy & identity’ industry didn’t exist.

Stefan went on to found Crendentica to continue the work of commercialization of his invention. Today he announced that Microsoft has acquired his company and he and his team are joining Microsoft.

Microsoft’s Identity Architect Guru Kim Cameron has more on the deal on his blog (he mentions the RSA for privacy concept as well).

Adam Shostack (former Zero Knowledge Evil Genius, who also created a startup & currently works at Microsoft) has this post up.   George Favvas, CEO of SmartHippo (also another Zero-Knowledge/Total.Net alumni – entrepreneur) also blogged about the deal as well.

Congratulations to Stefan and the team.  This is a great deal for Microsoft, the identity industry and his team. (I know we tried to get Microsoft to buy or adopt the technology back in 2001 🙂 

(I didn't really know much about Zero-Knowledge back in 2000, but it's interesting to see how early they characterized of Stefan's technology as being the privacy equivalent of RSA.  It's wonderful to see people who are so forward-thinking.)

Analyst Neil Macehiter writes:

Credentica was founded by acknowledged security expert Stefan Brands, whose team has applied some very advanced cryptography techniques to allow users to authenticate to service providers directly without the involvement of identity providers. They also limit the disclosure of personally-identifiable information to prevent accounts being linked across service providers and provide resistance to phishing attacks. Credentica's own marketing literature highlights the synergies with CardSpace:

“`The SDK is ideally suited for creating the electronic equivalent of the cards in one's wallet and for protecting identity-related information in frameworks such as SAML, Liberty ID-WSF, and Windows CardSpace.”

This is a smart move by Microsoft. Not only does it bring some very innovative and well-respected technology (with endorsements from the likes of the Information and Privacy Commissioner of Ontario, Canada) which extends the capabilities of Microsoft's identity and security offerings; it also brings some heavyweight cryptography and privacy expertise and credibility from the Credentica team. The latter can, and undoubtedly will, be exploited by Microsoft in the short term: the former will take more time to realise with Microsoft stating that integrated offerings are at least 12–18 months away.

[More here…]

Besides the many positives, there were concerns expressed about whether Microsoft would make the technology available beyond Windows.  Ben Laurie wrote:

Kim and Stefan blog about Microsoft’s acquisition of Stefan’s selective disclosure patents and technologies, which I’ve blogged about many times before.

This is potentially great news, especially if one interprets Kim’s

Our goal is that Minimal Disclosure Tokens will become base features of identity platforms and products, leading to the safest possible intenet. I don’t think the point here is ultimately to make a dollar. It’s about building a system of identity that can withstand the ravages that the Internet will unleash.

in the most positive way. Unfortunately, comments such as this from Stefan

Microsoft plans to integrate the technology into Windows Communication Foundation and Windows Cardspace.

and this from Microsoft’s Privacy folk

When this technology is broadly available in Microsoft products (such as Windows Communication Foundation and Windows Cardspace), enterprises, governments, and consumers all stand to benefit from the enhanced security and privacy that it will enable.

sound more like the Microsoft we know and love.

I hope everyone who reads this blog knows that it is elementary, my dear Laurie, that identity technology must work across boundaries, platforms and vendors (Law 5 – not to mention, “Since the identity system has to work on all platforms, it must be safe on all platforms”). 

That doesn't mean it is trivial to figure out the best legal mecahnisms for making the intellectual property and even the code available to the ecosystem.  Lawyers are needed, and it takes a while.  But I can guarantee everyone that I have zero intention of hoarding Minimal Disclosure Tokens or turning U-Prove into a proprietary Microsoft technology silo. 

Like, it's 2008, right?  Give me a break, guys!

Handbags at dawn?

Here is Pat Patterson's post on my recent discussion with Ben Laurie.   Pat is a widely respected member of Sun's identity team, blogs at Superpatterns, and runs the useful PlanetIdentity RSS feed.   There are a number of ways you could build a Password Manager for CardSpace, but I thought readers would enjoy seeing Pat's take on it:

You might have noticed the exchange between Ben and Kim over the past day or two… Ben made a point that CardSpace makes OpenID redundant – why not just send a password to the RP? Kim jumped all over him – somewhat misinterpreting what Ben later describes as one of my most diabolical hungover bits of prose ever. Ben goes on to clarify that maybe CardSpace can have a role in helping the user manage passwords; Kim says “Hmm… Food for thought” (okay, I'm paraphrasing); Ben admits he didn't explain himself too clearly to begin with; and, glory be, they're violently agreeing. Phew! I thought we were going to be seeing handbags at dawn…

Reading all this lit a spark in my mind of how this could work. The crux is to consider the username/password token, usually sent as one of a set of possible input tokens to an identity provider security token service (IP/STS), as an output token.

Here's how it would work… Borrowing a diagram from Microsoft's Guide to Interoperating with the Information Card Profile V1.0:

First of all, the IP/STS would specify ic:RequireAppliesTo in the managed card. This tells the identity selector to include a wsp:AppliesTo element in the wst:RequestSecurityToken (RST). The IP/STS is going to need this later…

Now, the user visits the relying party (RP) in step 1, requesting some resource. In step 2, the ‘service requestor’ (application client with identity selector) requests security policy from the RP. The RP would indicate, in step 3, that it wanted a username/password token by specifying a token type of http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0 in the policy.

Now the identity selector presents some set of information cards (hopefully just one) to the user (step 5) and the user selects one (step 6). Steps 7 and 8 would see the RP requesting security policy from the IP/STS, and the IP/STS supplying it, exactly as in the standard information card interaction. Here the IP/STS could require any form of input token, but username/password is most likely.

Between steps 8 and 9, the identity selector prompts the user for credentials (bad Microsoft, missing that out of the diagram!) and in step 8, the identity selector packages up the user's credentials in a WS-Trust RST and send them to the IP/STS.

Now, here's the interesting bit. The IP/STS authenticates the user, exactly as in the standard CardSpace case, but now it looks at the wsp:AppliesTo element, and looks up the user's username/password pair for that RP (this is an implementation detail – there could be a mapping of RP identifiers to username/password pairs per user, all encrypted on disk, of course). The IP/STS packages them as a wsse:UsernameToken, which is then encrypted with the RP's public key and returned to the identity selector (step 10). The display token could just show ******** for the value of the password claim. Now we have a nice, securely packaged credential that the identity selector can send to the RP in step 11.

Here's the other nice bit… All the RP has to do is to decrypt the incoming token and it has the user's username and password, exactly as if they had arrived by a conventional form post. No further customization required at the RP – no changes to directory or database schemas, no extra steps of associating an information card with your account. Passwords on steroids.

If the RP uses https, I'm not even sure there is any need to decrypt at the token layer, which simplifies implementation to decoding a simple xml structure.  RP's who are looking for greated levels of security should switch to public key.

I'd like to hear Pat's ideas about the user experience of bootstrapping the passwords into the Identity Provider.

Not the browser!

Google's Ben Laurie bookends our dialog (work back from here) with a really clear statement:

Kim correctly observes that the browser is not the place to be typing your password. Indeed. I should have mentioned that.

Clearly any mechanism that can be imitated by a web page is dead in the water. Kim also wants to rule out plugins, I take it, given his earlier reference to toolbar problems. I’m OK with that. We want something that only a highly trusted program can do. That’s been so central to my thinking on this I forgot to mention it. Sorry.

This sounds really positive.  Now, just so I don't end up with a different security product from every big web site, I hope Ben's work will include integration with the CardSpace framework.  I'm certainly open to discussions about ways we might evolve CardSpace to facilitate this.

Ben Laurie's “Single Passwords”

Given his latest post, I guess I got the gist of Ben Laurie's proposal for using what I'll call “Single Passwords” rather than “Single Signon”:  

“Kim Cameron, bless him, manages to interpret one of my most diabolical hungover bits of prose ever. I am totally with him on the problem of pharming, but the reality is that the average Cardspace user authenticated with nothing better than a password (when they logged into Windows).

Wow.  I appreciate the blessing from Father Laurie, but this is kind of a “We're going to die one day, so who cares if we die tomorrow?” type of argument – surprising for a priest. 

While it's true that pharming is a challenge for the operating system as well as the browser, let's not seriously equate the dangers of entering passwords into browsers (a malleable experience, the goal of which is to be infinitely and easily modified by anyone) with those involved in booting up your PC (a highly controlled environment designed to allow no modification and use a secure desktop).  It's true that both involve passwords.  But the equation is simplistic, best summed up as: “Tables have legs, people have legs, therefore tables are people.”

Anyway, I'm sympathetic to Ben's concerns about portability:

“Furthermore, if you are going to achieve portability of credentials, then you can either do it in dreamland, where all users carry around their oh-so-totally-secure bluetooth credential device, or you can do it in the real world, where credentials will be retrieved from an online store secured by a password.

I don't dismiss dreamland – isn't that what iPhones want to be?  But we do need lightweight roaming.  Using an online vault secured by a passphrase is a reasonable way to bootstrap a secret onto a machine.

But not the browser! 

The rub is:  once a user gets into the habit of typing this secret into the browser, she's ready to be tricked.  I'll go further.  If  the vault one day accrues enough value, a browser-based system WILL fail the user – sooner or later.   

Ben concludes:

“If you believe the Cardspace UI can protect people’s credentials, then surely it can protect a password?

“If it really can’t (that is, we cannot come up with UI that people will reliably identify and eschew all imitations), then how will we ever have a workable, scalable system that includes recovery of credentials after loss or destruction of their physical goods?”

There's food for thought here.  Start to take advantage of the engineering in CardSpace, and you inherit significant protection in terms of both phishing and pharming.  So if Ben implements his “Single Password” this way, he could start to be reasonably confident that the “function of the password” is what is released, while the password is guarded.

Eric Norlin takes OpenID to CSOs

Digital ID World's Eric Norlin explains why security executives should pay attention to OpenID in this article from CSO – the Resource for Security Executives: 

Kim Cameron has posted another thoughtful piece about why he (and by extension Microsoft) is supportive of OpenID. For those of you that don't eat, sleep, dream and breathe identity, Kim is the guy at Microsoft that was responsible for writing the “Seven Laws of Identity,” which led to the idea of an identity metasystem, which effectively gave birth to all kinds of meetings (the “identity gang”), which led to things like OpenID and Higgins really taking off. Bottom line: Kim's a VIP in the identity world (he's also one helluva nice guy).

Kim's main point is this:

“My takeaway is that OpenID leads to CardSpace. I don’t mean by this that Information Cards replace OpenID. I just mean that the more people start using cross-site identities, the more the capabilities of CardSpace become relevant as a way of strengthening OpenID and put it in a broader technology context.

Information Cards were created to put in place an infrastructure that can solve the security problems of the web before they explode in our faces. It’s a serious technology and involves secure high-strength products emerging across the industry.”

Its important to note that Kim is thinking about identity ecosystems, not “one protocol to rule them all.” Really, it comes down to making the use of an identity a “ritual.” That sounds a bit off, I know, but hear me out. Believe it or not, the great majority of humanity had its first contact with email in a workplace setting. Now, if the interface (and interaction) for email was substantially different for work-usage and home-usage (or should I say, WorkUsage and HomeUsage?), do you think the adoption curve would've been the same? I don't.

One of the essential points that Kim's been hammering on for a couple of years is that we have to make the underlying “ritual” of using identity similar in a foundational sense.

Yet one more reason why you (as a CSO) should be paying attention to OpenID. After all, people don't always first see and experience things in the workplace.

This matter of influences from the internet converging with the enterprise is incredibly important, and I'm going to expand on it soon.  By the way, it was Eric's encouragement that got me hooked on writing the Laws of Identity.

From “Screen-Names in Bondage” to OpenID

Google's Ben Laurie proposes using “functions of passwords” rather than plain passwords as a way to avoid phishing: 

Kim Cameron writes about fixing OpenID’s phishing problems by using Cardspace. Certainly I agree that using strong authentication to the OpenID provider fixes the phishing problem – but if you have strong authentication, why bother to use OpenID at all? Why not strongly authenticate to the site you are really trying to log into, instead?

Of course, Cardspace is a pretty heavyweight solution for this, so perhaps that’s what Kim’s getting at? It also doesn’t work well if you have more than one machine – moving your credentials around is not something Cardspace does well.

In my view, there’s a sweeter spot for solving this problem than Cardspace (or OpenID, obviously) – and that is to do strong authentication based purely on a password. That way, you can use the same password everywhere, so no problem with moving between machines, but can still resist phishing attacks and don’t have to make yourself linkable across all sites. Obviously supporting this would be way easier than taking the whole of Cardspace on board, but would have all of the immediate advantages. Clearly it would get you nowhere with advanced identity management, but its not like we don’t already have protocols for that and nor does there seem to be much demand for it yet.

I take it Ben is talking about having a toolbar that asks for your password, and transforms it based on the site's identity so you can use the same password everywhere.  Perhaps he is even thinking about a digest protocol where this transformed password would be used to calculate a “proof” rather than transported over the wire.

Phished or Pharmed 

Problem is, such a toolbar is as easily “pharmable” as OpenID is phishable.

How does a user know she is typing her password into the legitimate toolbar – rather than an “evil replica”?  Our experience with toolbars teaches us that is easy to trick a LOT of people into using fakes.  In fact, sometimes the fakes have propagated faster than the real thing!  Once people get used to typing passwords into a toolbar you have truly opened Pandora's Box.

Let's look at what happens when the kind of “common password” Ben proposes is stolen. In fact, let's compare it to having money stolen. 

If you go into a store and are short-changed, you just lose money in one store.  If you are pick pocketed, you just lose what's in your wallet – you can cancel your cards.  But if your “common password” is intercepted, it is as though you have lost money in ALL the stores you have been in.   And sadly, you will have lost a lot more than money.

The ultimate advantage of moving beyond passwords is that there is then NO WAY a user can inadvertantly give them away.

Is CardSpace too heavy-weight? 

CardSpace should be a lighter-weight experience than it is today.  We're working on that, making it less “in-your-face” while actually increasing its safety.  I also agree with Ben that it needs to be easier to roam credentials.  We're working on that too. 

The point is, let's evolve CardSpace – and the interoperable software being developed by others – to whatever is needed to really solve the relevant privacy and security problems, rather than introducing more half-measures that won't be effective.

So why OpenID?

If that's all true, Ben wonders why we bother with OpenID at all…

The most important reason is that OpenID gives us common identifiers for public personas that we can use across multiple web sites – and a way to prove that we really own them.

That is huge.  Gigantic.  Compare it to the cacophony of “screen-names” we have today – screen-names in bondage, prisoners of each site.

Technology people are sometimes insulted when you imply they haven't solved the world's problems.  But to be really important, OpenID doesn't have to solve the world's problems.  It just has to do this one common-identifier thing really well.  And it does.  That's what I love about it.

CardSpace doesn't address the same problem.  CardSpace plus OpenID solve it together. 

draft.blogger.com betas OpenID for blogger

Blogger.com now supports OpenID on its beta site.  I have to congratulate the blogger.com team on the user experience they've created.  This is not necessarily their final kick-at-the-can, but I like what they've done so far.

Blog owners have a simple radio-button selection to determine who can comment: 

 

From then on, when someone visits the blog as a user and wants to make a comment, they are given the choice of how to identify themself.  Choose “Any OpenID” and you are given the chance to enter one.  Click on that, and you are redirected to your OpenID provider.

Here's what it looked like for me.  I wanted to congratulate the team for their great work, so I filled out a comment form like this:

 

Then I pressed “Publish Your Comment” and got this:

That's because I use myopenid.com, which for me is phishproof because of its great Information Card support (in other words, no password is involved and no credential can be stolen).

That's it folks.  I pressed send and got:

Why is this implementation so good?  Because it doesn't torment you, doesn't make you set up an account, doesn't make you create a password you don't need, and doesn't nag you to join Blogger when that isn't in the cards.  And it puts full control over the kinds of credentials to accept into the hands of the bloggers  themselves. 

This is the kind of experience I have envisaged and have been waiting for.  I think it is a sign of things to come, since many other sites are looking at the same concepts.  There is going to be a “conflagration” when people start to “get it”.  Just look at the comments.  There could be a lot of people who do join Blogger just because they've been handed a carrot, not given the stick.

One last aside on the low-friction thing.  Once I've gone through the dance above, I can continue to post at Blogger.com and all other sites with which I've established relationships – without further authentication.   That is very powerful.

CardSpace for the rest of us

I've been a Jon Udell fan for so long that I can't even admit to myself just how long it is!  So I'll avoid that calculation and just say I'm really delighted to see the CardSpace team get kudos for its long-tail (no-ssl) work in Jon's recent CardSpace for the rest of us: 

Hat tip to the CardSpace team for enabling “long tail” use of Information Card technology by lots of folks who are (understandably) daunted by the prospect of installing SSL certificates onto web servers. Kim Cameron’s screencast walks through the scenario in PHP, but anyone who can parse a bit of XML in any language will be able to follow along. The demo shows how to create a simple http: (not https:) web page that invokes an identity selector, and then parses out and reports the attributes sent by the client.

As Kim points out this is advisable only in low-value scenarios where an unencrypted exchange may be deemed acceptable. But when you count blogs, and other kinds of lightweight or ad-hoc services, there are a lot of those scenarios.

Kim adds the following key point:

Students and others who want to see the basic ideas of the Metasystem can therefore get into the game more easily, and upgrade to certificates once they’ve mastered the basics.

Exactly. Understanding the logistics of SSL is unrelated to understanding how identity claims can be represented and exchanged. Separating those concerns is a great way to grow the latter understanding.

I've never been able to put it this well, even though it's just what I was trying to do.  Jon really nails it.  I guess that's why he's such a good writer while I have to content myself with being an architect.

Getting claims when using no-ssl CardSpace

When a user tells CardSpace to “send” identity data from a self-issued card to a web site,  it posts a SAML token using the action attribute in the HTML form containing an x-informationCard Object tag.

In the simple, no-ssl case, this information will not be encrypted, so you can just treat it as an XML blob.  You can test this out by making the form's action a script like this one:

This script just takes everything that is posted to the web server by CardSpace after processing the invocation form, and reflects it back as an “XML encoding”.  The result is shown in my demo, and in the no-ssl zip file as result.xml.

As pedagogical as the XML dump may be, it isn't a good sample of how you would consume claims.  For that, let's look at the following script:

GetClaims() shown above is just a way of pulling values out of an XML document – use your own instead.  You will see that the givenname and privatepersonalidentifier claims used here are retrieved with this simple code.

I hope all of this will become very clear by watching the demo and looking at the aforementioned zip file, which you can cut and paste for your own experiments.

[Note:  the raw XML display code above did not include the stripslashes function when I first posted it, which caused the function to fail in certain php configurations.  Thanks to Alex Fung from Hong Kong for the report.]

HTML to invoke CardSpace on your site

In an upcoming post called Ultimate Simplicity: 30 lines of code, I show how to tweak a web page so it presents the option of logging in with an information card – without requiring you to dirty your hands with certificates.

If you haven't seen the demo yet, I start from a simple web page like this one:

I add an HTML form like this:

The form has an ID of “ctl00′, and a post action called “dump_input.php”.  In other words, when the form is submitted (by clicking on the icon specified in the “img” section) the contents will be posted and the script “dump_input.php” will be run on the web server.

The form contains an x-informationCard object tag, which takes a parameter of “RequiredClaims”.  This is followed by the claims the web page designer is asking for – in this case givenname and private personal identifier.

The zip of the sample code is here.

If you copy demo.html to your site, then when using the most recent release of CardSpace, you can navigate to that page, click on the icon, and you will be prompted for an infocard. 

The claims supported in CardSpace for simple self-issued cards are defined here – you could cut and past them into the “RequiredClaims” parameter of demo.php to alter the form's behavior.