Fwd: Abridged -> Financial Cryptography Update: Identity on the move II - Microsoft's "Identity Metasystem" TM, R, Passport-redux

[coderman]

user centric identity management is coming.  big improvements here but
i'm going to dismiss it by saying the InfoCard system is still managed
by a huge proprietary code base mired in an ecosystem of
vulnerability.

the rootkits of the future will simply be hooking into userspace to
steal data off the pages you use to communicate over InfoCard secured
sessions back to your bank. (see the Haxdoor rootkit as an example of
this)


----

https://www.financialcryptography.com/mt/archives/000666.html

...

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).
"""

... 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 blogfor 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.