Category: Identity Metasystem

Information Card user education resources

Keith Brown points out that we need some permanent web resources that would teach people about Information Cards, how they work, how to use them, and so on:

As I add support for information cards to Pluralsight, I'm rather surprised that I'm having trouble finding official landing pages for consumers. For example, on our logon page, there will be a button to click to log in using an information card, kind of like what you see on Kim's login page. For people who don't know what an information card is, this might be confusing, so of course we'll want a link that points to some documentation. But right now it seems as though everyone is creating their own descriptions for this. Here's Kim's what is an information card page, for example.

It seems as though it would help adoption if there were some centralized descriptions of this stuff. Do these pages exist and I'm just missing them? Or is it that Microsoft only wants to talk about CardSpace, which is their implementation of the selector? I note that when Kim wants to tell you how to install an identity selector, he points to a WordPress blog called the Pamela Project, which doesn't seem too helpful, but might be interesting for someone wanting to add support for information cards to their WordPress blog.

It seems to me that if the industry really wants consumers to start adopting information cards, somebody's going to have to explain this stuff in terms my mother can understand, and it would help to have a common place where those explanations live.

In another post, discussing the issue with Richard Turner, he adds:

In my opinion, somebody (Microsoft?) needs to break this holding pattern fast. I agree that things aren't going to take off until there are more relying parties. But as a guy who is busy doing just that (adding support for infocard to pluralsight.com), it doesn't make me feel very comfortable that those consumer landing pages I talked about in my post don't already exist on the web. I happen to be very committed to this technology, so I'm going to implement a relying party no matter what. Other websites might not be so inclined.

I agree this would help – and simplify our lives.  When I InfoCard-enabled my site, I had to cobble stuff up from scratch.  It was tedious since none of the materials existed.   Maybe that's why my help screens are a bit, as Keith is too polite to tell you, crude.

It sure would be neat to have a PERMANENT location everyone's Information Card help links can point to.  That would provide consistency, and let us get some really good resources together, including videos. 

I'll bounce this idea around with others here at Microsoft and see how we can play, as Keith says, a leadership role in making this happen.

Long live minimal disclosure tokens!

Stefan Brands has a nice new piece called, Anonymous Credentials? No, Minimal Disclosure Certificates!  I think he's right about the need to stay away from the moniker “anonymous credentials”.  I adopted it – in spite of the confusion it creates – but I hereby give it up.  If I use it again, slap me around:

“Kim Cameron is in the midst of blogging an excellent series of posts on the important topic of unlinkability; see here and here, for instance. As I had expected from past experience, several commentors on Kim’s post (such as here and here) wrongly equate unlinkability with anonymity. Of course, an unfortunate choice of terminology (‘anonymous credentials’) does not help at all in this respect… 

“In short, ‘anonymous credentials’ are not all about anonymity. They are about the ability to disclose the absolute minimum that is required when presented an identity claim. Similarly, ‘unlinkability’, ‘untraceability’, and ‘selective disclosure’ are not about anonymity per se.

“Anonymity is just an extreme point on the privacy ‘spectrum’ that can be achieved, all depending on what attribute information is encoded in certificates and what of that is disclosed at presentation time. Currently prevalent technologies, such as standard digital signatures and PKI/X.509 certificates, are a poor technology to protect identity claims, since they inescapably leak a lot of identifying information when presenting protected identity claims; in particular, they disclose universally unique identifiers (correlation handles) that can be used to unambiguously link their presentation to their issuance.

I hope people will think hard about the difference between privacy and anonymity to which Stefan calls our attention.  Both are important, but people in the privacy community consider it crucial not to conflate them.  I'll try to find pointers to some of the detailed analysis that has been done by people like Simon Davies of Privacy International and Ann Cavoukian, Privacy Commisioner of Ontario, in this area – not to mention a host of other advocates and policy specialists.

So I'm going to STOP saying anonymous credentials, and even fix my very time-consuming graphic!  (Is that true dedication or what??) 

