Category: Identity

Resending of personal data with InfoCards

Eric Schultz writes with this question: 

I've been investigating CardSpace and the practicality of it's use for login on a new social networking site.

I have a question regarding the method through which data is transferred. I see that you can require certain claims from an InfoCard such as email, first and last name, zip code etc. When I look at the login code I see that the same claims are required again.

Does this mean that each time an InfoCard is sent all the personal data is resent? Isn't this dangerous for security/privacy? The potential for a server failure (malicious or not) caused by a buffer overflow, a coding mistake that outputs the details of session variables etc. seems rather risky in this scenario.

Perhaps I am being alarmist?

This is an area in which being “an alarmist” – perhaps I will rephrase it as being thoroughly pessimistic about what can go wrong – is the best starting point.  You questions are ones everyone should think about.

InfoCard and Minimal Disclosure

The simple answer is that there is nothing built into InfoCard concepts that requires a “relying party” to ask for attributes every time a user comes to its site.  Let's first look at the mechanics. 

The relying party controls what attributes it asks for by putting an OBJECT tag in the HTML page where the user opts to use an infocard.

The example shown here will bring up the infocard dialog and illuminate any cards that offer all four claims so the user can select one. 

If, next time, the relying party doesn't want to receive these claims, it just doesn't ask for them.  If it has stored them, it should be able to retrieve them when necessary by using  “privatepersonalidentifier” as a handle.  This identifier is just a random pairwise number meaningless to any other site, and so there is no identity risk in using it.

No theoretical bias 

In other words, the InfoCard system has no theoretical bias about what information should be asked for when.  Through the Laws of Identity we have tried to help people understand that they should only ask for what they need to complete a transaction and should only keep it for the length of time they absolutely must. 

In particular, there should be no hoarding of rainy-day information – information that “might come in handy” some day – but which is more likely to turn into a liability than into a benefit.

Do your risk analysis 

You'll need to do the conventional risk analysis and think about whether it is more dangerous to store the information or just ask for it on an “as-needed” basis and then forget it.  My personal sense is that it is more dangerous to store it than to use an on-demand approach. 

A central machine with the stored information that animates a successful internet business is a honeypot.  It could well be subject to insider attacks, and certainly, since it lives on the internet, will be subject to many attacks on the information it stores.  Why not avoid these problems completely?

Certainly, the on-demand approach has benefits in convincing customers and legal practitioners that, having held no identity information, you cannot be seen as being responsible for an identity meltdown.  To me this is very attractive, and something that has not been possible until now.

Conclusion

The examples Eric gives of things that can go wrong seem to me to apply even more strongly if you have stored information locally than if you ask for it on demand.

But as I said earlier, this just expresses my thinking – there is lots more to be written by Eric and hundreds of others as they develop applications. 

Meanwhile, InfoCard has no built-in assumptions around this and can be used in whatever way is appropriate to a given situation.

 

Separating apples from oranges

Dick Hardt of Sxip posted a reply to my recent comments on the fears I have about attacks on OpenID:

My good friend Kim Cameron posted the following misinformation on OpenID:

InfoCards change the current model in which the user can be controlled by an evil site. OpenID doesn’t. 

If a user ends up at an evil site today, it can pose as a good site known to the user by scooping the good site’s skin so the user is fooled into entering her username and password.

An evil site proxying a web based OpenID Provider is a known security threat in OpenID. There are a number of ways of thwarting this attack, and given that the user has a close relationship with their OP, not difficult to deploy. Similar to the advantages that CardSpace has with a client side implementation, Sxipper is a Firefox plug-in that provides an OpenID user with the same client side protections as CardSpace. OpenID is a protocol, similar at a high level to WS-* — so this is somewhat of an apples an oranges comparison. CardSpace could support OpenID and protect the user.

I’d like to see OpenID and InfoCard technologies come together more. I’ll be presenting a plan for that over the next little while.

I’m looking forward to seeing your thoughts Kim! Perhaps supporting OpenID in Cardspace?

I'm not just talking about (realtime) proxying.  I'm talking about social engineering attacks in general.  Where is the misinformation in my description of these attacks?  

Dick reassures us that use of the protocol to help convince uers to reveal their credential is a known attack.  Should this make me feel better?  I don't think so. 

I also don't think the mitigations I've heard about are too convincing – with a couple of exceptions. 

One of those is the mitigation devised by Dick himself – called Sxipper.  This is a plugin for the browser which, as I understand it, take control away from the evil party.  If all OpenID implementations were to add this feature it would be a big step forward!

But in that case, if we want to separate apples from oranges, let's not say that InfoCards require a client component and OpenID doesn't.  Let's say that to offer reasonable protection, InfoCards require a client component and so does OpenID.  That would, as Dick proposes, properly separate discussion of protocols from the overall delivery of an identity solution.

