A while ago I mentioned I had written some PHP code that would InfoCard-enable my site.

Problem was that when I went to put it onto my production server, I discovered that it runs the latest version of WordPress, and handles users and registration quite a bit differently than does the version running on my test machine.

I basically like the changes, but they have cramped my style a bit.

Now I've got things working again, though there are still bugs for me to fix. In particular, you can get into wierd states if you edit your profile – please wait a while.

Also, 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.

A bunch of people have been downloading the InfoCard client and trying it on my site. Now it should work. Next I publish the source, and will do a code walkthrough, explaining the tokens and how to use them.

This stuff is all very alpha right now and there are things about WordPress that I don't fully understand. So, together we should be able to have some fun. People may have hints about my “use” of php as well. Too bad about this architect thing – I do love programming.

By the way, even though there isn't an open source version of InfoCards available yet, I hope my demonstration of what you can do on the LAMP stack helps advance the availability of InfoCard on non-windows systems.

UPDATE:  The token handling code is explained here and includes a zip.  I still haven't finished writing up the tutorial on what you have to change in WordPress.

 

Welcome back…

 …as a recognized subscriber. Thanks for verifying your email address.

You can now make comments without waiting for me to approve them.

By the way, point us to things you've written or like.

Thanks,

Kim

Click here to go the blog's main page.

A friend sent me recently to a web site that I think has many lessons to teach.

These lessons are layered like the skin of an onion, starting with a threat analysis of RFID. The authors (Melanie R. Rieback, Bruno Crispo and Andrew S. Tanenbaum) do a great job not only of thinking through and prototyping threats, but of explaining themselves in a paper called “Is Your Cat Infected Wiith An RFID Virus?” Reading it you'll see this is not a rhetorical question.

The site has many other treats as well. For example:

To make clear what kinds of problems might arise from RFID hacking by amateurs or criminals, let us consider three possible and all-too-realistic scenarios.

A prankster goes to a supermarket that scans the purchases in its customers’ shopping carts using the RFID chips affixed to the products instead of their bar codes. Many supermarkets have plans in this direction because RFID scans are faster (and in some cases can be done by the customers, eliminating the expense of having cashiers). The prankster selects, scans, and pays for a nice jar of chunk-style peanut butter that has an RFID tag attached to it. Upon getting it home, he removes or destroys the RFID tag. Then he takes a blank RFID tag he has purchased and writes a exploit on it using his home computer and commercially available equipment for writing RFID tags. He then attaches the infected tag to the jar of peanut butter, brings it back to the supermarket, heads directly for the checkout counter, and pays for it again. Unfortunately, this time when the jar is scanned, the virus on its tag infects the supermarket's product database, potentially wreaking all kinds of havoc such as changing prices.

Emboldened by his success at the supermarket, the prankster decides to unwittingly enlist his cat in the fun. The cat has a subdermal pet ID tag, which the attacker rewrites with a virus using commercially available equipment. He then goes to a veterinarian (or the ASPCA), claims it is stray cat and asks for a cat scan. Bingo! The database is infected. Since the vet (or ASPCA) uses this database when creating tags for newly-tagged animals, these new tags can also be infected. When they are later scanned for whatever reason, that database is infected, and so on. Unlike a biological virus, which jumps from animal to animal, an RFID virus spread this way jumps from animal to database to animal. The same transmission mechanism that applies to pets also applies to RFID-tagged livestock.

Now we get to the scary part. Some airports are planning to expedite baggage handling by attaching RFID-augmented labels to the suitcases as they are checked in. This makes the labels easier to read at greater distances than the current bar-coded baggage labels. Now consider a malicious traveler who attaches a tiny RFID tag, pre-initialized with a virus, to a random person's suitcase before he checks it in. When the baggage-handling system's RFID reader scans the suitcase at a Y-junction in the conveyor-belt system to determine where to route it, the tag responds with the RFID virus, which could infect the airport's baggage database. Then, all RFID tags produced as new passengers check in later in the day may also be infected. If any of these infected bags transit a hub, they will be rescanned there, thus infecting a different airport. Within a day, hundreds of airport databases all over the world could be infected. Merely infecting other tags is the most benign case. An RFID virus could also carry a payload that did other damage to the database, for example, helping drug smugglers or terrorists hide their baggage from airline and government officials, or intentionally sending baggage destined for Alaska to Argentina to create chaos (e.g., as revenge for a recently fired airline employee).

