There's an interesting new identity blog on the scene by Pete Rowley.  He's an open source kind of guy – positive too – and picked up on my recent InfoCard token tutorial:

“I have been pretty busy recently, which is why Kim Cameron managed to sneak by a tutorial and demo of InfoCard that also revealed the WordPress relying party PHP code for the LAMP stack. It includes a short demo video which walks through how InfoCard works when logging in to a site that is useful to review before actually reading the tutorial. Excellent!

“Now if I might be so bold Kim, could we have the code released under an open source license.”

Thanks, Pete.  In terms of releasing code, I truly hope the industry hasn't arrived at the point where you need licensing for a tutorial. 

The bottom line?  I put my ideas out there and invited everyone to use them in any way that would advance identity on the web.  I hope that's straightforward enough. 

Anyway, I like Pete's pragmatic and multi-sided approach.  Here's another example:

User-centric != user asserted

Johannes Ernst says “If user-centricity is really what we are after, it follows that I am my own identity provider in many circumstances, doesn’t it?” I think the answer to that is, to begin with. Digital identity for the internet is a bootstrap problem. Not much can be demanded or expected to begin with, and third party asserted claims are definitely a lot to ask right now.

However given a generally accepted system of identity claims assertion for the internet, I would expect that over time many of those claims would be expected to be backed up by a third party. For sure, some things will never require that: my favourite movie and other such trivia. But a lot of claims are generally self asserted now because they have to be, like my nationality, my employer, my professional affiliations, people I know, and many others may well naturally become third party claims about me, and expected to be.

User-centric identity does not imply user asserted identity, that is merely the initial expected state in order to garner adoption. Nothing more. I fully expect there to be higher level of trust in the identity claims asserted in the future, not merely the status quo.

  I totally agree.



Computer Security Alert has done a nice frontpage feature on “What InfoCard is and isn't” in its May 2006 issue.  The Alert is normally only available to members, but Robert Richardson has given me permission to let you download and reprint the PDF version, complete with sidebars – or you can read the main part of the story here: 

There’s little doubt that the Microsoft marketing engine will get itself geared up to tell the public at large what InfoCard “is,” but in the meanwhile, getting a handle on the next major security-related software introduction is remarkably difficult. It’s a slippery topic.

The place to start, however, is with the diagram below from an overview of the “Identity Metaverse” by Microsoft’s identity guru Kim Cameron.

The box at the very bottom of the diagram is you, the subject. If you go to a Web site or an application that requires you to establish that you’re authorized to use its services (where in the past you’d have been challenged for a username and password), you’ll instead be shown an interface where you can choose from what appear to be traditional “ID cards.” Simply put, that interface is InfoCard. That’s it.

Or, at least, that’s how to draw a line around it that differentiates it from everything else. Obviously, there’s more to it than that. For one thing, it’s running in a different security context than the rest of your applications on whatever operating system you happen to be running. It’s supposed to be completely cordoned off in terms of memory access and the like. Other applications (and, say, viruses that have installed themselves unbeknownst to you) can’t see memory that’s being used by the InfoCard interface.

Cameron does note that “if you get a rootkit, you’re in trouble. But Vista makes it much less likely that you’ll get one, because you almost always run in your own context (e.g. not at ‘root’ privilege). A virus caught in your user context cannot see your InfoCard screen or memory.” There are other security gains as well, Cameron notes: “InfoCard protects against keyloggers because typing of shared secrets becomes obsolete. And social engineering attacks are mitigated because Web sites no longer control the user experience. Finally, sensitive information like a credit card number is never stored on the PC, or visible to a virus running there.”

InfoCard presents your various credential possibilities to you in the form of “cards,” so not too surprisingly there’s also a mechanism for generating your own self-signed InfoCard and then issuing encrypted tokens when the card is used (in other words, there’s a tool for making yourself into an ID Provider, which Microsoft’s documents often refer to as an IP, but which we’ll call an IDP in the hopes of not creating confusion around the already overloaded “IP” acronym)—this too is part of InfoCard.

Finally, there’s a strong sense that this is what Microsoft thinks every operating system’s authentication interface should look like: an isolated page where you pick from your various ID cards. This really isn’t about Redmond wanting everything to look like a version of Windows—in fact InfoCard is trying to look a bit different than the rest of the Windows Vista operating system. Rather, it’s supposed to look different from everything else altogether, so that you the user realize you’ve entered one of those transitional moments where you may be handing over some of your personal information.

