[fc-discuss] Financial Cryptography Update: Identity on the move II - Microsoft's "Identity Metasystem" TM, R, Passport-redux
Mon, 27 Feb 2006 12:07:47 +0000 (GMT)
Financial Cryptography Update: Identity on the move II - Microsoft's "Identity Metasystem" TM, R, Passport-redux
February 27, 2006
A commercial presentation on Microsoft's Infocard system is doing the
rounds. 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 diffi-
cult 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.
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
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
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 <b>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”.</b>
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.
<img height="" width="" src="microsoft_adopts_ca_branding.png">
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
* 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
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/... 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
(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
2.7. Authenticating Users to Sites
InfoCards have several key advantages over username/password
• 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:"
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 at that. 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, but they are using his term.
What that means is unclear.
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
Powered by Movable Type