The links below give more technical detail about possible attacks and how to prevent them. The authors suggest that you read them in order.

• RFID Middleware
• Classes of RFID Malware
• The Architecture of RFID Systems
• Vulnerabilities that Can Be Exploited
• How to Write an RFID Virus
• How to Write an RFID Worm
• How to Defend against RFID Malware

I just came across one of Phil Becker's typically cogent pieces on the relationship between Higgins and InfoCard. Phil is the founder of Digital ID World

I talk so much about the importance of perspective to understanding identity that I often feel I'm overdoing it. Then a week like this one arrives, and I know that I'm not.

Monday, at the Tribeca Grill in New York, Project Higgins had its coming out party. Since that time, the story has been ill-reported and misinterpreted to the point that a number of really smart people are still scratching their heads trying to figure out what Higgins actually is, and what it's appearance on the scene means. (See Phil's post for examples – Kim).

The Importance of Higgins

Higgins is potentially an extremely important development in both identity technology and the identity conversation. So even though this will be a bit lengthy, I am going to take a swing at explaining what Higgins is in a way that can be understood by non-technical types and that provides perspective on where it fits in the identity pantheon.

Exactly what is Higgins? This sounds like a simple question, but geeks and engineers are genetically unable to explain complex new technology paradigms to anyone who doesn't already understand them. Everyone else ends up confused, picking pieces of obscure acronyms out of the pores of their skin. The result is confusion that gets worse instead of better, compounded by reactions to misunderstandings.

Does Higgins Compete With InfoCards?

One of the incorrect, but logically occurring questions is whether Higgins is competition for Infocards. Perspective is key to seeing that this is the wrong question. InfoCards begins its outlook on the identity problem set it's solving by saying “we need a common, intuitive user experience so a user can relate to their identity information and use it safely and with the results they expect.”

This perspective (creating a common user identity experience) led Kim Cameron to develop his laws of identity from the user's viewpoint, and then conceptualize the development of an open identity metasystem, which would allow his user interface to connect with and manage a user's information interoperably with nearly any kind of identity infrastructure that exists or might come to exist in the future.

The perspective of InfoCards is thus the user's view port on the world of identity, and the identity metasystem is how InfoCards can connect to the “identity plumbing” of the world. InfoCards will become part of the Windows desktop when Vista is released later this year, with downloadable versions to retrofit XP and Windows 2000 desktops.

The Higgins Perspective

The Higgins project begins from what might be thought of as the other end of the identity universe, with the mission of giving an application developer a common view port on the world of identity. Its goal is to provide interfaces and abstractions which allow a developer to use identity and have it work as the policies in the system expect it to, but without having to learn the intimate details of how all this happens or works under the hood.

It is especially ironic that a project that is all about identity context doesn't explain its *own* context very well. The best explanation of Higgins I've found is this one, from SocialPhysics:

http://spwiki.editme.com/HigginsIntroduction

I note, however, that the key context setting sentence for *why* Higgins is needed is the *very last one* on this page. “The application developer who needs to integrate an identity/networking system is forced to learn the intricacies of each different system. …This learning investment is not transferable.” I'll add that this usually means that the developer's work is also not transferable, and this is one of the reasons that identity deployments today are usually much harder than they need to be.

The Higgins Context

To fully understand the perspective from which Higgins approaches identity, you first need to know that significant software development today nearly always occurs in what is called an Integrated Development Environment (IDE). There are many of these, but the world is quickly narrowing to Visual Studio.NET for Windows application development, and Eclipse for the rest of the world.

Eclipse, being open source, is architected to allow new concepts to be created by new groups and made part of the developer's environment through a concept known as Eclipse Frameworks. Higgins is a project to create an Eclipse Framework that abstracts identity data and service interactions so that the application developer can easily develop a standardized relationship to varying identity infrastructure.

Higgins’ Relationship to “Identity Plumbing”

This is a major task, and it will only succeed if they develop a common set of abstractions that can cover all of the ways identity “plumbing” relates to identity data today or in the future. This encompasses not only the functionality of various identity protocols, but the quirks of data repositories and mechanisms behind them where those influence how identity infrastructure operates. The Higgins framework also has to deal with varying client side capabilities, such as browsers, IM clients, or other client software with differing identity needs and capabilities.