But I hope Stefan will allow me to say “Minimal Disclosure Tokens” rather than “Minimal Disclosure Certificates”.  I know the word “token” can possibly be confused with a hardware second factor, but its usage has become widely accepted in the world of web services and distributed computing.  Further, I want to get away from the connotations of X.509 “certificates” and forge new ground.  Finally, the word “tokens” ties in to thinking about claims, and allows us to envisage not only “hiding” as a means of minimization, but less draconian mechanisms as well.

Colluding with yourself

Further to Dave Kearn's article, here is the complete text of Paul Masden's comment: 

Kim Cameron introduces a nice diagram into his series exploring linkability & correlation in different identity systems.

Kim categorizes correlation as either ‘IP sees all’, ‘RP/RP collusion’, or ‘RP/IP collusion’, depending on which two entities can ‘talk’ about the user.

A meaningful distinction for RP/RP collusion that Kim omits (at least in the diagram and in his discussion of X.509) is ‘temporal self-correlation’, i.e. that in which the same RP is able to correlate the same user's visits occurring over time.

Were an IDP to use transient (as opposed to persistent pseudonymous) identifiers within a SAML assertion each time it asserted to a RP, then not only would RP's be unable to collude with each other (based on that identifier), they'd be unable to collude with themselves (the past or future themselves).

I was working on a diagram comparable to Kim's, but got lost in the additional axis for representing time (e.g. ‘what the provider knows and when they learned it’ when considering collusion potential).

Separately, Kim will surely acknowledge at some point (or already has) that these identity systems, with their varying degrees of inhibiting correlation & subsequent collusion, will all be deployed in an environment that, by default, does not support the same degree of obfuscation. Not to say that designing identity systems to inhibit correlation isn't important & valuable for privacy, just that there is little point in deploying such a system without addressing the other vulnerabilities (like a masked bank robber writing his ‘hand over the money’ note on a monogrammed pad).

First, I love Paul's comment that he “got lost in the additional axis”, since there are many potential axes – some of which have taken me to the steps of purgatory.  Perhaps we can collect them into a joint set of diagrams since the various axes are interesting in different ways.

Second, I want everyone to understand that I do not see correlation as being something which is in itself bad.  It depends on the context, on what we are trying to achieve.  When writing my blog, I want everyone to know it is “me again”, for better or for worse.  But as I always say, I would like to be able to use my search engine and read my newspaper without fear that some profile of me, the real-world Kim Cameron, would be assembled and shared.

The one statement Paul makes that I don't agree with is this: 

Were an IDP to use transient (as opposed to persistent pseudonymous) identifiers within a SAML assertion each time it asserted to a RP, then not only would RP's be unable to collude with each other (based on that identifier), they'd be unable to collude with themselves (the past or future themselves).

I've been through this thinking myself.

Suppose we got rid of the user identifier completely, and just kept the assertion ID that identifies a given SAML token (must be unique across time and space – totally transient).  If the relying party received such a token and colluded with the identity provider, the assertionID could be used to tie the profile at the relying party to the person who authenticated and got the token in the first place.  So it doesn't really prevent linking once you try to handle the problem of collusion.

Evolving technology for better privacy

Let's continue to explore linking, and of how it relates to CardSpace, identity protocols, token formats and cryptography.

I've summarized a number of thoughts in the following diagram, which contrasts the linking threats posed by a number of technology combinations. The diagram presents these technologies on an ordinal scale ranging from the most dangerous to the least – along the axis of linkage prevention.

X.509 with OCSP

Let's begin with Public Key Infrastructure (PKI) technology employed with X.509 user certificates.

Here the user has a key only she can “exercise”, and some Certificate Authority (CA) mints a long-lived certificate binding her key to her name, organization, country and the like. When the user visits a relying party who trusts the CA, she presents the certificate and exercises the key – typically by using it to sign a challenge created by the relying party.

In many cases, in addition to binding the key to attributes,  the CA exists with the explicit mission of linking it to a “natural person” (in the sense of an identifiable person in the physical world).  However, for now we'll leave the meaning of assertions aside and look only at how the technology itself impacts privacy.

