Financial Cryptography

Identity on the move II - Microsoft's "Identity Metasystem" TM, R, Passport-redux

A commercial presentation on Microsoft's Infocard system is doing the rounds. (Kim Cameron's blog.) Here's some highlights and critiques. It is dressed up somewhat as an academic paper, and includes more of a roadmap and analysis view, so it is worth a look.

The presentation identifies The Mission as "a Ubiquitous Digital Identity Solution for the Internet."

By definition, for a digital identity solution to be successful, it needs to be understood in all the contexts where you might want to use it to identify yourself. Identity systems are about identifying yourself (and your things) in environments that are not yours. For this to be possible, both your systems and the systems that are not yours – those where you need to digitally identity yourself – must be able to speak the same digital identity protocols, even if they are running different software on different platforms.

In the case of an identity solution for the entire Internet, this is a tall order...

Well, at least we can see a very strong thrust here, and as a mission-oriented person, I appreciate getting that out there in front. Agreeing with the mission is however an issue to discuss.

Many of the problems facing the Internet today stem from the lack of a widely deployed, easily understood, secure identity solution.

No, I don't think so. Many of the problems facing the Internet today stem from the desire to see systems from an identity perspective. This fails in part because there is no identity solution (and won't be), in part because an identity solution is inefficient, and in part because the people deploying these systems aren't capable of thinking of the problem without leaning on the crutch of identity. See Stefan Brands' perspective for thinking outside the tiny cramped box of identity.

A comparison between the brick-and-mortar world and the online world is illustrative: In the brick-and-mortar world you can tell when you are at a branch of your bank. It would be very difficult to set up a fake bank branch and convince people to do transactions there. But in today’s online world it’s trivial to set up a fake banking site (or e-commerce site …) and convince a significant portion of the population that it’s the real thing. This is an identity problem. Web sites currently don’t have reliable ways of identifying themselves to people, enabling imposters to flourish. One goal of InfoCard is reliable site-to-user authentication, which aims to make it as difficult to produce counterfeit services on the online world as it is to produce them in the physical world.

(My emphasis.) Which illustrates their point nicely - as well as mine. There is nothing inherent in access to a banking site that necessitates using identity, but it will always be an identity based paridigm simply because that's how that world thinks. In bricks-and-mortar contrast, we all often do stuff at branches that does not involve identity. In digital contrast, a digital cash system delivers strength without identity, and people have successfully mounted those over web sites as well.

That aside, what is this InfoCard? Well, that's not spelt out in so many words as yet:

In the client user interface, each of the user’s digital identities used within the metasystem is represented by a visual “Information Card” (a.k.a. “InfoCard”, the source of this technology’s codename). The user selects identities represented by InfoCards to authenticate to participating services. The cards themselves represent references to identity providers that are contacted to produce the needed claim data for an identity when requested, rather than claims data stored on the local machine. Only the claim values actually requested by the relying party are released, rather than all claims that the identity possesses (see Law 2).

References to providers is beginning to sound like keys managed in a wallet, and this is suggested later on. But before we get to that, the presentation looks at the reverse scenario: the server provides the certificate:

To prevent users from being fooled by counterfeit sites, there must be a reliable mechanism enabling them to distinguish between genuine sites and imposters. Our solution utilizes a new class of higher-value X.509 site certificates being developed jointly with VeriSign and other leading certificate authorities. These higher-value certificates differ from existing SSL certificates in several respects.

Aha. Pay attention, here comes the useful part...

First, these certificates contain a digitally-signed bitmap of the company logo. This bitmap is displayed when the user is asked whether or not they want to enter into a relationship with the site, the first time that the site requests an InfoCard from the user.

Second, these certificates represent higher legal and fiduciary guarantees than standard certificates. In many cases, all that having a standard site certificate guarantees is that someone was once able to respond to e-mail sent to that site. In contrast, a higher-value certificate is the certificate authority saying, in effect, “We stake our reputation on the fact that this is a reputable merchant and they are who they claim to be”.

Users can visit sites displaying these certificates with confidence and will be clearly warned when a site does not present a certificate of this caliber. Only after a site successfully authenticates itself to a user is the user asked to authenticate himself or herself to the site.

Bingo. This is just the High Authentication proposal written about elsewhere. What's salient here is that second paragraph, my emphasis added. So, do they close the loop? Elsewhere there has been much criticism of the proposals made by Amir and myself, but it is now totally clear that Microsoft have adopted this.

The important parts of the branding proposal are there:

• The site is identified
• the statement is made by the verifier of the site:
• the verifier is named, and
• the verifier's logo is present.

The loop is closed. Now, finally, we have a statement with cojones.