Higgins handles interaction with various protocols through plug-ins to its framework. Thus there would be a plug-in to map LDAP to the Higgins abstractions, another to map SAML to those abstractions, and others for such things as WS-Trust, Liberty, proprietary protocols, etc. As an open source project, new Higgins adapters would appear as contributors develop them, allowing it to evolve as infrastructure changes.

How Mature is Higgins?

Today the Higgins project is in its infancy (version 0.2), and most of this work remains to be done. The announcement Monday, however, indicates that the identity industry is reaching the point where it realizes that this type of step is badly needed, and larger players are now looking to promote the development of such solutions.

InfoCards is no doubt adding a sense of urgency to this process, as it means that there will soon be an end-to-end user-centric identity infrastructure deploying widely. While the underlying identity metasystem that InfoCards runs on is open, only Microsoft will have both the user and the application endpoints available when it deploys. Ping identity recently released PingTrust, which will allow federation to an InfoCard infrastructure, but the rest of the field isn't really ready to take advantage if users end up liking what InfoCards presents them as a unified way to interact with and manage their networked identity data.

A Sense of Urgency is a Good Thing for All

Over the years I've seen that a sense of urgency generally produces good results, and often rapid evolution in either the capability or the packaging and ease of use of identity technology. As I wrote last week, this is exactly what potential customers are saying they need vendors to provide more of to buy. So it looks like both the customer demanding RPD (reduced pain on deployment) and the prodding of InfoCards to look at the identity problem in a far more systematic and integrated way are both pushing development in the same direction.

It now seems likely that by our conference in September the identity technology world will be changing very significantly. The identity conversation is getting more interesting every day…

If you have a single web server that uses html pages, like most bloggers do, the easiest way to take advantage of infocard identities is to get the Identity Selector to post tokens directly to your web server. Normally, you might get the contents of a form in the post. When using InfoCards you get a “token”. Various types of token are possible, but SAML tokens are most common. The built-in self-asserted identity provider uses the SAML format.

<enc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
               xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
  <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /> 
  <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      <e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">
          <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
              <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
          </e:EncryptionMethod>
          <KeyInfo>
              <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/
                        oasis-200401-wss-wssecurity-secext-1.0.xsd">
                  <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/
                        oasis-wss-soap-message-security-1.1#ThumbprintSHA1" 
                          EncodingType="http://docs.oasis-open.org/wss/2004/01/
                        oasis-200401-wss-soap-message-security-1.0#Base64Binary">
                      +PYbznDaB/dlhjIfqCQ458E72wA=
                  </o:KeyIdentifier> 
              </o:SecurityTokenReference>
          </KeyInfo>
          <e:CipherData>
              <e:CipherValue>
                   1dYJm11Qw2UDKuS7OsjY23k+vX4l5nHkKUC71ev7
                   jtDUC0dFn1mcWunmGV272bpXGHeyWIviv2Salkxj
                   XErXBwO3hq9/dNyDfY7VvLRi5rOvn1Szgb71d0Xg
                   rKCvnUljhy9bSssSxtYgr4YOTkUV894z0yXS9omK
                   S0XNtm/dzr4=
              </e:CipherValue> 
          </e:CipherData>
      </e:EncryptedKey>
  </KeyInfo>
  <enc:CipherData>
      <enc:CipherValue>
          77Ybo3C32JckPMD+lxm9t7KKxfQjMT8ojczrDs0i
          HsxJ3Q6i3B04RAGrOivLfqMYzYP4lZXsM2lF8cUs
          aVOTY9KqsJjpOBwyk37n9tw7pV6E3SXkHtXx92xl
          5AqmjPeBdDI/syrIjgE1bpbn5sX5PpNoOmAbYSV2
          dQRBnImKJBAfKQFFmMk0mcUb/Bv11w9aCAgimPy7
          UfwqQPhkPp0DbCoINFZsmbgppelTHTh6Bnpe/it9
          OPDqBeUaILVBA7vMVvgDA0vmklb9g3mEzo1va5GG
          4GP/u0xuCG7x9glozdDVtsBsohJiGj0UnFS2QI0o
          ZbfbMS9rtWCiHRbp0TIhcykn70PUooVJrU/HcKDh
          baKnoC3dd0Y73gqTogwvruYZ3Fg9mqhlYMSoLmsR
          sz+W8a935WQM1OAcNz6VEjxaKn7QDRZn/OfQhW1r
          XsWh+oazVKHdxpa9vvj6UeV3w8DaJsmZDO5SRTep
          LjZzfMENc52XG8CJfDrVHEuPmals92NoTN+BwIc6
          R4WpHPxr+P7GPfpb24apOfgBmfN/snq+Jy37PLjV
          4yivz9NmP6EKEpDI7u7b+evytYRmQrh04T/aL6gi
          NHzgfHo7PxiNU6hvCKNQ0vtKgMp1R6QjkMV93FvS
          1I6eknbHLjbUJaJuuGI3eH83RN/Gx7bsuDvfTvDL
          WiTTsG2zD5UPWeEjx+ROCkhLpb8Ojm8h6fI3s+Qv
          qUuzAbzH8cHiyfWGAt8HPe1BwKWcU25XbVfQTOnG
          jP2+NXt2AUtDYimUjydSlyMzk0Bi3GPr19aav2UV
          N1gr2ldVotma4lpNonhLjk+liHTrrO7P51/vkc4k
          P7koLTLBmmNooOQrJ1w70MelRjZnFbCdoadyzH8j
          z/vR/zzvO62z4ycFyn/S9OxqFqrufKpyijnopVS3
          bf4JGazumScIutKfUUpWOtRELXnCpv4S9JB4FIkr
          Kqqgi/3rh06QMByWK6DU7cf94dI3jIzx336A1a/r
          .                                       
          .                                       
          .                                       
          Wvl2o5ABIqvToMV1bp16Ns1ImSgxuB074kmAvAUx
          b/LXPXq1Gwcz2YtyaHMYSUvzzzYRuDH9qu0R6748
          B/C1if4MeXHUqMPYaEQ+dhuzoVUMuy7/kQVP5ckb
          B0asMSqIiJp5B4vecBe/aGQo9AYNEwPv4xAB5cvr
          PBEG4TCFtSVyJkn2LcdwNzqmNqIewGMxawwUPgxe
          D2w==
      </enc:CipherValue> 
  </enc:CipherData>