Since the user presents the same long-lived certificate to every relying party who trusts the CA, the certificate and the information in it link the user accross sessions on one web site, and between one web site and another. Any two web sites obtaining this kind of certificate can compare notes and determine that the same user has visited each of them. This allows linkage of their profiles into a super-dossier (possibly including a super-dossier of a natural person).

What is good about X.509 is that if a relying party does not collude, the CA has no visibility onto the fact that a given user has visited it (we will see that in some other systems such visibility is unavoidable). But a relying party could at any point decide to collude with the CA (assuming the CA actually accepts such information, which may be a breach of policy).  This might result in the transfer of information in either direction beyond that contained in the certificate itself.

So in the diagram, I express this through two risks of collusion. The first is between any two relying parties who receive the same certificate. The second is between any relying party and the certificate authority. In esssence, then, all participating parties can collude with any other party, so this represents one of the worst possible technology alternatives if privacy is your goal.

In light of this it makes sense that X.509 has been successful as a technology for public entities like corporate web sites, where correlation is actually a good thing, but not for individual identification where privacy is part of the equation.

(Continues tomorrow…).

Keys, signatures and linkability

Stefan Brands is contributing to the discussion of traceability, inkability and selective disclosure with a series of posts over at identity corner.  He is one of the world's key innovators in the cryptography of unlinkability, so his participation is especially interesting.   

Consider a user who self-generates several identity claims at different occassions, say “I am 25 years of age”, “I am male”, and “I am a citizen of Canada”. The user’s software packages these assertions into identity claims by means of attribute type/value pairs; for instance, claim 1 is encoded as “age = 25”, claim 2 is “gender = 0”, and claim 3 is “citizenship = 1”. Clearly, relying parties that receive these identity claims cannot trace them to their user’s identity (whether that be represented in the form of a birth name, an SSN, or another identifier) by analyzing the presented claims; self-generated claims are untraceable. Similarly, they cannot decide whether or not different claims are presented by the same or by different users; self-generated claims are unlinkable.

Note that these two privacy properties (which are different but, as we will see in the next paragraph, complementary) hold “unconditionally;” no amount of computing power will enable relying parties to trace or link by analyzing incoming identity-data flows, not even if relying parties collude (indeed, they may be the same entity).

Now, consider the same self-generated identity claims, but this time their user “self-protects” them by means of a self-generated cryptographic key pair (e.g., a random RSA private key and its corresponding public key). The user digitally signs the identity claims with his private key; for example, claim 1 as presented to a relying party looks like “age = 25; PublicKey = 37AC986B…; Signature = 21A4A5B6…”. Clearly, these self-protected claims are as untraceable as their unprotected cousins in the previous paragraph. Are they unlinkable? Well, that depends:

  • If the user applies the same key pair to all claims, then the public key that is present in the presented messages will be the same; thus, all presented identity claims are linkable. As a result, a relying party that receives all three claims over time knows that it is dealing with a 25-year old Canadian male. As the user over time presents more linkable claims, this may indirectly lead to traceability; for example, the relying party may be able to infer the user’s birth name once the user presents a linkable identity claim that states the postal code of his home address.
  • If the user applies a different self-generated key pair to each identity claim, the three presented claims are as unlinkable and untraceable as in the example where no cryptographic data was appended. Note that this solution does notforce unlinkability and untraceability: in cases where the user should be identified, the user can simply provide a claim that specifies his name: “name=Jon Smith” or “SSN-identifier=945278476”, for instance. Similarly, to make self-generated identity claims linkable, an additional common attribute value can be encoded

This is a clear way to introduce the notion of how keys and signatures affect tracability and linkability of claims.  However there is more to consider.  Even if the user applies a different self-generated key pair for each of the three attributes discussed above,  if the three attributes are transfered in a single transaction, they are still linked.  The transaction itself links the attribute assertions.  Convenyance of multiple claims is a very common case.

Similarly, if Stefan's three attributes are released during what can be considered to be the same session, they are linked, again regardless of the cryptography.  And if they are released within a given time window from the same transport (IP) address, they should be considered linked too.

While cryptography is one factor contributing to linkability, we need to look at the protocol patterns and visibility they render possible as well.  I'll be starting to do that in my next posting.