But other than these pieces, everything else in the identity management universe is something other than InfoCard. The part where the InfoCard interface talks across the network and exchanges information isn’t InfoCard, but the WS-Trust standard. The server that creates a token that attests that you’ve got authorization to use a certain service isn’t InfoCard either, but something like a certificate authority (CA) or perhaps something a little more old-fashioned like a Kerberos server. The primary thing that InfoCard does is allow you to choose which of several identities you want to use in a given situation where you’ve been challenged for ID.

The “cards” represent your various identities. The “cards,” it’s vital to note, don’t contain information about you, per se. You won’t find your name and address or your social security number stored in one of your cards. Instead, enough metadata is stored that when the appropriate moment arrives, InfoCard can communicate to the IDP to say who you’re supposed to be. The IDP will confirm this by challenging you in one way or another (doesn’t matter to InfoCard what that way is—it’s completely agnostic in this important respect—but it may very well matter to the Web site that is requesting the information).

So the IDP plays an important role in this, but as we mentioned above, may in some cases actually be you, as self-provider of a card (this is the situation you’ll find yourself in at a Web site that asks for a login name or e-mail address but otherwise doesn’t care who you are). The other player (besides you, the user of all this splendor) is the Web site that wants to know who you are in the first place. In today’s pre-InfoCard world, this site would normally challenge you for a username and password and check up on your assertion that you are in fact you on its own steam. With InfoCard, this site becomes a Relying Party (RP) and actually gets its assurance that you are you by way of the IDP.