</enc:EncryptedData>

This article appears in the March issue of Wired.

Working late one night a few months back, I was just about to sign off when I decided to check my email. At the top of my inbox was a message from PayPal, “confirming” a change in my email address. But I hadn't changed the address. In an exhausted panic, I clicked the link to correct an obvious fraud.

For a split second the browser opened not to PayPal but to an unrelated IP address. Then, almost instantaneously, the screen was replaced by what looked exactly like a PayPal window, requesting my password to sign in. This wasn't PayPal; it was a phishing bot. Had I been just a little drowsier, I might have been snagged by the fraud in the very act of trying to stop it.

We who celebrate the brilliance of the Internet – and in particular, its end-to-end open design – tend to ignore the maliciousness that increasingly infects it. The Net was built on trust, and it lacks an adequate mechanism to prevent fraud. Thus, it's no surprise that phishing expeditions nearly doubled last year – and phishing is just one of many evils proliferating online. It's only a matter of time until some virus takes out millions of computers or some senator's identity is stolenin. When that happens, the liberties inherent in the Internet's early design will erode even faster than the liberties said to be protected by the Constitution.

Now, with the debut of the InfoCard identity management system, Microsoft is leading a network-wide effort to address the issue. To those of us long skeptical of the technology giant's intentions, the plan seems too good to be true. Yet the solution is not only right, it could be the most important contribution to Internet security since cryptography.

The InfoCard system will first be distributed with Vista, Microsoft's newest Windows OS, set for release this year. The system effectively adds an “identity layer” to the Internet, accomplishing what security companies have been promising for years: making it difficult to falsify an identity and easy to verify your own. Here's how it works: Users’ computers (and potentially cell phones and other devices) will hold files called InfoCards that give encrypted sites access to authenticated information about the user. An American Express InfoCard, for example, might carry your name, address, and account number, all authenticated by American Express. When a Web site requests personal data, you choose whether to release that information, securely and with the verification of the card's issuer.

The resulting system is more precise and comprehensive than the hope-it-works hodgepodge of security measures we use now, argues Kim Cameron, Microsoft's chief architect of identity and access. “Auto-complete and cookies and passwords are part of a patchwork solution. With InfoCards, users will always know exactly what's happening and can always control it.”

This might sound scary to friends of privacy. It shouldn't. The InfoCard system gives you more control over your data, not less. The protocol is built on a need-to-know principle: While an InfoCard might hold 30 facts about me, only the data I choose to reveal is shared. If I need to certify that I am a US citizen, then that fact is verified without also revealing my name, age, or place of birth. And when it comes to that fake PayPal site, the InfoCard system wouldn't recognize it – it wouldn't have theproper credentials.