Use of a hardware token at the OpenID site also mitigates the social engineering attack, though not the man in the middle attack.

More later about how Cardspace and OpenID can converge further.

As simple as possible – but no simpler

Gunnar Peterson recently showed me a posting by Andy Jaquith (securitymetrics.org and JSPWiki) that combines coding, wiki, identity, Cardspace, cybervandals, and OpenID all into one post – a pretty interesting set of memes.  Like me, he finally actually shut off anonymous commentary because he couldn't stand the spam workload, and is looking for answers:

Last week's shutoff of this website's self-registration system was something I did with deep misgivings. I've always been a fan of keeping the Web as open as possible. I cannot stand soul-sucking, personally invasive registration processes like the New York Times website. However, my experience with a particularly persistent Italian vandal was instructive, and it got me thinking about the relationship between accountability and identity.

Some background. When you self-register on securitymetrics.org you supply a desired “wiki name”, a full name, a desired login id, and optionally a e-mail address for password resets. We require the identifying information to associate specific activities (page edits, attachment uploads, login/log out events) with particular members. We do not verify the information, and we trust that the user is telling truth. Our Italian vandal decided to abuse our trust in him by attaching pr0n links to the front page. Cute.

The software we use here on securitymetrics.org has decent audit logs. It was a simple matter of identifying the offending user account. I know which user put the porn spam on the website, and I know when he did it. I also know when he logged in, what IP address he came from, and what he claimed his “real” name was. But although I've got a decent amount of forensic information available to me, what I don't have any idea of whether the person who did it supplied real information when he registered.

And therein lies the paradox. I don't want to keep personal information about members — but at the same time, I want to have some degree of assurance that people who choose to become members are real people who have serious intent. But there's no way to get any level of assurance about intent. After alll, as the New Yorker cartoon aptly put it, on the Internet no-one knows if you're a dog. Or just a jackass.

During the holiday break, I did a bit of thinking and exploration about how to address (note I do not say “solve”) issues of identity and accountability, in the context of website registration. Because I am a co-author of the software we use to run this website (JSPWiki), I have a fair amount of freedom in coming up with possible enhancements.

One obvious way to address self-registration identity issue is to introduce a vetting system into the registration process. That is, when someone registers, it triggers a little workflow that requires me to do some investigation on the person. I already do this for the mailing list, so it would be a logical extension to do it for the wiki, too. This would solve the identity issue — successfully vetting someone would enable the administrator to have much higher confidence in their identity claims, albeit with some sacrifice

There's just one problem with this — I hate vetting people. It takes time to do, and I am always far, far behind.

A second approach is to not do anything special for registration, but moderate page changes. This, too, requires workflow. On the JSPWiki developer mailing lists, we've been discussing this option quite a bit, in combination with blacklists and anti-spam heuristics. This would help solve the accountability problem.

A third approach would be to accept third-party identities that you have a reasonable level of assurance in. Classic PKI (digital certificates) are a good example of third-party identities that you can inspect and choose to trust or not. But client-side digital certificates have deployment shortcomings. Very few people use them.

A promising alternative to client-side certificates is the new breed of digital identity architectures, many of which do not require a huge, monolithic corporate infrastructure to issue. I'm thinking mostly of OpenID and Microsoft's CardSpace specs. I really like what Kim Cameron has done with CardSpace; it takes a lot of the things that I like about Apple's Keychain (self-management, portability, simple user metaphors, ease-of-use) and applies it specifically to the issue of identity. CardSpace‘s InfoCards (I have always felt they should be called IdentityCards) are kind of like credit cards in your wallet. When you want to express a claim about your identity, you pick a card (any card!) and present it to the person who's asking.

What's nice about InfoCards is that, in theory, these are things you can create for yourself at a registrar (identity provider) of your choice. InfoCards also have good privacy controls — if you don't want a relying party (e.g., securitymetrics.org) to see your e-mail identity attribute, you don't have to release that information.

So, InfoCards have promise. But they use the WS-* XML standards for communication (think: big, hairy, complicated), and they require a client-side supplicant that allows users to navigate their InfoCards and present them when asked. It's nice to see that there's a Firefox InfoCard client, but there isn't one for Safari, and older versions of Windows are still left out in the cold. CardSpace will make its mark in time, but it is still early, methinks.

OpenID holds more promise for me. There are loads more implementations available (and several choices for Java libraries), and the mechanism that identity providers use to communicate with relying parties is simple and comprehensible by humans. It doesn't require special software because it relies on HTTP redirects to work. And best of all, the thing the identity is based on is something “my kind of people” all have: a website URL. Identity, essentially, boils down to an assertion of ownership over a URL. I like this because it's something I can verify easily. And by visiting your website, I can usually tell whether the person who owns that URL is my kind of people.