Neil Macehiter on the identity metasystem

Here is some recent commentary from Neil Macehiter at macehiterward-dutton Blog on IT Business Alignment:

It's perhaps unsurprising, given all the brouhaha surrounding Microsoft's claims that open source software infringes on 235 of its patents (which incidentally I take to be largely ‘sabre rattling’ from Redmond in the face of the implications of the GPLv3 for its deal with Novell, as discussed in the Risk Factors of the latter's recent 10-K filing), that some recent news regarding the Redmond company's very positive collaboration with the open source community has not received the attention it deserves.

The news in question concerns a series of announcements the company made at last week's Interop conference in Las Vegas. These announcements, as the title of the post suggest, all revolve around Microsoft's vision for an Internet-scale, interoperable identity metasystem and range from additions to the Open Specification Promise (OSP) through to support for OpenLDAP with Microsoft's Identity Lifecycle Manager.

So, what did they announce? First, Microsoft is

making the Identity Selector Interoperability Profile available under the OSP to enhance interoperability in the identity metasystem for client computers using any platform. An individual open source software developer or a commercial software developer can build its identity selector software and pay no licensing fees to Microsoft, nor will it need to worry about future patent concerns related to the covered specifications for that technology

In other words, third parties are free to build the equivalent of Microsoft's CardSpace, following the likes of the Higgins project, Ian Brown's Apple Safari Plug-In and Chuck Mortimore's Firefox Identity Selector. This is important not only because it extends the reach of CardSpace-like capabilities beyond Windows but also because it facilitates the consistent user experience (I know because I have used CardSpace, the Safari Plug-In and the Firefox Identity Selector) which helps to reduce errors and misunderstanding by users.

Second, Microsoft

is starting four open source projects that will help Web developers support information cards, the primary mechanism for representing user identities in the identity metasystem. These projects will implement software for specifying the Web site’s security policy and accepting information cards in Java for Sun Java System Web Servers or Apache Tomcat or IBM’s WebSphere Application Server, Ruby on Rails, and PHP for the Apache Web server. An additional project will implement a C Library that may be used generically for any Web site or service. These implementations will complement the existing ability to support information cards on the Microsoft® Windows® platform using the Microsoft Visual Studio® development environment.

Or, to put it another way, doing for back end servers what the first announcement is doing for the front-end: enabling web sites and enterprises running a wide variety of web server infrastructure to support authentication using CardSpace and the other identity selectors.

The cyncical amongst you might be forgiven for thinking that these two announcements are just Microsoft paying lip service to interoperability. This post should help to allay your concerns: at the Internet Identity Workshop earlier in May the Open Source Identity Selector (OSIS) group demonstrated interoperability amongst 5 identity selectors, 11 relying parties (the party relying on authentication to prove an identity), 7 identity providers (the party asserting the identity), 4 types of identity token (the mechanism for conveying the identity assertion), and 2 authentication mechanisms. Also, on the same day as the Microsoft press release, Internet2 announced plans to extend Shibboleth, a federated web single sign-on solution based on SAML that is widely used amongst educational institutions, to support CardSpace and compatible identity selectors.

The third piece of news from Redmond last week, concerned the new Identity Lifecycle Manager product and is thus primarily focussed behind the firewall. Microsoft is going to be working with KERNEL Networks and Oxford Computer Group to enable bi-directional synchronisation of identity data between OpenLDAP, an open source implementation of the ubiquitous directory standard, and Microsoft's Active Directory. Identity Lifecycle Manager already supports a wide range of the commonly-deployed identity data repositories so I think this move is primarily in the “playing well with open source” category – but valuable nonetheless.

These announcements are further evidence that the likes of Kim Cameron, Microsoft's chief identity architect, and Mike Jones, the company's Director of Identity Partnerships, have been working hard to foster the relationships and commitment (both from Microsoft and third parties) required to help make the identity metasystem a reality. That reality is too important for the results of those efforts to be diluted by political shenanigans around patents and GPLv3.

I'm glad to hear that Neil has tried CardSpace and its sister implementations on different platforms. 

Notes from IIW 2007a

Over at self-issued, Mike Jones picked up on the OSIS Wiki Page reporting on the recent Information Card Connect-a-thon.  Maybe the most encouraging thing was to see new players show up with working bits:

The OSIS group sponsored an Information Card interoperability connect-a-thon on May 15, 2007 as part of the Internet Identity Workshop 2007 A in Mountain View California. Participants collaborated to work through combinations of Identity Provider, Identity Agent, and Relying Party scenarios, in order to identify and workshop problems with interoperability. The following representatives were present and participated:

5 Information Card Selectors

  • Ian Brown’s Safari Plugin
  • XMLDAP
  • Windows Cardspace
  • Higgins IdA Native
  • Higgins IdA Java

11 Relying Parties

  • Bandit (basic wiki authentcation)
  • Bandit (elevated privileges)
  • PamelaWare
  • CA
  • XMLDAP
  • Windows Live RP (used to obtain a managed card)
  • Windows Live/single-issuer (where you can use the managed card)
  • Oracle RP
  • Identityblog RP (based on Rob Richards’ library)
  • Identityblog helloworld token RP
  • UW/Shibboleth

7 Identity Providers

  • Higgins
  • Bandit
  • XMLDAP
  • UW/Shibboleth
  • LiveLabs
  • HumanPresent
  • Identityblog HelloWorld IdP

4 Token Types

  • SAML 1.0
  • SAML 1.1
  • helloworld
  • username token

2 Authentication Mechanisms

  • username/password
  • self-issued (personal) card

Many combinations interoperated as expected; several issues were identified and are being fixed in preparation for the coming Information Card Interop event to be held at the Burton Group Catalyst Conference in San Francisco (June 25-29).

Socket and Ecosystem Days

David Coder comments on my recent reflection on “novel auth” technology:

Kim, I very much agree with everything you wrote.

But there is another thing I don't understand lately. CardSpace is shipping now for almost half a year in its RTM version. And yet, I have never come across a production site (except this one) that uses it. You post all these fantastic anouncements of new groups that will support this, but out there on the web, very little adoption seems to take place. And in particular, there seems to be not a single Microsoft site that uses it. Why? Contrary, the one huge MS group where I would have thought they might use it (Windows Live ID and all the sites that use it) seems to be even implementing their own identity selector.

Quite frankly, right now my impression is that what is needed most is some highly visible commitment from MS itself to this idea and to implement it widespread on its platform. I am just quite sceptical that anyone else will use this widespread, unless you do the first step.

Make no mistake:  you will see deep Microsoft support. But you need to give us time to roll it out, just as we need to give others in the industry time to do the same. 

Using your example of Windows Live ID, it is a huge production system handling a billion authentications a day.  There are strict requirements for introducing new software.  In fact, some of them arose through input from policy makers.  Much more is involved than “wanting to do something” and coming up with “bits” suitable for use on such an enormous site.  There is Process.

The same is true in terms of integrating the new technology into our federation product, Active Directory Federation Service (ADFS).  There is a whole team working on CardSpace support, so administrators will be able to give their Active Directory (AD) users Information Cards at the flick of a switch.  But we want to do it as well as we can, and in the most secure way possible, and we can't do that over night.

My colleagues and I wanted to see CardSpace bits get into circulation as early as possible – even if service offerings weren't ready yet.  Why?

Socket and Ecosystem Days

The problem with identity is getting the infrastructure in place. Some great talent – I don't know who – pointed this out when he said, “The Public Key Infrastructure (PKI) is great except for one thing: the public has no keys”…

CardSpace eliminates the need to “give the people keys”. But the bits still have to “get out there” before it will work. We are still in “Socket and Ecosystem Days”, when sockets start to appear on desktops and people running web sites can move past “but nobody has information cards” and get to “hey, everyone is going to have them”. 

Our first job was to ship CardSpace V1.0 so Information Cards became “real”.  Now we need to distribute bits.  And finally we need to lead in adoption, just as you say. 

CardSpace can't succeed without its sister implementations on other platforms. It also needs relying party software in a dozen languages to run on all platforms.  And identity provider software.  

These are just starting to emerge.  But all this is happening in a methodical and persistant way.  I think of it as “ecosystem time”.  

I'll post the report that appeared on the OSIS wiki describing the Connect-a-thon held at a recent IIW.  You will see the degree to which the ecosystem is growing.

Meanwhile, Windows Live ID plans to introduce Information Card support this summer.  At that point, all the Microsoft properties will be enabled.  The integration will grow progressively stronger over time.

The European e-Identity Conference

I don't often mention my speaking agenda, but next week I'll be giving the opening keynote at a conference in Paris that looks like a great opportunity to exchange information.  It is hosted by EEMA (which has morphed into the European Association for eIdentity and Security) and ENISA (the European Network and Information Security Agency).  If you've been sitting on the fence, it looks like the conference has really come together. Here's the program.

One track is called “managing identity” (in the largest sense) with presentations about architecture and application development approaches by Siemens, SEALED and SAP.  It includes roundtables on interoperability, security-identity interfacing and SOA. 

The other track is on “social networking” with presentations on Netlog and Facebook, and a fascinating series of roundtables on a nice taxonomy of reputation issues.

And that's just day one!  Day two is huge. 

Nick Shelness on CardSpace

The strangest thing just happened.  I was following a link that had just appeared from vowe.net  – a site published by Volker Webe.  An interesting site, for sure – and on it, I read this piece by Nick Shelness:  

Establishing identity and authenticating on the web are a mess. I doubt I’m alone in using the same user id and password over and over again. If they’re hacked once they can be employed a hundred times over. Yeah, some sites make you change your password at regular intervals, but how do you remember them? I write them down, and carry them with me. OK, they’re somewhat encoded, but …

For some time now, there has been the possibility of improvement under the “Identity 2.0” banner. To the surprise of some (many?), a significant chunk of Identity 2.0 innovation has come from Microsoft, and no, no, no, it’s not “Passport”. It is expressed in two seminal papers: The Laws of Identity and The Identity Metasystem, both by Kim Cameron.

But this is not all. There is a Microsoft product. It’s called “CardSpace” (it used to be called “Info Card”). It ships as part of Vista. It also ships as an automatic XP upgrade, and there are a host of alternatives, including open source ones.

CardSpace and its analogues, on their own, are not a solution. They are a component, albeit a key one, of an Identity Metasystem. What needs to come next is for web sites (“Relying Parties”) to start requesting and employing CardSpace-managed security assertions. This in turn will create a demand for Identity Provision (yes, this is where ActiveDirectory and son of Passport come in).

Will this happen? It’s too early to say. But by seeding the digital world with CardSpace, Kim and Microsoft have taken us a long first step down this path, and IMHO done us all a big favor.

It took me a minute to click in to the name Nick Shelness.  He is a great visionary – CTO at Lotus and later an IBM fellow (now with his own practice in the UK).  His support means a lot to me. 

As for his “will it happen?” question, I've asked it too on a hundred ‘bleak and dreary days’.  But I continue to think there are historical inevitabilities at work here.  

Distributed computing is dammed up behind a wall of identity friction.  The one good thing about the friction is that it limits phishing and cyber crime as much as it limits business.  Remove the friction with something like single sign-on and you massively increase the attraction of the digital honeypot, providing a one-stop attack surface for evil.  The more consolidated identity initiatives succeed, the more they will fail – unless there is a paradigm change like CardSpace that compensates for risk aggregation.  

Few may understand these dynamics through theory alone, but Professor Reality will come to tutor them before too long.  Meanwhile, there are more and more people with enough vision that they don't have to “go over Niagra Falls in a barrel to know it hurts.” 

Day after day, week after week, month after month, CardSpace “sockets” are appearing on desktops.  One day – not too far into the future – it will be present on 50% of them.  Then on 75%!  Meanwhile the software will get slicker and slicker, with multiple versions and choices by people like our friends at Higgins running on Mac and Linux.  This is a historic thing we are doing together, and we can't be impatient.  But this baby is going to light up big time.