There remain some snafus to sort out. This is not actually the browser that does this, it is the InfoCard system which may or may not be available and may or may not survive as this year's Microsoft Press Release. Further, it only extends to the so-called High Assurance certs:

To help the user make good decisions, what’s shown on the screen varies depending on what kind of certificate is provided by the identity provider or relying party. If a higher-assurance certificate is provided, the screen can indicate that the organization’s name, location, website, and logo have been verified, as shown in Figure 1. This indicates to a user that this organization deserves more trust. If only an SSL certificate is provided, the screen would indicate that a lower level of trust is warranted. And if an even weaker certificate or no certificate at all is provided, the screen would indicate that there’s no evidence whatsoever that this site actually is who it claims to be. The goal is to help users make good decisions about which identity providers they’ll let provide them with digital identities and which relying parties are allowed to receive those digital identities.

The authors don't say it but they intend to reward merchants who pay more money for the "high-assurance". That's in essence a commercial response to the high cost of the DD that Geotrust/RSA/Identrus are trying to float. This also means that they won't show the CA as the maker of a "lower assurance" statement, which means the vast bulk of the merchants and users out there will still be phishable, and Microsoft will be liable instead of the statement provider. But that's life in the risk shifting business.

(As an explanatory note, much of the discussion recently has focussed on the merchant's logo. That's less relevant to the question of risk. What is more relevant is VeriSign's name and logo. They are the one that made the statement, and took money for it. Verisign's brand is something that the user can recognise and then realise the solidity of that statement: Microsoft says that Verisign says that the merchant is who they are. That's solid, because Microsoft can derive the Verisign logo and name from the certificate path in a cryptographically strong fashion. And they could do the same with any CA that they add into their root list.)

Finally, the authors have not credited prior work. Why they have omitted this is obscure to me - this would be normal with a commercial presentation, but in this case the paper looks, writes and smells like an academic paper. That's disappointing, and further convinces people to simply not trust Microsoft to implement this as written; if Microsoft does not follow centuries-old academic customs and conventions then why would we trust them in any other sense?

That was the server side. Now we come to the user-centric part of the InfoCard system:

2.7. Authenticating Users to Sites InfoCards have several key advantages over username/password credentials:

• Because no password is typed or sent, by definition, your password can not be stolen or forgotten.
• Because authentication is based on unique keys generated for every InfoCard/site pair (unless using a card explicitly designed to enable cross-site collaboration), the keys known by one site are useless for authentication at another, even for the same InfoCard.
• Because InfoCards will resupply claim values (for example, name, address, and e-mail address) to relying parties that the user had previously furnished them to, relying parties do not need to store this data between sessions. Retaining less data means that sites have fewer vulnerabilities. (See Law 2.)

What does that mean? Although it wasn't mentioned there, it turns out that there are two possibilities: Client side key generation and relationship tracking, as well as "provider generated InfoCards" written up elsewhere:

Under the company's plan, computer users would create some cards for themselves, entering information for logging into Web sites. Other cards would be distributed by identity providers -- such as banks or governmental agencies or online services -- for secure online authentication of a person's identity.

To log in to a site, computer users would open the InfoCard program directly, or using Microsoft's Internet Explorer browser, and then click on the card that matches the level of information required by the site. The InfoCard program would then retrieve the necessary credentials from the identity provider, in the form of a secure digital token. The InfoCard program would then transmit the digital token to the site to authenticate the person's identity.

Obviously the remote provision of InfoCards will depend on buy-in, which is a difficult pill to follow as that means trusting Microsoft in oh so many ways - something they haven't really got to grips with. But then there are also client-generated tokens. Are they useful?

If they have client-side key generation and relationship caching, then these are two of the missing links in building a sustainable secure system. See my emphasis further above for a hint on relationship tracking and see Kim Cameron's blog for this comment: "Cameron: A self-issued one you create yourself." Nyms (as per SSH and SOX) and relationship tracking (again SSH, and these days Trustbar,Petname and recent other suggestions) are strong. These ideas have been around for a decade or more, we call it opportunistic cryptography as a school.

Alternatively, notice how the credentials term is slipped in there. That's not how Stefan Brands envisages it (from Identity on the move I - Stefan Brands on user-centric identity management), but they are using his term. What that means is unclear (and see Identity on the move III - some ramblings on "we'll get it right this time, honest injun!" for more).

Finally, one last snippet:

3.6. Claims != “Trust” A design decision was to factor out trust decisions and not bundle them into the identity metasystem protocols and payloads. Unlike the X.509 PKIX [IETF 05], for example, the metasystem design verifies the cryptography but leaves trust analysis for a higher layer that runs on top of the identity metasystem.

Hallelujah! Trust is something users do. Crypto systems do claims about relationships.

Posted by iang at February 27, 2006 01:45 PM | TrackBack