Again, if this sounds scary to those suspicious of Microsoft, it shouldn't. It's a protocol – a set of rules for exchanging information – not a Microsoft product. Any company can provide certified protection for data using the protocol, and many will. So unlike Microsoft's Passport system, the dubious personal info repository that alarmed many people a few years ago, no central administrator decides how privacy is protected or trust secured. Instead, the protocol solves the problem of security the same way the Internet solved the problem of browsers – through competition on an open, neutral platform. This is infrastructure for a digital age. It's TCP/IP for privacy and security.

None of this means there isn't a role for (smart) government policy and laws against online fraud or theft. There plainly is. But if this identity layer sticks, then there is a wider range of solutions to the problem. In particular, there is one that seemed impossible to me just a year ago, one that's consistent with the decentralized design of the Internet. That's an extra?ordinary gift to the online world, from a giant that increasingly depends on the Net's extraordinary design.

Here is Dave Kearn's “The real deal about IBM, Novell and Project Higgins” from Network World's Identity Management Newsletter of 03/06/06:

You must have seen at least one of these headlines last week:

“Project Higgins: IBM's response to Microsoft InfoCard?”

“IBM developing online ID system similar to Microsoft's InfoCard”

“Open Source Higgins Project Takes On Microsoft's InfoCard”

“IBM And Open Source Allies Prepare To Take On MS’ Infocard”

“IBM Bucks Microsoft's Infocard”

And my personal favorite:

“Passport's heir gets open source competition”

The one thing they all had in common is that they were all wrong, misleading even. The Higgins Project (as you read here last fall) is a “framework to build user-centric, ID-enabled services.” InfoCard, on the other hand, is an application or services for the Windows platform enabling a user to plug their identity into what's called the “identity metasystem,” a loosely defined, constantly morphing fabric allowing ID providers and ID consumers to transact ID activity in a secure, privacy-protecting way using the worldwide IP network.

It would be possible to use the Higgins framework to construct a service that participated in the identity metasystem, though it wouldn't necessarily compete with Microsoft's InfoCard but, rather, be complementary to it.

The flap all started when IBM and Novell issued a press release announcing that they would contribute software to the Higgins Project and that IBM would “incorporate Higgins technology within its Tivoli identity management software.” This is interesting, because Higgins really is a framework that allows developers to incorporate identity-based services into their applications. Hasn't IBM already integrated identity into its applications?

The situation was further muddled by this quote in the press release from Tony Nadalin, distinguished engineer and chief security architect at IBM: “Open source ensures… that customers won't be locked into a proprietary architecture when they adopt user-centric identity management systems.” Reporters and editors took that to be a direct slap at Microsoft. But, as Nadalin explained (via e-mail): “Joining this project was a direct result of customers coming to IBM wanting interoperability with Microsoft Infocards and IBM software (along with interoperability with other identity systems like SXIP, LID, OpenID, etc), so we needed a framework with service interfaces that would allow this to occur and IBM believes it's best if this is done in an open source community.”

So no matter what the various technology scandal sheets are saying, no matter what “spin” people try to put on this, it boils down to IBM and Novell recognizing that they need a way to participate in the user-centric identity arena and choosing the well-established Higgins Project as their vehicle to do so. It really is a tempest in a teapot!

I hadn't even seen “Passport's heir gets open source competition”. It really makes you want to pull your heir out.

I had to laugh reading Jason Hogg's HoggBlog, dedicated to “Patterns and practices: integration, web services and security.” Here's a recent post, part of an interesting series about the RSA Conference in San Jose:

How many times have you had a security solution / process forced upon you that for whatever reason is unworkable – forcing you you to work around it?

The classic example is of course where tough password policies are implemented that make it impossible for people to remember passwords without writing them down. The last place you would expect this mistake to be made is at a conference organized by RSA – but for the second year in a row this is exactly the challenge that many attendees experienced whilst trying to access the secure wireless network.

I spent over an hour trying to connect to the wireless network. I even followed the 6 page instruction document that you can obtain after tracking down their help desk. I spent a further 15 minutes with a help desk guy who was also unable to help… until it worked for a brief 5 minute period. Naturally minutes after I left the help desk the connection stopped working again.

Prior to my presentation today I asked how many people had laptops – the answer was about 1/2 of the room. I asked how many people had successfully connected to the network and I would guess only about 20% of that group had managed to connect. I asked how many people had connected without any problems – and only 1 person put his hand up! Not great odds…