OpenID is cool. I got far enough into the evaluation process to do some reasonably serious interoperability testing with the SXIP and JanRain libraries. I mocked up a web server and got it to sucessfully accept identities from the Technorati and VeriSign OpenID services. But I hit a few snags.

Recall that the point of all of this fooling around is to figure out a way to balance privacy and authenticity. By “privacy”, I mean that I do not want to ask users to disgorge too much personal information to me when they register. And correspondingly, I do not want the custodial obligation of having to store and safeguard any information they give me. The ideal implementation, therefore, would accept an OpenID identity when presented, dyamically collect the attributes we want (really, just the full name and websute URL) and pull them into our in-memory session, and flush them at the end of the session. In other words, the integrity of the attributes presented, combined with transience yields privacy. It's kind of like the front-desk guard I used to see when I consulted to the Massachussetts Department of Mental Health. He was a rehabilitated patient, but his years of illness and heavy treatment left him with no memory for faces at all. Despite the fact I'd visited DMH on dozens of occasions, every time I signed in he would ask “Have you been here before? Do you know where you are going?” Put another way, integrity of identity + dynamic attribute exchange protocols + enforced amnesia = privacy.

By “authenticity” I mean having reasonable assurance that the person on my website is not just who they say they are, but that I can also get some idea about their intentions (or what they might have been). OpenID meets both of these criteria… if I want to know something more about the person registering or posting on my website, I can just go and check ’em out by visiting their URL.

But, in my experiments I found that the attribute-exchange process needs work… I could not get VeriSign's or Technorati's identity provider to release to my relying website the attributes I wanted, namely my identity's full name and e-mail addresses. I determined that this was because neither of these identity providers support what the OpenID people call the “Simple Registration” profile aka SREG.

More on this later. Needless to say, I am encouraged by my progress so far. And regardless of the outcome of my investigations into InfoCard and OpenID, my JSPWiki workflow library development continues at a torrid pace.

Bottom line: once we have a decent workflow system in place, I'll open registrations back up. And longer term, we will have more some open identity system choices.

Hmmm.  Interesting thoughts that I want to explore more over the next while.

Before I get to the nitty-gritty, please note that Cardspace and InfoCards do NOT require a client-side wiki or web site to use WS-* protocols. 

The system supports WS-*, which gives it the ability to handle upper-end scenarios, but doesn't require it and can operate in a RESTful mode! 

So the actual effort required to implement the client side is on the same order of magnitude as for OpenID.  But I agree there are not very many open-source options out there for doing this yet – requiring more creativity on the part of the implementor.  I'm trying to help with this.

It's also true that InfoCards require client software (although there are ways around this if someone is enterprising: you could build an infocard selector that “lives in the cloud”).

But the advantages of InfoCard speak clearly too.  Andy Jaquist would find that release of user information is built right in, and that “what you see is what you get” – user control.  Further, the model doesn't expose the user to the risk that personal information will become public by being posted on the web.  This makes it useful in a number of applications which OpenID can't handle without a lot of complexity.

But what's the core issue? 

InfoCards change the current model in which the user can be controlled by an evil site.  OpenID doesn't.

if a user ends up at an evil site today, it can pose as a good site known to the user by scooping the good site's skin so the user is fooled into entering her username and passord.

But think of what we unleash with OpenID…

It's way easier for the evil site to scoop the skin of a user's OpenID service because – are you ready? – the user helps out by entering her honeypot's URL!

By playing back her OpenID skin the evil site can trick the user into revealing her creds.  But these are magic creds,  the keys to her whole kingdom!  The result is a world more perilous than the one we live in now.

If that isn't enough, evil doers armed with identifiers and ill-gotten creds can then crawl the web to see where the URL they have absconded with is in play, and break into those locations too.

The attacks on OpenID all lend themselves to automation…

One can say all this doesn't matter because these are low-value identities, but I think it is a question of setting off on the wrong foot unless we build the evolution of OpenID into it.

It will really be a shame if all the interest in new identity technology leads to security breaches worse than those that currently exist, and brings about a further demoralization of the user.

I'd like to see OpenID and InfoCard technologies come together more.  I'll be presenting a plan for that over the next little while.

 

Firefox support for Windows CardSpace

Via Mary Jo Foley's Unblinking Eye on Microsoft,  here's a piece on a new Firefox plugin supporting CardSpace on Window's Platforms:

A new plug-in providing Firefox support for Microsoft's CardSpace digital-identity framework is now available for public download.

Solution architect Kevin Miller, who played an instrumental role in developing the technology, announced the availability of his Firefox add-on for Windows via his blog.

Why is Firefox support important? Until there is more third-party support for Microsoft's CardSpace, it will be slow to gain traction. But until CardSpace gains more traction, developers will be reluctant to build applications that make use of it. CardSpace, the technology formerly known as InfoCard, is a key piece of Microsoft's proposed Internet-wide identity metasystem.

