Anonymity is the substrate

Ben Laurie at Links, contemplating the “identity as a default” debate, argues “Anonymity is the substrate“:

Kim Cameron’s blog draws my attention to a couple of articles on anonymity. The first argues for anonymity to be the default. The second misses the point and claims that wanting anonymity to be the default makes it a binary thing, whereas identity is a spectrum.

But the point is this: unless you have anonymity as your default state, you don’t get to choose where on that spectrum you lie.

Eric Norlin says

Further, every “user-centric” system I know of doesn’t seek to make “identity” a default, so much as it seeks to make “choice” (including the choice of anonymity) a default.

as if identity management systems were the only way you are identified and tracked on the ‘net. But that’s the problem: the choices we make for identity management don’t control what information is gathered about us unless we are completely anonymous apart from what we choose to reveal.

Unless anonymity is the substrate choice in identity management gets us nowhere. This is why I am not happy with any existing identity management proposal – none of them even attempt to give you anonymity as the substrate.

Ben has a valid point in terms of the network substrate.  There are a number of hard issues intertwined here.  But from a practical point of view, here is how I approach it:

  1. You can't solve every problem everywhere simultaneously.  Solving one problem may leave others to be dealt with.  But with one problem gone, the others are easier to tackle.
  2. There are interesting technologies like onion routing and tor that could be combined with the evolving identity framework to offer a more secure overall solution (Ben is better versed in these matters than I am).
  3. If society mandates storage of network addresses under certain circumstances, as it seems to be doing, a much more secure approach to this storage could and should be adopted.  Any legislation that calls for auditing should also require that the audit trail be encrypted under keys available only to vetted authorities and then only through well-defined legal procedures with public notification and in an off-line setting.  This would have a huge impact in preventing the ravages of Norlin's Maxim.

Network issues aside, in keeping with the second law of identity (minimal disclosure), users should by default release NO identifying information at all. 

You can call this anonymity, or you can call this “not needlessly blabbing everything about yourself”. 

Sites should only ask for identifying information when there is some valid and defensible reason to do so.  They should always ask for the minimum possible.  They should keep it for the shortest possible time.  They should encrypt it so it is only available to systems that must access it.  They should ensure as few parties as possible have access to such systems.  And if possible, they should only allow it to be decrypted on systems not connected to the internet.  Finally, they should audit their conformance with these best practices.

Once you accept that release of identifying information should be proportionate to well-defined needs – and that such needs vary according to context – it follows that identity must “be a spectrum”.

 

Ping's Identity Metasystem demo

Ping Federate with InfoCardEarlier this summer, just before the Burton Group Catalyst conference, Andre Durand and Ashish Jain of Ping Identity really surprised me with a lovely Identity Metasystem demo that combined use of Information Cards and federation technology.

I don't think anything I've seen demonstrates more concretely why “federation” and “user centricity” are different and yet complementary.

The demo is built around Ping Federate, which speaks four protocols for transporting SAML tokens around:  SAML 1.0, SAML 1.1, SAML 2.0, and WS-Federation.  Since it speaks all these federation dialects, it can talk to any federating system regardless of its dialect – for example WebSphere, Presentation Server, Windows 2003 and .NET, Tomcat, SAP, Web Logic, Salesforce.com, SiteMinder, CoreID, etc.

But even better, the user has a rational experience as well – just seeing this circle of trust as being accessed through an Information Card.

To play the demo:

Use Windows Media Player.  (You will need the Techsmith Screen Capture Codec (TSCC).  If your system complains it doesn't have the right codec, pick it up here.)  If you want to watch this and don't have any way to see it with Windows Media Player, let me know and I'll make a version for Quicktime.

The demo lasts 3 minutes and takes up 4 megs.  Download here.

As always I sound a little earnest as I rush you towards the finale.  But I think you'll like what these guys have done anyway.

Federation and user-centricity

Conor Cahill picked up on a discussion I recently relayed to identityblog readers – part of an ongoing dialog between Brett McDowell and Dick Hardt.  Conor says:

I think the issue causing the disagreements here is the interpretation of the term “federation” when discussed in an identity context.

Certainly federation can mean groups of businesses working together and this is the traditional meaning of the term in the business community. This meaning would fit with Kim's statement above.

However, in an identity context (as in “identity federation” — the stuff the Liberty Alliance has been working on since its founding) the term federation was used to describe the sharing of identity information from party A to party B. Party A is usually some party representing the user (acting on the user's behalf) such as an Identity Provider or an Attribute Provider. There is nothing that says whether Party A is an entity operated by the user or by some 3rd party.

In fact, in the Cardspace solution, the process of sending data through an Infocard instance to a relying party would be considered taking place under identity federation, whether the infocard instance was rooted in a local data source or a remote data source.

Ultimately, I would say that federation can be used in both user centric and non-user centric solutions. Federation is a technology/protocol and user centric is an implementation philosophy. When designing a user centric solution, you almost always have to include some form of identity federation, but give the user great control over its use. The converse is not required to be true (although I wouldn't object to it if it was true in any environments in which I played).

I like a lot of Conor's thinking.  I agree that use of a managed card in Cardspace should be considered a form of “federation” between the relying party and the identity provider – federation approved by the user.

But I don't quite buy that “federation is a technology/protocol” wherease “user-centric is an implementation philosophy”.  I doesn't compute given a great deal of work I've been doing lately.

It's clear to me that good “user-centric” experience isn't just an automatic or natural by-product of some other “technology/protocol”.  In fact, it requires just as much study, just as much thought, just as much coding, and just as much experimentation as protocols do – probably more. 

What I'm try to say here is that it requires technology.   In the past we've had a lot of technology that failed miserably at organizing, integrating and rationalizing the user's experience.  I've been working on software that I think does a lot better job at this.  Why wouldn't Conor call that a technology?

To my way of thinking, you have two more or less orthogonal technology efforts – that oriented around federation issues, and that oriented around the user's experience.

As a user, when I go from portal to portal to portal, it's likely they will have relationships with different identity providers.  Should my experience therefore be totally discontinuous as I move from one portal to another, being organized by the portal rather than by my own system?

In Cardspace (and with Information Cards running on other devices and platforms) we postulate that the user can benefit from computerization of his or her own identity experience – just as enterprises benefit from computerization of theirs.

Through Information Cards users can benefit, to the extent the technology is adopted, from the same well-understood experience as they move between unrelated portals which do not share identity relationships.   

I see Cardspace as providing a palette of identity relationships (Information Cards) that work for me as a user and make sense from my point of view as an individual with a complicated life. 

I think Dick Hardt, and others like Paul Trevithick at Higgins, share a number of the same notions as I do, though each of us is concentrating on different aspects of the problem.

So that's why I'm saying that there are two legitimate technology areas, orthogonal in the sense that you can have either one without the other, but synergistic in that together you get a number of critical new scenarios.

To make this more concrete, my next post will be  a demo of Andre Durand and Ashish Jain's work in showing how this can look in practice.