There are early releases of InfoCard in the hands of developers, and blog reports so far make it clear that it’s pretty fragile just yet—it takes just the right combination of operating system release, Explorer browser preview and InfoCard code to make the thing work. It does work if you get it all right, but would seem that there are only a handful of non-Microsoft people in the world who’ve managed to InfoCard their way into a site (such as Cameron’s As Cameron puts it, “it’s new, it’s evolving quickly, and it hasn’t stabilized yet.”

What happens bat game time

So with the various pieces in place, we can walk through the mechanics of an InfoCard transaction. We’ll talk here about going to a Web site, but clearly there are other use cases, such as internal applications that directly invoke the InfoCard interface to authenticate the user with an intranet application, perhaps built on a service-oriented architecture.

Arriving at the site

I’m an InfoCard-enabled user and I arrive at my bank, which has now implemented support for this interface. My arrival causes a page to be sent to my browser, as would always be the case. Indeed, the page my still contain all the usual paraphernalia for a traditional login.

Triggering the InfoCard process

What’s also in the HTML page that is sent to my browser, however, is an HTML OBJECT tag. The browser, which also has to be up-to-date, recognizes that this object has a “type” parameter that identifies it as an InfoCard request. It therefore triggers the InfoCard dynamic link library (DLL) module. The stage is set and the screen dims (I’m not kidding, it really does dim—another way of differentiating this process from normal computing activities as well as a way of making the process harder to spoof).

InfoCard gears up

Among the parameters passed to the DLL from the OBJECT tag are the claims about the user that need to be proven. These might be things like the user’s name, but on the other hand, the Web site may only need to know some anonymous piece of information, such as that the user is older than 21. Generally, the site should only have requested what it needs to know. The DLL compares the claim requests to the user’s InfoCards to see what claims can be met by which cards, and then displays those that can meet the request (others are visible but grayed out).

The user picks a card and is challenged

This is an important moment if you think about it. The user may use any card that meets the requirements of the Web site’s request. A user might maintain different personas with different sets of proofs for different contexts. With the selection made, the DLL contacts the IDP via WS-Trust. The IDP then does whatever it needs to do to authenticate the user. Possibly it asks for a username and password; possibly a one-time password must be used or some biometric proof supplied.

A secure token is issued and reviewed

Assuming the user successfully authenticates with the IDP (not the Web site, which is the RP in this scenario, it’s important to keep in mind), the IDP places the appropriate claims into an XML document and then uses the RP’s public key to encrypt them. This is sent not to the RP but back to the user’s InfoCard process, which displays the claims that are about to be sent so that the user can review them.

The approved claims are forwarded

If the user is comfortable with passing the information in the claims along to the Web site, they press a Submit button and the encrypted token is forwarded to the RP, which will now grant access to the user. The Web object in more detail Jumping back a step, notice that the mechanism for invoking the InfoCard interface really is pretty much as simple as it sounds. A snippet of HTML code is added to the rest of the material in the Web page, as in this example from Andy Harjanto’s Infocard Weblog.

Notice that this example shows a Web site that requires a SAML assertion for authentication. The RP may not get to dictate that I’ll provide my credentials or that I’ll provide a specific credential if there are several that meet the need, but it does get to dictate what kind of credential must be provided if it’s to be considered sufficient. Specifically, the RP can make requests concerning:  

  • The issuer;
  • The type of token that will be returned;
  • What claims must be vouched for by the token;
  • Requirements regarding the kind of proof used (symmetric, public key, etc), the size of the key used in authentication and other such details as might be required for high-security scenarios.

It’s worth underscoring that the RP only receives proofs of the specific claims it requests, not access to any kind of full profile of data about the individual. The user (or, at any rate, not the RP) gets to choose where data used for this particular user’s authentications are stored. This ability to separate authenticated claims from specific identities is potentially a huge gain for Internet privacy. This would be true even in relatively small ways: one can imagine being able to post comments at a blog site anonymously, but only after proving that one had the reputation (from actions at other sites) of never posting spam. Anonymity is preserved while the social good of keeping out bad actors is upheld.

On the other hand, we shouldn’t overstate how much may be gained in the real world—RP’s may still very well want a full complement of information, including name, address and credit card numbers, before selling you their products. And once they’ve got the information, they may well decide to store it, even insecurely.

As an aside, Microsoft has taken the interesting step of essentially not providing any kind of normal application/programming access to InfoCards. They are stored in their own little world; there is no API to access them. The effect of this is that cards don’t get deleted or modified or added without the user’s direct involvement, because these steps must be taken through the InfoCard interface.

For the InfoCard interface to be invoked, of course, there has to be some software resident on the user’s system. At present, it gets there by way of a purpose-built software file (a DLL file) that has to be expressly loaded along with Internet Explorer 7. These things will be part and parcel of Microsoft Vista, when it’s released next year, but users who stick with XP will have to download these pieces in order to use InfoCard.

Given that migration to Vista is bound to take place at a measured—perhaps even downright reluctant, depending on the vicissitudes of the market—pace, one question is whether the requirement for additional specialized software will make Web site developers reluctant to get involved. Obviously, they can use pre-existing login routines for users who don’t have InfoCard capability on their machines, but having two systems will just complicate life. Cameron says it’s not all that much more complicated, however: “We’ve taken this into account so the changes to a Web site are absolutely minimal.”

Organizations may or may not decide that dealing with InfoCard is worth the trouble—it will have to move beyond its current proof-of-concept stage before anyone can decide—but one thing organizations don’t have to do, should they opt to use InfoCard, is run Windows servers. From the “Microsoft’s Vision for an Identity Metasystem” white paper:

    Non-Microsoft applications will have the same ability to use “InfoCard” to manage their identities as Microsoft applications will. Non-Windows operating systems will be able to be full participants of the identity metasystem we are building in cooperation with the industry. Others can build an entire end-to-end implementation of the metasystem without any Microsoft software, payments to Microsoft, or usage of any Microsoft online identity service.

Just to prove that this is so, Cameron, who’s in charge of the InfoCard project, moved his over to non-Microsoft software (completely so: he’s running the classic, open-source LAMP stack). The blog is running on WordPress (also open source) and he’s written his own PHP scripts to handle the InfoCard login process. By Cameron’s own admission, it’s still a bit buggy and it lacks a certain degree of polish:

    Some of the user experience is still pretty “basic”. Like what happens if you click on InfoCard login and don’t have InfoCards installed. When I have some time I’ll make that take you to a page that tells you what InfoCards are, how they work, how to install them, and that sort of thing. But for now, the behavior should appeal to lovers of cryptic error messages.

So at least in theory, the Linux and Macintosh systems of the world could implement compatible identity selectors, RPs and IDPs that were all compatible with InfoCard. And, really, it’s only that it’s Microsoft doing the developing that makes it seem like InfoCard is the driving force here. In point of fact, InfoCard’s mission is to work with WS-Trust, an open standard (we could quibble about how open it is, but at least there’s nothing preventing anyone from using it). So the open standards for identity, such as WS-Trust, are really the driving force behind InfoCard. In any case, identity management seems to be entering something of a 2.0 phase, and there’s no question that InfoCard will play a significant role in whatever that turns out to be. — R.R.


This sounds like the best thing since sliced bread:

Ever feel like Chicken Little? Wonder if letter grades, color codes, and/or duct tape are even a tiny bit useful? Cringe at the subjectivity applied to security in every manner?

If so, MetriCon 1.0 may be your antidote to change security from an artistic “matter of opinion” into an objective, quantifiable science. The time for adjectives and adverbs has gone; the time for numbers has come.

MetriCon 1.0 is intended as a forum for lively, practical discussion in the area of security metrics. It is a forum for quantifiable approaches and results to problems afflicting information security today, with a bias towards practical, specific implementations. Topics and presentations will be selected for their potential to stimulate discussion in the Workshop.

Workshop Format

MetriCon 1.0 will be a one-day event, Tuesday, August 1, 2006, co-located with the 15th USENIX Security Symposium in Vancouver, B.C., Canada. Beginning first thing in the morning, with meals taken in the meeting room, and extending into the evening.

Attendance will be by invitation and limited to 50 participants. All participants will be expected to “come with opinions” and be willing to address the group in some fashion, formally or not. Preference giventothe authors of position papers/presentations who have actual work in progress.

Each presenter will have 10-15 minutes to present his or her idea, followed by 15-20 minutes of discussion with the workshop participants. Panels may be convened to present different approaches to related topics, and will be steered by what sorts of proposals come in in response to this Call.

Goals and Topics

The goal of the workshop is to stimulate discussion of and thinking about security metrics and to do so in ways that lead to realistic, early results of lasting value. Potential attendees are invited to submit position papers to be shared with all. Such position papers are expected to address security metrics in one of the following categories:

– Benchmarking
– Empirical Studies
– Metrics Definitions
– Financial Planning
– Security/Risk Modeling
– Visualization

Practical implementations, real world case studies, and detailed models will be preferred over broader models or general ideas.

How to Participate

Submit a short position paper or description of work done/ongoing. Your submission must be no longer than five(5) paragraphs or presentation slides. Author names and affiliations should appear first in/on the submission. Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be submitted to MetriCon AT

Presenters will be notified of acceptance by June 15, 2006 and expected to provide materials for distribution by July 15, 2006. All slides and position papers will be made available to participants at the workshop. No formal proceedings are intended.


MetriCon 1.0 will be co-located with the 15th USENIX Security Symposium (Security ’06).

$200 all-inclusive ofmeeting space, materials preparation, and meals for the day.

Important Dates

Requests to participate: by May 15, 2006
Notification of acceptance: by June 15, 2006
Materials for distribution: by July 15, 2006

Workship Organizers

Andrew Jaquith, Yankee Group, Chair
Adam Shostack,
Gunnar Peterson, Arctec Group
Elizabeth Nichols, ClearPoint Metrics
Pete Lindstrom, Spire Security
Dan Geer,Verdasys

Funny, I was just at a conference today arguing that the truth is in the quantitative studies.  There are some wonderful people putting this together – it seems full of promise.


Adam at Emergent Chaos has taken a stab at demystifying InfoCards:

For every product, there are thousands of sentences which result in the reply “well, why didn't you just say that?” The answer, of course, is that there are thousands, and often its not clear which is the right one. For me, the useful sentence is that ‘Infocard is software that packages up identity assertions, gets them signed by a identity authority and sends them off to a relying party in an XML format. The identity authority can be itself, and the XML is SAML, or an extension thereof, and the XML is signed and encrypted.’

Hmmm.  Thanks Adam.  No cigar, but we're getting closer.

Actually, the relying party states what assertions it wants, the Identity Selector allows the user to control what identity provider to use, and the identity provider packages up the identity assertions, signs them and sends them to the relying party in a token format.  The identity authority can be something local to the identity selector, or something reachable over the internet, and the token format can be XML, including SAML, or anything else.  The whole visual metaphor and user experience is called InfoCard, the protocols are WS-Trust, and the mesh of interoperating parties and technologies are the Identity Metasystem.

It feels like together we have put together a pretty good definition.  Comments?

Why didn't you just say that? (Actually, Kim Cameron says just about that in the video linked to in “The Infocards For PHP Tutorial.”)

True.  Why didn't I just say that?

More seriously, I'm unsure if Infocard is the software, the protocol, or some combination thereof. But I do have a much better understanding of how it works, so I'm glad to have watched the short movie demo.

Yes, I've been sloppy about all of this, and the fact that InfoCard is just a code name doesn't help either.  Anyway, InfoCard is really the visualization and experience that represents an identity within an identity selector. 

A couple of thoughts:

  • First, Stephan Brands of Credentica has comprehensively analyzed the privacy issues in this sort of scheme in his book, “Rethinking Public Key Infrastructures and Digital Certificates; Building in Privacy.” The essential point to be aware of is that the certifying authority can track every site you visit. Infocard includes a self-signing authority, so you're aware of every site you visit. If web sites start demanding certificates from other organizations, they have a deep view into your web activities.

See my comments below…

  • The demo code relies on Javascript. Is there anything other than the “onClick” that requires it? Javascript dramatically expands the browser's attack surface, helps phishers confuse users, etc. It would be good for Infocard to work without relying on it.

I need to think more about this.

  • Finally, there's a card which is greyed out, which Kim helpfully explains is greyed out because it doesn't include an email address. I'm expecting there's an easy way for the user to discover this?

Anyway, I'm glad that Kim produced the video, and if you've been like me, watching and not having time to dig in, go watch it.

I'm happy the video is helping clarify things.  InfoCards are really easy to use, but hard to explain to a technical audience.

No tracking 

I have to correct Adam's assertion that “the certifying authority can track every site you visit”.

The InfoCard system supports what we call “non-auditing” identity providers. As I say in the tutorial accompanying the video:

The InfoCard system supports two classes of Identity Provider.

  • “auditing” identity providers know what Relying Party the subject is visiting. They therefore encrypt directly to the relying party.
  • “non-auditing” identity providers, are not, for privacy reasons, told the identity of the relying party. Therefore, they can't encrypt for it. Instead, they send the token to the InfoCard client, which in turn encrypts it for the Relying Party.
  • Non-auding identity providers don't have visibility into the sites you visit.

    Stephan's work – which I would like to see incorporated into the InfoCard framework – adds a proof-key to the bearer semantics currently used for non-auditing providers. This strengthens the proof of ownership of the token and is a good thing, but it doesn't affect the privacy of the system.





    This tutorial includes a demo, an explanation of how Self-Issued InfoCard identity tokens work, and sample PHP code allowing you to accept these tokens at a web site.

    One of the key goals of InfoCard and the Identity Metasystem is to put the release of identity information under the direct control of computer users.  At the same time, the system respects the right of a web site to say what information it requires to grant entry.  The accompanying demo shows how InfoCards help bring the two sides of this equation together in a way that accords with the Laws of Identity.

    Information Card technology can be used to manage the exchange of any kind of token.  CardSpace&#39s self-issued tokens use the SAML format.  With this format, identity information sent to a site is “signed” to guarantee that it really comes from whoever originates the “claims” in the identity token.  Then, to protect the user&#39s information during release, it is encrypted so only that site can get at it.

    How can the identity provider encrypt the information destined for your web site?  You need a public key and certificate.  In the current version of InfoCard this has to be an SSL certificate (mine cost me under $20), and your web server needs to be able to support https.  Identity tokens sent to you will be encrypted under the same key your system uses for https.  If people need help with this, let me know and I&#39ll add instructions to this tutorial.

    I wrote my sample code in PHP 5 (I had a 4.2 version running at one point, but didn&#39t want to keep two versions going).  If you wonder why I chose PHP, I wanted it to be clear that InfoCards are not Windows-specific.  You need to make sure your version of PHP has the mcrypt and openssl libraries enabled.  (By way of example, these libraries are part of the default environment at TextDrive, my excellent web site host.)

    I would suggest you approach this tutorial as follows:

    1. Watch the demo.  Use this version for Windows Media Player.  (If your system complains that it requires the Techsmith Screen Capture Codec [TSCC], pick it up here.)  If you can&#39t use TSCC, try the much fatter Quicktime version (doubleclick on the demo to start it).
    2. Learn about the Encrypted SAML Token, and then how to decrypt it to reveal the signed token.
    3. Learn about the Signed Token, and how to verify it.
    4. Look at the sample HTML page and mainline that constitutes the demo.

    You can download the sample PHP files here (I updated them to V3 in June 2007 to make the code compatible with the shipping version of Vista, and at the same time embrace the new OASIS claims names.)

    I&#39ll be evolving this work over the next little while, so let me know about anything that is unclear or not pitched at the right level.

    People have asked if I&#39ll be putting this tutorial into .pdf format.  I will, once I&#39ve received a bit more feedback.  In particular, I&#39m hoping some PHP gurus will look things over – this is my first PHP project.

    I&#39ve also been asked what intentions I have for this code. My only goal is to share information as widely as possible.


    Check out this amazing piece at Computerworld.  It boggles the mind.  To whet your appetite:

    APRIL 12, 2006

    Broward County, Fla., Maricopa County, Ariz., Fort Bend County, Texas. Three counties separated by hundreds of miles with something in common: They’re among potentially hundreds of counties in several states that in recent years have made Social Security numbers, driver's license information, bank account numbers and a variety of other personally sensitive data belonging to residents available to anyone in the world with Internet access.

    The exposure follows the failure to redact sensitive information from land records and other public documents posted on the Internet and makes county Web sites a veritable treasure trove of information for identity thieves and other criminals, according to a number of privacy advocates.

    “These sites are just spoon-feeding criminals the information they need,” said B.J. Ostergren, a privacy advocate based in Richmond, Va. “But no one appears to be seeing it and nobody’s changing the laws,” she said.

    Among the pieces of personally identifiable information from county Web sites made available to Computerworld by Ostergren and other privacy advocates were: Rep. Tom Delay’s Social Security number on a tax lien document; the Social Security numbers for Florida Gov. Jeb Bush and his wife on a quit claim deed from 1999; driver’s license numbers, addresses, vehicle registration information, height and race of individuals arrested for traffic violations; names and dates of birth of minors from final divorce decrees and family court documents; and even complete copies of death certificates with Social Security numbers, dates of birth and cause of death. (The Social Security numbers for Bush and his wife have been redacted and are no longer available online.)

    “All of this information is available to anyone sitting in a cafe in Nigeria or anywhere else in the world,” said David Bloys, a retired private investigator who publishes a newsletter called “News for Public Officials” in Shallowater, Texas. “It’s a real security threat.”

    The article includes a calming quote from Darity Wesley, CEO of Privacy Solutions, a privacy consultancy for the real estate industry based in San Diego.

    “There’s a real need to keep the information flowing,” Wesley said, adding that while there’s a real need to protect data “at all costs,” there’s little evidence so far that the public availability of personal information on government sites has contributed to identity theft. For most identity thieves, the effort involved in sifting through millions of public records for sensitive information is simply not worth it, she said.

    “There’s a lot of value in public records, and shutting down access to them” over privacy concerns would be a step backward, she said. “Rather than wrap a lot of fear and sensationalism” around the issue, what is needed is an informed discussion of the issue by legislators and privacy advocates.

    This is a good example of how simply transfering a manual process to the virtual world can result in a whole new level of invasiveness and threat.

    “I understand people’s concerns, but a lot of this information has been freely available for public inspection since Plymouth Rock,” said Carol Fogelsong, the assistant comptroller for Orange County, Fla.

    Even so, privacy advocates say the move to post public records on the Web without removing personally identifiable information has greatly broadened access to sensitive data and the potential for misuse. “The simple truth is these records were safe in the courthouse for 160 years,” Bloys said. Now, all it takes is Internet access and a very rudimentary idea of how to look for data to find all sorts of information, he said.

    Ostergren, for instance, claims to have harvested more than 17,000 Social Security numbers simply by “messing around” in county Web sites over the past two years. Among the countless nuggets Bloys turned up was the complete medical history of a terminally ill county official.

    Finally, if you worry that this type of attack seems like too much work for an identity thief, console yourself:

    It is not always necessary to search for data, since online records often can be purchased in bulk for a fraction of what it would cost to buy them from a courthouse, Bloys said. One example: Fort Bend County, Texas, last year sold to a Florida company every document ever filed with the county clerk’s office — estimated to be around 20 million — for roughly $2,500. Bloys wrote about the transaction in his newsletter in December. Fort Bend County officials did not immediately return a call seeking comment.



    I&#39ve been promising to share the sample code I wrote to InfoCard-enable my site.

    Working on this, it became pretty clear that I needed to explain how tokens work before I could explain how the related code works.

    And then, since few people so far have access to InfoCard bits compatible with my site, I saw that I needed to do a demo of what the user experience would be, showing how InfoCards actually work.

    Finally, thanks to the review work of a number of colleagues across a number of different companies, I have a Simple InfoCard Tutorial and Demo ready for you to try out.  Watch the five-minute demo, and then follow this link into the tutorial.

    Are you using Windows Media player?  Then use this version of my demo, encoded with the Techsmith Screen Capture Codec (TSCC).  If your system complains that the codec isn&#39t installed, it is totally worth picking it up here.  It does a tremendous job of compressing demos.

    If your player doesn&#39t support TSCC, I hope the Quicktime version will help.  I found I had to download the whole file, then click on the icon to open Quicktime, and then double click on the demo image to make the demo start playing.  Am I doing something wrong?  The biggest drawback seems to be that the encoding is four (4) times larger than the TSCC version.  But hey, it works, and I like the way you can drag the progress bar to jump around within the demo.

    Thanks to Robert Richardson for helping me understand the codec issues.  If others have advice for me, please send it, since I want to do more demos in the near future.

    I&#39ll be evolving this work over the next little while, so let me know about anything that is unclear.  I&#39ll also add some demos of what it looks like using InfoCards on  the compatible sites that have been created by Chuck Mortimer and Ashish Jain.

    Once I get more feedback on what can be improved, I&#39ll assemble the tutorial into .pdf format, and make a zip for downloading the samples, .

    Someone has asked me what intentions I have for this code.  My only goal is to share information as widely as possible.



    I've heard many positive comments about Pam Dingle's talk on “InfoCard in the Enterprise” at the Directory Experts Conference in Vegas.  Unfortunately I couldn't get to Vegas – but here's her recent post.

    Things went along just swimmingly last night at my “Infocard in an Enterprise Context” talk at the Directory Experts Conference. There were many insightful questions from the audience, and afterwards, it warmed my geeky little heart to see Stuart Kwan surrounded by crowds of administrators, all wanting to give feedback and have questions answered.

    There were some very interesting topics brought up during the discussion, which I want to capture before I forget. The most discussed topics surrounded that of “card proliferation”. If you end up having as many different managed cards on your desktop as you do cards in your physical wallet, does that become easier or harder to use than regular username/password combinations?

    It is a really good point. A great example was brought up, which was identification cards for gambling establishments. What if you have 20 membership cards for 20 casinos? There are two ways that those casinos might want to do the infocard thing: either they could give you a managed card with that information in it, or they could register your self-asserted card.

    In the first case, you literally would end up with 20 different cards. Remember though, in that case the gambling establishment would be requiring an exact issuer, so ALL the cards in your wallet would be greyed out except the right one, and that the same card would always be used for transactions with that site, so it would always pop up at the top, with the “you used this card last time, would you like to use it again? message”. In the second case, you could create a “gambling card” that could be registered at as many sites as you wished. You could do this safely, because nothing in the information stored in the infocard is specific to any one of the gambling institutions, it is just personal contact information. Instead of you giving them your membership number, you are giving them your PPID, which is associated with your membership number at the gambling site. By doing so, you have completely removed any data from the card that would be of interest to steal, or that could be accidentally given away during the process of using the card at multiple sites. Remember that a PPI is a calculated identifier that is different for every Relying Party.

    I think that at least in the beginning, that 2nd case will be more common. However, users themselves will not be able to choose what kind of card the Relying Party demands, and besides, the root point of the original question remains. How many cards do YOU have in your wallet? How many username/password combos have you, over the years, accumulated? If Infocard really takes off, there is no doubt that people will begin to accumulate infocards, even if they work hard to keep their cardsets small.

    I can’t speak for MS of course, but I’m pretty sure that the Infocard team would be delighted to have this technology become so popular that they have to race to get rid of the currently existing card limit (I know there is one, can’t remember what it is) and implement mass-management tools for the interface sooner rather than later (-:

    Another discussed topic was the idea of having cards that had some controlled fields and some open fields. That one is a topic for a whole other conversation, and a very interesting concept.

    Lastly – Dave Kearns asked me what about my presentation was “user-centric”. I replied “nothing” as I was specifically addressing how the identity metasystem could be locked down and controlled/audited/managed centrally to satisfy business needs. I think that perhaps that answer was flippant — users still get to see what of their information is being passed in the enterprise, and they can also choose which corporate credentials they wish to use for what corporate resources — this is still an increase in choice and visbility to what they have now.

    If you were there and if you are interested in trying this technology out, here is a uber-quick set of instructions and gotchas:

    • Although infocard will run on both W2K3 and XP sp2, I suggest using XP sp2, as IE7 beta previews are not yet supported on W2K3
    • Getting the right version of IE7 is *critical*. I don’t know all the version numbers, but the version I have works – IE7 Beta preview 2. There was another version following that which does NOT work, so be careful. If you can’t afford the time to be wrong, let me know and I’ll make sure you get a working version.
    • Don’t use a host system that you have any attachment to. If you want to follow the CTPs as they come out, you will almost certainly have to start from scratch (for example, moving from the Jan CTP to the Feb CTP required a vanilla install). Use VMs if you can.
    • Apparently (and I haven’t even tried it yet, it is that new), there are now TWO Relying Parties on the internet that you can go to with your new Infocard client, Kim Cameron’s Identity Blog and Chuck Mortimore’s Java-based Relying Party.

    Thanks again to everyone who attended, I hope that y’all had fun.

    Update: Jef comments that IE7 version 5335 fails, and that he got version 5299 to work. I also know that Rohan Pinto had trouble with version 5299 and had to resort to 5296. No matter what, it seems that 5335 is a no go, so I hope that helps! Thanks Jef.

    At this point, I think the best thing to do is get the MIX06 bits if you want to experiment with the InfoCard sites.  I'm definitely publishing my PHP sample code and tutorials this week, so stay tuned.



    Jimmy Atkinson has written to tell us about a series he's involved in at Credit Card Blog  “that may interest readers of Identity Weblog. It's the Top Five Credit Card Scams. Each day this week, we're covering a different scam and providing tips to consumers as to how they can protect themselves against identity theft and credit card fraud.” 

    The site will definitely give you things to think about.  I don't know a lot about  Maybe Jimmy can help us to understand more.

    Anyway, here is a sample – the recent posting on “skimming”:

    One of the most insidious forms of credit card fraud occurs with a little device known as a skimmer. Skimmers are the size of a pager and can be carried by a scam artist to swipe your credit card and steal the information needed to create a counterfeit card with your name on it. Here’s how it works: You pay at a restaurant or other business and the clerk takes your card. In the back, the clerk swipes your card for the purchase and then swipes it secretly into the skimmer, which records the name and numbers.

    The numbers in the skimmer can be downloaded into a computer and emailed anywhere across the globe. They are then used to make fake credit cards that are used by thieves in Europe, Asia, Latin America, and the US. Skimming is responsible for over $1 billion in losses each year.

    Skimmers can also be placed on some older ATMs so that when you swipe your own card, the information is stored in the tiny bug and then retrieved at a later date by the scammer. To protect yourself, keep an eye on your credit card bills. Watch for any unusual activity and report it immediately. Also shred all your statements so that the numbers cannot be stolen.

    When out and about, keep a close eye on your credit card as well, and report any suspicious activity to the Federal Trade Commission.

    It all just shows how hard it is to change an infrastructure once it's in, no matter how many flaws it has.  It's the problem of exposing your secret (as happens with north american credit cards) rather than using your secret to prove something.  InfoCards give us a way to fix this in the online environment.  The payment identity provider does not need to release a long-term credit card number – just a one-time approval (potentially modelled as a credit card number for compatibility purposes).