CardSpace is designed to store centrally an individual's multiple digital identities used to log into different secure sites (not quite – see below). Microsoft built support directly into Internet Explorer 7.0. And CardSpace is one of the elements of the .Net Framework 3.0, which Microsoft introduced alongside Windows Vista and has back-ported to Windows XP and Windows Server 2003.

Miller blogged: “You can download the (Mozilla CardSpace) extension here for now. I'll jump through the hoops over at addons.mozilla.org this week, and hopefully it will be available there soon. I'll post an update when it is there. I've also set up a project over at Codeplex (as mentioned briefly in my first post), and will get the code posted there in the next day or so.”

Scott Hanselman, chief architect with Corillian Corp., a Hillsboro, Ore.-based financial-services integrator, is bullish about CardSpace's prospects. “CardSpace is going to change it all. It’s likely the biggest thing to happen to security since HTTPS. CardSpace changes the game for consumers. It’ll take a few years, but after IE7 and FireFox and MacOSX all have CardSpace implementations – and it won’t take long – we’ll see Identity 2.0 happen,” Hanselman said.

“If you contrast (CardSpace) with the way certificate management has traditionally worked on nearly any OS, it’s significant because it makes secure certificates accessible to my mom. CardSpace and its related specifications make a secure identity experience accessible, both to the user and to the programmer.”

There are a number of other third-party companies and coalitions beyond Mozilla developing CardSpace-compatible providers and support.  Even Microsoft's own Windows Live team is looking to throw its backing behind the effort. The Windows Live ID team is developing a security token service (STS) that supports CardSpace, according to Richard Turner, senior product