Now don't get me wrong – I understand the importance for RSA to be perceived as being security conscious – but it appears that little consideration was given for simplicity or usability. I wonder if any usability testing was actually performed?

The really funny thing is that I was talking with a Chief Security Architect from a Fortune 50 company and mentioned the problems I was having and he said he had the same problems and suggested that I wonder down the hall to the foyer of the Hilton hotel – where there is free public wireless Internet available.

Perfect! The wireless network at the Hilton worked like a charm – but for myself and obviously many other attendees to be productive we have had to completely bypass the security system that RSA set up and go and use an alternate completely insecure solution…

I think this scenario is worth formalizing as an anti-pattern. I wonder what we should call it? Respond with ideas… Also feel free to respond with other of these Dogbert like scenarios if any spring to mind…

Continuing on the trek through my spam folder, a friend had sent me a pointer to this posting by a small company called Opinity that Ester Dyson had called “extremely interesting” at the Berkman identity meeting.

I've known the Opinity guys for a while now, but they have very much solidified their thinking and really thought hard about how to make their system accord with the Seven Laws. I think it's one of the more forward-thinking social computing initatives I've seen. They have great ideas for delivering new experiences without screwing up on the privacy front.

Last week, Ted Cho and Bill Washburn, two of the head guys at Opinity, had a talk with Kim Cameron, Microsoft's identity guy (which you probably knew already). This was a continuation of a discussion that goes back to last summer. As a result of these talks and our own ongoing focus, Opinity will implement Microsoft's InfoCard into Opinity 2.0.

This is not, as the saying goes, ‘a deal.’ This is a mutual agreement to work together on implementing Microsoft's identity management into Opinity's services.

From our point of view, it is an opportunity to get many of the features we want to offer our users into play–to put some software into people's hands that will enable them to manage their online selves. We like Kim Cameron's ideas and stated intentions. His Laws of Identity (which might more accurately be called “Desirable Principles of Identity Management,” but, really, that's not a very snappy title) provide an excellent way of thinking about open and user-controlled identity. Infocard gives those ideas concrete form.

So we're confident that this is a good start, a way of getting actual users into the game and manifesting our own commitments to user control of personal information. As I have said here in various ways, we want to give users the abilities to:

construct as comprehensive and detailed a picture of themselves as they choose
include whatever information they think is relevant

authenticate whatever information they wish

give the information only to people they choose

give the information only in situations they choose

It's like this: in a particular transaction, you want to verify you're over twenty-one and live in Denver; you should be able to reveal that information on that occasion, show that it's validated, and nothing else.

How all this will work out in practice remains to be seen–as Yogi Berra pointed out, prediction is difficult, especially of the future. We think InfoCard will set us on the road to making all this happen, and so we're committed to adopting InfoCard.

I should also point out that we're not locking anyone out. Doing so is not Kim Cameron's vision, and it certainly isn't ours. We remain standards-agnostic.

Personally, I also believe that we're seeing the emergence of identity management as something users can actually do. Bill Gates pushed hard for InfoCard in his talk at the RSA Conference, and Verisign has announced its endorsement of InfoCard, the announcement coming soon after its anouncement that eBay, Yahoo, and Motorola have signed up for Versign's online identity protection program, VIP. So you connect eBay-Yahoo-Verisign-Motorola to InfoCard and InfoCard to Windows Vista, and all of a sudden you have the possibility of millions of users getting their hands on managing their own identies. Also, the inclusion of Motorola in this deal could mean that millions of cellphone users could be part of all this.

One final thing I'd note about InfoCard: with it, users can assert information about themselves and aren't simply at the mercy of identity “providers.” This means that users can claim their own identities. It's about time, and we're totally stoked–to use the technical term–to see it happening.

I don't want to sound like a nag, but over time we'll see whether the Laws of Identity are really nothing more than “Desirable Principles of Identity Management.” I think people will eventual see that these are objective laws of distributed human systems that, over time, will gate what fails and succeeds as a widespread identity framework.

I'm still wading through the contents of my spam folder, a mixture of real spam and stuff which got there through some random and idiot algorithm.

As a result, I've lost the context for a number of comments that might have been interesting at one point. However, this comment from Dave Kearns seems to have an eternal usefulness:

The mere fact that someone owns a hammer and a saw doesn't make them a carpenter