(Live ID is the successor to Microsoft's Passport authentication system.)

“We need a proliferation of ID providers,” Turner said. “LiveID is just one of those providers.”

Mary Jo does an admirable job of describing what's at stake here, though I need to remind readers that CardSpace doesnt actually store digital identities centrally – it just stores metadata (pointers) to identity providers.  This may sound like nit-picking, but it's hugely important in mitigating risk. 

The main point is that Kevin has done some great work here.  I've used his plugin with Firefox and it works beautifully.  If you use Firefox on Windows, give it a try.

I'll try to start compiling a list of resources so people can easily see what to download given various configurations and predelictions.

 

Practical Guide To Certificate Installation for the Disinterested

It's a bit tricky to install certificates and keys, and harder still when you want to use the same certificate on both Windows and *NIX boxes.  Most of us don't have to install certificates very often (!), but that doesn't make it any easier! If you're like me you forget at least one of the annoying little essential details.

So partly in light of questions I've been receiving, and partly so next time I encounter these problems I remember how I answered them, I'm putting together what I hope might be a useful “Practical Guide to Certificate Installation for the Disinterested“.  In other words, I'm NOT discussing how to use certificates in production environments.

I'm kind of starting in the middle, but I've got three pieces ready so far.  If you're not familiar with this area, OpenSSL is an open source tool for managing certificates and IIS is Microsoft's Internet Information Server (i.e. Web server).  If you see problems with my instructions, please let me know.

Now for the pithy titles:

I'm also going to tackle the issue of creating InfoCard-compatible certs for testing and developing purposes.  If others want to add other sections let me know.

 

World's leading identity politician

When it comes to dealing with identity, Australia has already “been there, done that.”  In 1987 there was a massive public revolt against a proposed national ID card that imprinted several of the Laws of Identity on the psyche of the nation.

None the less, the country faces the same challenges around health care and social benefits as every other: the need to streamline benefits processing, reduce fraud, and improve information flow where it is vital to the health and safety of individual citizens.

Over the last few years this had led a whole cohort of Australians to think extensively about how identity, privacy and efficiency can all be served through new paradigms and new technology. 

On its second try, Australia went in a fundamentally different direction than it did with its 1987 proposal (reminiscent of others that have hit the wall of public opinion recently in other countries).  This time, Australia started out right – bringing privacy advocates into the center of the process from day one. 

The cabinet minister responsible for all of this has been Joe Hockey, who seems to have a no-nonsense approach based on putting users in control and minimizing disclosure.

Finally!  Our first glimpse of a government initiative that is, at least in its inception, fully cognisant of the Laws of Identity.  Beyond this, instead of swimming with dull proposals based on Berlin-wall technology,  Australia is leading the way by benefiting from new inventions like smartcards with advanced processors and web services that can together put information ownership in the hands (and wallets) of the individuals concerned.

Here's the story from The West Australian

Police, State governments and banks will not be able to demand access to the new $1.1 billion smartcards under new laws aimed at stopping them becoming de facto national identity cards.

Responding to a report to be released today by Access Card task force chairman Allan Fels, Human Services Minister Joe Hockey will announce changes to ensure individual cardholders have legal ownership over them.

In a speech to be delivered to the National Press Club today he says most government and bank-issued cards remain the property of the issuer but in what may be a world first, the new laws will ensure the cards cannot be demanded for ID purposes.

Professor Fels foreshadowed the legislation in June when he warned consumers needed to be given as much control over the card as possible, and that the Government faced major security concerns if it did not protect cardholders from having to produce the card as identification.

Mr Hockey says the legislation will be introduced next year.

The Government will be able to turn off access to health and welfare benefits if the owner of the card is no longer entitled to them.

The high-tech cards, to be rolled out across Australia from 2008, will replace 17 health and social services cards, including the Medicare card, healthcare cards and veterans’ cards.

They will include a digital photo and name but not the holder’s address and date of birth, and the microchip will store certain health information and emergency contact details.

The Government says it will not be compulsory, but has admitted it will be hard to avoid because it will be required for all government services.

Nearly every Australian will need to carry a smartcard by 2010.

In his speech, Mr Hockey will argue that Australia has been a “complacent comfort zone” when it comes to aspects of card technology and security.

“Many other countries, particularly in Europe, replaced the magnetic strip with a microchip long ago,” he says.

He denies the scheme will result in one giant data base.

“Your information will stay where it presently is, the agency relevant to that information, the agency you deal with,” he says.

The Government hopes the scheme will wipe out $3 billion in welfare fraud a year.

Shadow human services minister Kelvin Thomson said the Government had engaged in precious little public debate about the card.

“Concerns include the threat to privacy from surveillance by corporations and governments, as well as the financial plausibility of a Government-run $1.1 billion IT project,” he said.

“In the United Kingdom, the Blair Government has been forced to put their proposed smartcard on hold due to overwhelming public opposition.”

If Joe Hockey's proposal is as enlightened as it appears to be, I hope every technologist will help explain that our current systems are far from being ideal.  We mustn't get too hung up on simply preventing deterioration of privacy through absurdist proposals, because the current bar is already too low for safety. 

We need to follow Australia in being proactive about strengthening the fabric of privacy while achieving the goals of business and government.

Virtual gardens with real-world walls

Here is a fascinating piece from OZYMANDIAS that oozes with grist for the User Centric mill.  This seems to be about walled gardens with barbed wire.  Please don't take what I'm saying as being critical of Sony in order to puff some other company (like, er, my own).  I'm talking about the general problem of identity in the gaming world, and the miserable experience much of the current technology gives us.  I think I should be able to represent my gaming personas as Information Cards – just as I would represent other aspects of my identity – and use them across games (and one day, even platforms) – without linkage to my molecular identity. 

News on the web today is that Xfire is suing GameSpy for how their GameSpy Comrade “Buddy Sync” feature creates friends lists. To quote:

Now Battlefield 2142 is caught up in a legal tangle between rival in-game instant messaging programs Xfire and GameSpy Comrade. On October 16, Viacom-owned Xfire filed suit against News Corp subsidiary IGN Entertainment over its GameSpy Comrade program, which comes on the Battlefield 2142 disc. IGN Entertainment also owns IGN.com, a GameSpot competitor.   

Xfire is claiming that GameSpy Comrade's “Buddy Sync” feature illegally infringes on its copyrights. Buddy Sync retrieves users’ friends lists from other instant messaging programs like AOL Instant Messenger and Xfire, and gives players the option of automatically inviting those friends who have GameSpy accounts to join the users’ friends lists on Comrade.

If you read a bit deeper you find that what's basically being challenged is GameSpy's use of information (friends lists) that has been publicly published by Xfire on their website. Xfire claims that GameSpy's reading of that data is to enable GameSpy to bolster their own friends lists:

In a filing in support of the restraining order, Xfire CEO Michael Cassidy specified how his company believes the Comrade program works. First, Cassidy said it reads the user's Xfire handle from the XfireUser.ini file, then visits a formulaic URL on the Xfire site to get a list of the user's friends (for instance, to find the friends list of Xfire user Aragorn, Comrade would go to http://www.xfire.com/friends/aragorn). The names on that friends list are then compared with a central IGN database of Comrade users’ Xfire handles, and if any matches turn up, the user is asked if they want to invite those people to their Comrade buddy lists.

I am not a lawyer, and can't definitively comment on whether information that's made public in this fashion can or cannot be harvested. My gut is that it's probably kosher – we have plenty of website scraping applications in the wild today that do just this, including best price searching sites. What does fascinate me is how this suit highlights how busted Sony's PS3 online network is, and how companies are fighting to position themselves to take advantage of this financially. Bet that seemed to come out of right field. Wink But here's where I'm coming from.

I wrote earlier about why Sony's enabling of Xfire for PS3 games wasn't as exciting as it might seem. Take a read, and then let's talk about just what the experience of being an online user on PS3 is likely to be like.

So I buy my PS3, bring it home, and go online. The first thing I'm going to be asked to do is create some sort of Sony Network ID. That “Sony ID” will apparently bring basic presence and communication features via the crossbar interface. So far so good. Now I decide to play Insomniac's Resistance, which recently stated the following:

Insomniac's Ted Price: “The buddy list is specific to Resistance. And we decided not to bother people in-game with messages. If you have a new message sent to you while you're in a game, you'll see your “buddy list” tab flashing when you re-enter the lobby after playing a game. The buddy list tab is where you can access your friends, ignore list, messages, etc.”  

1Up (to reader): “Does this mean there's a system-wide friend's list, but you have to compile game-specific friends lists for each online game you participate in? That doesn't make much sense, and hopefully today's event will clear up the situation.”

Yes Virginia, that's exactly what this means. Even though I already have a “Sony ID”, I may have to create a new “Resistance ID” to play. And then start thinking about just how broken the experience is when you try to invite someone to a game. Do you send it via the Resistance UI? What screenname do I send it to? If I want to add you to my “Sony ID” friends list, do I need to send you an in-game message to ask you what your real “Sony ID” name is? What about game invites? How does that work across even just these two IDs?

You think that's bad? Now let's open up a few more games from different publishers. Each of these publishers had to make a choice of what online interface to use – again, because Sony's online network just isn't ready. So they'll choose between writing their own (as did Insomniac for Resistance), or perhaps licensing Xfire, or GameSpy, or Quazal, or Demonware. So now we have five potential networks with different namespaces, and an inherent  lack of ability to communicate (chatting, voice, invites, finding friends, etc.) between them, and even across to just the “Sony ID” namespace. Think we're done? Nope… what happens if each publisher doesn't stick with the same online solution for all of their games? This is very likely as most publishers use different developers – so even across a single publisher, you may find fragmented communities.

The only consistent tie all of these different community fragments has is that a user should always have their Sony ID. That gives you a lifeline to be see friends when they are online… but only in the crossbar UI. Will you even be able to see what game they're playing? What about what network that game uses, and whether that friend is logged into it? How will you get messages in a timely manner? Remember Ted Price's quote above? “And we decided not to bother people in-game with messages. If you have a new message sent to you while you're in a game, you'll see your “buddy list” tab flashing when you re-enter the lobby after playing a game.” Doesn't sound like a user-centric design decision to me.

So… back to Xfire and GameSpy. I said earlier this suit is a direct result of how busted Sony's online network appears to be, and I just described some of the issues you'll likely be facing later this month. Yes, it's targeted at a PC title right now (Battlefield 2142), but that's just noise. What we're really seeing with this suit are online middleware companies trying to position themselves to become the eventual defacto solution that publishers will use. Just as with web search and instant messaging, these companies are trying to get momentum and user base that will cause them to be the “PS3 online” solution of choice. And this suit is simply one of many battles we'll see in this space, especially as PC and console crossplatform connectivity becomes more important in the coming years.

When my role as a player is really valued, I will be seen as owning my own buddy list.  Using zero knowledge technology, it will be possible for me to hook up with any of my buddies’ personas – across various games and without committing sins of privacy.

 

Podleaders Interview for those new to the Laws

Tom Raftery at http://www.podeladers.com/ interviewed me recently for his PodLeaders show (42 mins 15 secs).  Here is his description of what we talked about:

My guest on the show this week is Kim Cameron. Kim is Microsoft’s Identity Chief and as such is responsible for developing CardSpace – Microsoft’s successor to the much reviled Passport. Kim elucidated the Seven Laws of Identity and is developing CardSpace to conform to those laws. If he manages this, he will have changed fundamentally how Microsoft deals with people.

Kim is also responsible for Microsoft recently releasing 35 pieces of IP and promising to never charge for them.

Here are the questions I asked Kim and the times I asked them:

Kim, I introduced you as Microsoft’s Identity Chief, what is your official title in Microsoft? – 0:35

What does the Chief Architect of Identity do in Microsoft? – 01:02

Why is it necessary to have identity products in software? – 01:29

How do I know who I am dealing with on the internet? How is that problem being solved? – 03:56

And you as Microsoft’s Identity Architect are coming up with a way to resolve this called CardSpace… – 07:08

You were saying CardSpace is to be platform independent, I run a Mac, will it run on the Mac? – 15:26

You mentioned a couple of companies, are the offerings from these companies going to interoperate or are we going to have another version of the VHS/BetaMax wars? – 17:45

Audience questions
Rob Burke

Perhaps more than any of the other Vista-era technologies, in order to really catch on, CardSpace requires broad cross-platform adoption. Kim personally is doing a lot to showcase the use of CardSpace’s open standards. What does the broader effort to engage with other platforms and communities look like, and how is CardSpace being received? – 21:10

CardSpace uses an intuitive wallet-and-credit-card metaphor. One of the features of a wallet is that it’s portable – I several pieces of identity with me at all times. I tend to move between computers a lot. What provisions are there in CardSpace for helping me keep mobile (in a secure way)? – 25:07

What happens if your laptop containing your InfoCards gets lost and/or stolen? – 28:00


Dennis Howlett

What’s cooking on the identity managemnt front at MSFT? We’ve been hearing about this on and off for a while – we need progress if we’re not to be weighed down byt having to remember so many usernames and passwords for the servics we consume. – 30:35


My questions again:

Will there be a lot of re-engineering of web apps required to roll out these technologies? – 34:03

And finally you mentioned that this is the first version what can we expect in the next versions and when will they be released? – 39:58

Download the entire interview here
(19.3mb mp3)
Let me make one thing clear about Microsoft's Open Specification Promise: many people were involved, and Microsoft's legal people, along with their colleagues representing open source thinkers aned companies, deserve all the credit. 

Check out the other interviews on the site (I think I'm number 48).  Doug Kaye was number 47, and there are lots of good things to listen to while on the treadmill (physical or metaphorical).

 

Information Cards supported on Community Server

Armand du Plessis at Impersonation Falure writes about his work to add Information Card support to his Community Server:

A couple of days ago I enabled experimental Windows Cardspace support on http://dotnet.org.za/. I mentioned that I'll post the source code and controls but with Tech-Ed Africa and some other work I never got around to posting it.

So now the updated Community Server files is available here and the source code for both the Community Server controls and the underlying ASP.NET controls available here.

To enable Community Server to make use of Information Cards for authentication the following steps are required :

  • Install and configure your site with a SSL certificate. (Make sure it's a certificate issued by a Certification Authority trusted by popular browsers so you don't make the same mistake as me. See this post for more info)
  • Grant access to the certificate's private key to your application pool user. Easiest method to do this is using the winhttpcertcfg.exe utility.
    • winhttpcertcfg -g -c CertLocation -s SubjectStr -a Account
  • Add your certificate's thumbprint to your web.config appSettings section so the Token processor helper class can find it :
    • The thumbprint can be obtained through the MMC Certificates snap-in.
  • Unzip the updated Community Server files over the CS web files. The following files will be replaced so make sure you've backed them up before this step :
    • \Themes\default\Masters\master.ascx
    • \Themes\default\Skins\Skin-EditProfile.ascx
    • \login.aspx

How it works is relatively straigth forward, kudos to the design of the Cardspace web integration and the Community Server SDK. A quick explanation :

The source consists of four core controls :

  1. Adp.CardSpace.InformationCardRequest – A very basic ASP.NET control that takes care of rendering the < object > element used to engage the Identity Selector with the desired claims the Relying Party wants from the Identity Provider. This can either be placed in the head of the page when working together with the InformationCardSubmit control, or as a standalone in a form body.
  2. Adp.CardSpace.InformationCardSubmit –  Another basic ASP.NET control that renders the required script and a button that can be used to engage the Identity Card Selector. It is meant for consumption by higer-level controls that can subscribe to it's OnTokenReady event which is fired when a postback triggered by the ICS happens.
  3. Adp.CommunityServer.Controls.Association – A Community Server control used in the profile section to allow a user to associate an Information Card with his/her account.
  4. Adp.CommunityServer.Controls.CardSpaceLogin – A Community Server control used to authenticate the user using his Information Card instead of the usual username/password.

The claim requirements is expressed through the Claims property on the Adp.Cardspace.InformationCardRequest control. This can be done programmatically or declaratively and the control added either to the page head or to a form body. Adding the control to the page head as done in the Community Server integration allows for fine grained control over when the Identity Selector is invoked without interfering with other form submit buttons on your page.

Below is an extract from master.ascx which embeds a request for two claims, email and PPID, into the page. (By default self-issued cards are accepted but this can be configured through the Issuer property on the control) 

< CS:Head runat="Server">
< meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
< CS:Style id="UserStyle" runat="server" visible = "true" />
< CS:Style id="s2" runat="server" visible = "true" Href="../style/Common.css" />
< CS:Style  runat="server" Href="../style/common_print.css" media="print" />
< CS:Script id="s" runat="server"  />
< ADP:InformationCardRequest ID="_xmlToken" runat="server" Claims-Capacity="4">
< ADP:ClaimDto ClaimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier" Required="true" />
< ADP:ClaimDto ClaimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Required="true" />
ADP:InformationCardRequest>
CS:Head>

 Where the Identity Selector trigger is required the Adp.Cardspace.InformationCardSubmit control is placed. The sole responsibilty of this control is to invoke the Identity Selector and raise an OnTokenReady event which can be consumed by other interested parties. Below is an extract from the Skin-CardspaceLogin.ascx (a Community Server control which uses the InformationCardSubmit control to obtain the encrypted token)

< ADP:InformationCardSubmit CssClass = "CommonTextButtonBig" runat="server" id="csSubmit" />

 That's all that's required to invoke the ICS. To decrypt and extract the token using the very useful TokenProcessor from the Microsoft samples the following code is required to hookup and handle the OnTokenReady event. (This code is in the above mentioned CardSpaceLogin control, a composite control utilizing the InformationCardSubmit control and other default Community Server Controls) 

protected override void  AttachChildControls()
{
submit = FindControl("csSubmit") as InformationCardSubmit;
message = FindControl("csMessage") as StatusMessage;
 
submit.OnTokenReady += new EventHandler(submit_OnTokenReady);


if ((submit == null) || (message == null))


throw new CSException(CSExceptionType.SkinNotSet);


}




The Token helper class takes care of decrypting and extracting all the tokens from the postback. (The token helper class is available in the samples on http://wcs.netfx3.com)


After breaking out the tokens we can access them through the indexed Claims property. All the claims we expressed in the InformationCardRequest control above is available for use in your code.  In the sample below the token's unique id is extracted and assigned to an extended profile attribute in Community Server.




void submit_OnTokenReady(object sender, TokenEventArgs e)


{


try {


Token token = new Token(e.TokenValue);




if(context.User.Email !=


token.Claims[System.IdentityModel.Claims.ClaimTypes.Email]) {




DisplayMessage(ResourceManager.GetString("Association_EmailMismatch",


CSUtil.CsResourceFilename), false);


return;


}


 


context.User.SetExtendedAttribute(CSUtil.CsExtendedAttributeName,


token.UniqueID);




Users.UpdateUser(context.User);


 


DisplayMessage(


ResourceManager.GetString("Association_Success",


CSUtil.CsResourceFilename),true);


 


}


catch (Exception e1) {


string displayMessage = ResourceManager.GetString("Association_GenericException",


CSUtil.CsResourceFilename);


 


CSException e2 = new CSException(CSExceptionType.UnknownError,


displayMessage, e1);




e2.Log();


 


DisplayMessage(displayMessage, false);


}


}




Some limitations in this implementation is that it currently don't detect whether or not the browser supports Infocards. Also triggering the Identity Selector through script currently don't seem to be supported by the Firefox Identity Selector plug-in.


Currently the implementation on dotnet.org.za still suffers from the use of the Starfield SSL certificate which requires users to first import the Intermediate Certificate as a trusted issuer before Cardspace will accept it. This will be rectified soon.


Links:






	


	
	






	
	

		
Privacy and Identity – IGF workshop outcomes
	


	

		
From the Internet Governance Forum, via Ralf Bendrath's blog: 


The workshop on privacy and identity we held together with the LSE information systems group this morning sparked an interesting discussion.


Christian Möller gave some examples of how privacy is not only important in itself, but how it also is a necessary condition for freedom of expression.


Microsoft’ Jerry Fishenden presented their InfoCards concept and the “7 Laws of Identity” as one approach on how to handle user data based on different credentials. While most of the panelists agreed that this is a good basis for a start, and especially welcomed the company's recent efforts to make it more privay-friendly, Jan Schallaböck and Mary Rundle pointed at one major drawback: Once you have sent your personal information to a company – no matter if through InfoCards or another system – you can not control what happens with it afterwards.


Jan, who is with the data protection authority of the German land of Schleswig-Holstein, therefore presented the ideas, concepts and systems developed in the EU-funded Privacy and Identity Management in Europe (PRIME) project as an alternative.


Their model is that user data given to web service providers will have “sticky privacy policy” attached to it in the form of meta-data. This meta-data will move with the personal data and can help ensure that it is only used or tranferred in a way the user has agreed to.


Mary from NetDialogue suggested (having) a similar way as the Creative Commons license: Privacy Policies should be human readable, lawyer readable, and machine readable. The advantages would be that the users can better decide how they “licence” the use of their data to other parties. Mary even presented a very nice series of icons that symbolize different use policies.  This approach might be one way to address the failure or “myth of user empowerment”, as Ives Poullet called it.


Stephanie Perrin, research director at the Office of the Privacy Commissioner of Canada, finished by saying that the privacy community has to become much more involved in international technical standardization processes. As always, time was too short. Therefore, we will discuss a collaborative follow-up process later this evening.


Actually, the “sticky privacy policy” notion can be implemented by identity providers using version 1 of Cardspace – it doesn't limit the token types that can be exchanged.  A new type of token that includes metadata about use policy is a good example of why this flexibility is useful.  I support the idea.


Maybe Jan Schallaböck and Mary Rundle are aware of this, but are talking about the self-issued identity provider used to “bootstrap” Cardspace.  In v1.0, it does not have this kind of metadata built in to it. 


I look forward to collaborating with Mary and Jan to create the kinds of visual and metadata systems now being discussed.  I don't actually see PRIME as being “alternative” in any way to the work I've been doing – we have the same goals.