User Driven Services let users manage their own online identity.

Unless we control our identity online, we risk unnecessary exposure to identity theft and unwanted correlation of online activity. At the same time, online services increase the risk of attacks when using the same identifier for multiple functions.

User Driven Services allow users to be in maximum control of their identity by distinguishing between the four different types of identifiers used online:

• Authentication IDs
• Presentation IDs
• Reference IDs
• Internal IDs

Users should be able choose their own third-party identity service and have complete control over the three external identifiers used by any User Driven Service: their authentication IDs, their reference IDs, and their presentation IDs. The internal ids relating these external identifiers should never be exposed. Identity Providers should operate in non-correlation modes—so that different services providers automatically receive different authentication tokens, and all presentation IDs should be hand selected by the user for each service whenever possible.

The ideal service will enable intentional correlation only upon user directive, allowing individuals to claim blog posts, social profiles, and microblogging accounts as their own, after initially anonymous or psuedonymous use. Services are also more flexible when they allow users to use multiple distinct identifiers within a given class, e.g., having more than one email address or online chat handle. Finally, when possible, services should allow for anonymous and anonymized use.

Examples

OpenID allows users to use a third party service for Single Sign On at millions of websites, bypassing potentially millions of usernames and passwords. Information Cards allow “clicking in” to relying websites rather than logging in, using the credentials and authentication of third party Identity Providers. Azigo’s RemindMe service allows users to selectively activate membership credentials, such as AAA or AARP affiliation, on specific websites for special offers and discounts—without divulging such affiliations to the website in question.

Questions

• Does the service allow third party identity providers for managing authentication?
• Does the service fully distinguish all four identifiers used in online identy:
  • Authentication ID–used for logins
  • Presentation ID–used for labelling authorship and ownership
  • Reference ID–used for referring to specific users, e.g., for sending messages
  • Internal ID–used internally to link the other three IDs to each other and to appropriate privileges.
• Does the service allow users to modify and manage the three exposed identifiers: Authentication, Presentation, and Reference?
• Does the service allow users to have multiple identifiers in the same class, such as two email addresses or multiple chat handles?

This article is part of a series. It is the ninth of ten characteristics of User Driven Services:

1. Impulse from the User
2. Control
3. Transparency
4. Data Portability
5. Service Endpoint Portability
6. Self Hosting
7. User Generativity
8. Improvability
9. Self-managed Identity
10. Duty of Care

One more to go…

The Identity Quartet is a framework for online services that allows users to express their Identity on their own terms. When I use the term “Identity”, I refer to the set of identifiers used in reference to users in online services.

At the December 2008 Internet Identity Workshop, Randy Farmer introduced what he called the “Tripartite Model of Identity.” He presented a pattern distilled from years of groundbreaking work building virtual communities.  This article is a write up of a four component model based on Randy’s initial concept. I also build on the ideas discussed at the IIW session on Non-correlatable IDs with OpenID.

The Quartet

In online systems, we use Identity in four roles, using four potentially distinct identifiers. Each of those four will be present in any system that allows users to login, present themselves online, and receive incoming services. Often, systems use the same identifier to fulfill multiple roles. However, there are good reasons that these identifiers should be managed separately, especially across organizational boundaries.

The  four identifiers are:

1. Authentication IDs
2. Presentation IDs
3. Reference IDs
4. Internal IDs

Authentication IDs

To access privileged services, users must present an identifier to claim their right to that service. Common identifiers include session IDs, cryptographic tokens, and usernames. Usernames are probably the most common identifier for logging into services. Paired with a password for authentication, this is a cornerstone of how we use identity to gain access to privileged services. That access authorization typically persists without logging in again through the use of a session ID. In a user-centric context we can separate the authentication ID used at a Relying Party with that used at the Identity Provider, allowing for directed identity as described by Kim Cameron in his Seven Laws of Identity.  In a capability-based authentication regime, the identifier itself could contain a cryptographically signed delegation of authority for a particular privilege, but, in general authentication IDs don’t need to be that fancy.

Presentation IDs

Handles, nicknames, and character names are used to label content for display to others in the system. Often these presentation identifiers are humorous or obviously fictional, such as “HappyCamper” in an online chat or “Thor the Destroyer” in World of Warcraft. They need not relate to actual user characteristics, nor do they need to be unique. Their only role is to present a label as the author, owner, or embodiment of a post, comment, rating, or character. Just as there are multiple “John Smiths” in the New York white pages, there’s no reason there can’t be multiple accounts with the same presentation ID in an online community, as evidenced by the vast number of users with the handle “Jesus Jesus Jesus” on Facebook. In reciprocal multiplicity, online games like World of Warcraft often allow each user to create and simultaneously maintain multiple characters, with different names, avatars, descriptions, characteristics and property.

Since presentation IDs are intended to be shown to a wider audience and because their uniqueness is not technically required, it is prudent to separate presentation identifiers from authentication. There is no need to advertise authentication identifiers widely, as that simply increases security risk by giving away a critical—and preferably secret—component required for accessing privileged services.

Reference IDs

Service requests need a way to refer to intended parties. The most prevalent reference identifier is the local-part in an email address, the part before the @ sign, e.g., “joe” in “joe@example.com”.  This identifier allows users to contact one another, without referring to anything else (such as a blog post or a job listing). It should be unique for each intended incoming role (e.g., admin@example.com or joe@example.com), but there is no technical reason that any given user can’t have more than one reference identifier, as is commonly seen when multiple email addresses auto-forward to the same individual. Also, often for a given role, it makes sense for a reference identifier to forward messages to several individuals, e.g., admin@example.com could forward the email to three different users to improve the response time for handling the issue.

Since this reference ID is intended to be used by users other than the recipient (that should be obvious!), it makes sense to distinguish it from authentication IDs used to access the system. Distinguishing the reference ID from the presentation ID allows users to receive directed incoming services (such as email) while displaying handles that are common to multiple users. Combined with an appropriate service endpoint, reference IDs allow for any number of incoming services to be provided in reference to that ID.

Internal IDs

Every system needs to keep track of which identifiers relate to each other and to specific privileges. For example, what email messages should be shown to the user with a particular authentication ID?  And which users should be able to post to a bulletin board? Internal IDs link together the authentication, presentation, and reference identifiers in the system, allowing users who are logged in to a system to see the appropriate service interfaces and have particular services performed as directed, including the proper presentation of their Identity to fellow users. The internal identifier is typically the primary key in a database table managing the list of users, and may also be used in a permissions table to keep track of service privileges. Because it is an internal identifier, it need never be revealed to the outside world and, to minimize hacking, it shouldn’t be. Because it is completely internal, it can also enable anonymous access to services through appropriate anonymized mechanisms for authentication IDs.

Separation of identifiers improves Identity

Many systems use the same identifier for multiple roles, such as using your email address as your login username for a system, such as AOL once required (and might still). However, systems can be more robust, more flexible, and more secure if they explicitly delineate the four identifiers to help avoid unintended correlation and attack vectors. This is especially true across trust boundaries. Using your AOL login as the AOL email service endpoint simplifies the mental model for users new to online services at some minor cost to security by exposing the login id to everyone a user gives their email address to. Using your AOL username as a login to other services is asking for both a loss of privacy from cross-site correlation of your identity and attacks on your account login.

Fortunately, the latest technology can avoid this—if we use it correctly.

It isn’t just enough to enable OpenID, SAML, or Information Cards on our systems. For truly user-driven Identity we need to explicitly delineate the identifiers used for authentication, presentation, and reference from each other and internal identifiers, both within and between organizations. We should also enable users to choose their own identifiers for the first three… and keep the internal identifier completely secret.

Examples

There’s no reason users can’t select their own authentication ID in each of the above situations, although in practice, the RP-specific token is usually dynamically generated on behalf of users. Similarly, Presentation IDs can easily be specified by users in either system, leveraging OpenID’s Attribute Exchange Extension when appropriate. The reference IDs can also be user defined in either of the above approaches, with OpenID allowing fourth parties to discover a user’s service endpoint and endpoint-specific reference ID  for any service authorized by the user for that party. And clearly, the internal identifiers in all three situations have no innate need to be correlated with any of the others except through the secret internal ID. This allows for the maximum possible user choice and, potentially, maximum anonymity.

The Identity Quartet pattern isn’t rocket science. In fact, it makes things simpler when it comes to security, maintenance, and user control. The Quartet makes systems more flexible and more secure while giving users more freedom to manage how they interact and present themselves online. It is one way to turn user-centric Identity services of OpenID and Information Cards into truly user-driven Identity.

[Update: 4/17/2009 Revised "routing ID" to "reference ID".]

Problem Domain

The distributed nature of the web is a big part of its power–nobody needs to ask permission from a central authority to use it or create with it. However, that disaggregation limits the cohesion for sophisticated uses, leaving users to hobble together ad-hoc mash-ups of value from multiple, diverse service providers.

For example, the average travel planner spends 29 days from their first query to their first purchase. No tool I know of facilitates that entire process effectively.

Solving this problem in a general way—while retaining the authority of the individual and the flexibility of open systems—is perhaps the greatest opportunity for VRM. The personal data store and VRM relationship services are two prongs of an architectural shift for enabling this kind of aggregation while remaining open. Once you put the user in the driver’s seat, with coherent controls over the flow and the data, the experience can integrate around the user, even as they drive anywhere on the Internet.

Solution

Kynetx’s solution is built on one primary capability:

A rules engine (and language) for contextual customization based on strong identity-based claims, using the user-centric Identity of Information Cards.

This puts Kynetx squarely in the web augmentation service business. Adaptive Blue (and their Glue product) is perhaps the most sophisticated approach to this space, but Yahoo’s Toolbar also augments web pages, as does Skype (putting its SkypOut button on any phone # it recognizes), and the granddaddies of all web-augmentation services are the ad blocker plug-ins that remove banner ads on websites.

I distinguish web augmentation from web media enhancements, like PDF and Flash and Java, in that the latter are embeddable or downloadable extensions to the core HTML/http architecture of the web, while augmentation services provide third-party manipulation of website presentation on behalf of the user. They actually tweak the web page as the user sees it, rather than offering websites a new way to package content or functionality.

Web augmentation isn’t new, but it is gaining adoption and breadth. There is a low-grade market war going on in this space. While browsers define the official battleground of the World Wide Web; augmentation services are the guerilla warriors of next generation browsing. The approach that reaches ubiquity first will create significant value throughout the architecture: for users, software vendors, and service providers.

So, the question that comes to my mind is where does Kynetx fit into all of this?

The value proposition of a rules-engine for customization is powerful, if that engine makes it easy to leverage strong identity. Every website will, imo, want to take advantage of the unique value of user-centric identity and  Information Cards in particular. However, rewriting your customization to do that will take resources and that will slow adoption. If Kynetx can simplify how websites plug- in to the Identity meta-layer that sounds like a real value.

Gaps

There are however, several gaps that I see in Kynetix’s approach mapped out in the white paper.

First, who are the target developers: websites or Third party services. Or both?

It’s not clear to me if the primary authors of KRL rulesets (and hence Kynetx’s customers) will be the destination website developers or third party augmentation services. For example, . Adaptive Blue‘s Glue augments web pages so that things like movies can be recognized across domains for social commentary, ratings, and sharing. That means that Glue modifies the presentation of web pages at IMDB, Netflix, Amazon, Blockbuster, etc. In this pattern, it is the third-party, Glue, that would be running KRL rulesets, not the websites.

Is this the intended architecture for Kynetx? Is the point of the Kynetx Information Card to provide authorization by the user to allow services like Glue to augment their web experience, while the rest of the plug- in handles injection into the web page within the browser?

Or, is the main point that web services themselves would leverage Kynetx’s Information Card approach to manage third party identity for customization? For example, so Hertz could seamlessly provide AAA or AARP discounts if, and only if, the appropriate AAA or AARP information cards (KIX) are presented by the user? In this case, Hertz writes the customization, but doesn’t need to know upfront what the user’s affiliations might be.

If the first case is intended, the white paper doesn’t do a good job explaining how this fits into a larger, open ecosystem, nor does it highlight this unique architectural opportunity. If a user wants Orbitz to help augment its travel planning experience, even when it is at Expedia or Southwest airlines or Hilton.com, it would be great to do that in a secure, authorized, privacy-sensitive way. But it isn’t quite clear if this is the point of Kynetx’s approach. (Although it is a great opportunity, one that r-buttons and SwitchBook see in the not-so-far future).

If the second case is the goal, it isn’t clear to me why Kynetx is better than other customization frameworks. With a card selector and cards issued from the right authority, users can already present AAA or AARP credentials to websites, which in turn can integrate that information into their existing CMS or other presentation code (Drupal, PHP, perl, Ruby-on-Rails, etc.). If the value proposition is in speed-to-market for identity-based customization, then the white paper needs to make that case first and foremost. If that’s the goal, then it also suggests a business model, which I talk about in a bit.

It could also be that both of these are part of the approach: allowing both the website developer and third parties augment the web experience based on strong identity. This is the general idea behind r-buttons and would almost certainly speed deployment. However, the white paper doesn’t address the issues of contention when multiple providers want to augment the same page. Given the open-ended javascript functionality associated with a KIX, this could be a challenge.

Second, isn’t re-aggregation actually about creating a coherent context?

While the Kynetx approach allows users to present a particular relationship at a particular website, that doesn’t seem to solve the stated problem. I don’t see how it actually achieves a cross-web aggregated experience. In fact, it seems that the best aggregated experience should combine many relationship cards at many different services. In the 29-day travel planning scenario, won’t users need to send their AAA and AARP cards to every site they visit? (Or some large subset?) Does the card selector require a ceremony for every website every session? Or just once and then it is a permanent approval, such as confirming once with Expedia that the user is a AAA member? Managing this A x B complexity with A Information Cards and B websites scales poorly if every site has a distinct ceremony–and even worse if each card presented at each site is a distinct ceremony.

This apparent model of KIX based aggregation seems to miss an opportunity, one that is near to my heart as the core of the Search Map architecture for User-driven Search. It seems to me that for a given web-based task–such as travel planning–what you need is a user-driven personal data store that tracks the user’s progress across the Web. This data store should be 100% transparent, 100% editable, and seamlessly transferable/accessible to authorized vendors under terms controled by the user. We call our version of this a Search Map, an electronic document that provides the user a concrete way to manage and express their Search intent. It is also a seamless way to manage and express user context.

In the white paper, Phil asserts that “users are freed from managing episode context themselves” as a core benefit. But, I don’t think this is actually a benefit. Attempting to achieve that goal could end up being more patronizing than useful, following in the footsteps of “Clippy” the Microsoft Windows help agent which tried to figure out the context and help users, but failed miserably. “I see you are writing a letter. Would you like assistance?” Ack!

It’s not that users don’t want to manage their context, it’s that they haven’t been given simple, value-producing tools to do so. Consider spreadsheets: it’s not that users want to balance the budget on a computer—doing budgets on a computer isn’t inherently rewarding. It’s that spreadsheets make it easy to get value out of balancing their budget on the computer. Managing KIX across 29 days of travel planning and potentially a hundred+ websites sounds like a chore… unless we have a coherent expression of the context (in something like a Search Map, perhaps) that is easy to use and immediately useful.

Third, over-centralization limits scale.

The Kynetx model, as I understand it, doesn’t scale to the full World Wide Web, because it centralizes two core functions: resolving requests for augmentation and the validation of injection javascript as safe, private, and secure. Both of these constrain the growth opportunity for a KRL-based approach to augmenting web services. First, it places the core usage-time server demand on a single service. Given the business model of charging for ruleset evaluations, there is no obvious incentive for Kynetx to release an open source reference implementation to make it easier for alternate KRE service providers. In fact, there is every expectation that Kynetx will be motivated to “win the market share” battle and be the primary KRE service. Which, unfortunately, makes it just another silo, and will face precisely the same sort of scaling issues that plague Twitter. Second, by making Kinetx the arbiter of “quality” it places a single entity in control ofwhat constitutes “safe”. Even with good intentions, such centralized moral authority is not just dangerous, it alienates potential innovation. Nobody wants to be forced to seek permission for their new functionality. That was, IMO, the primary reason the World Wide Web dominated AOL so quickly.

The way to reach web scale is to make it absolutely trivial for /anyone/ to play the game. Several open source implementations and open standards enabled anyone who wanted to, to set up their own web server and try out the World Wide Web as a service provider. And, despite that lack of central control, lots of companies made lots of money providing enhanced software to manage those systems. So don’t fall for the illusion that central control is required or desirable for a big financial win.

Signing software is understood technology; we can enable signed KIX functionality with a validated identity as a first step towards quality control. Then, by opening up the validation service–and separating it from the distribution/matching of those KIX functions, we can allow software developers and service providers the freedom to innovate and provide their own approaches to what is valid and what isn’t. Some providers will choose to accept ANY signed KIX and simply track reputation. Others will charge a fee for developers, but run through a quality control check and review. By opening it up, you allow users and developers the freedom to manage KIX quality however they like, without building a presumptive “download at your own risk” ecosystem.

With Kynetx the sole authority on “quality” for KIX functionality, we would have both a technical and a political bottleneck that would retard the adoption of a generalized approach to the disaggregated web experience.

[Btw, it would be great if there were a name for the javascript injected into the browser when a KRL rule fires after evaluating the context and the user identity. This is currently just the "associated KIX functionality", which is a bit wordy.]

Fourth, what about privacy and data rights management?

On the whole, it isn’t clear to me what data might be sent around in the claims of various Information Cards, but there is no discussion in the white paper about the data rights associated with that information. If I’m telling Hertz that I’m an AARP member, can they use that data to start sending me junk mail or SPAM targeting AARP members? Frankly, this is a hole in the entire user-centric Identity framework. OpenID Attribute Exchange and Information Cards allow users to use a third party service for the management and presentment of minimally sophisticated facets of identity (much better than username & password), but neither inherently enables users to specify a data rights regime for the claims or attributes so provisioned. In effect, we’ve made it easy for users to provide additional data about themselves, but missed the opportunity for users to easily control the use of that data.

Since Kynetx has a goal of seamlessly augmenting users’ web experience, isn’t it incumbant on them to assure that seamlessness both protects users’ right to privacy and prevents unintended over-customization based on supposedly private data? This is another manifestation of the “Tivo thinks I’m gay” problem, where Tivo analyzes viewing behavior and assumes things about the user, with no way for the user to manage their profile. The data rights problem happens because there is nothing to keep Tivo from telling Hertz, GE, or NBC they think the user is gay. The problem in the Kynetx approach happens when service providers start passing presumably private data to third parties—and users lack the means to control that leakage once the service provider knows certain data. This level of data rights control needs to be built in from the start for VRM and user-driven applications.

Business Model

At the core, I think the business model needs rethinking. Although a CPM-based pricing for KRL evaluations seems to align the value proposition directly with costs, it actually presents more risk and less control to potential customers than other models. It also presents greater risk and less stability for Kynetx itself.

What service providers and developers want to see in a technology platform is one with a free entry point (so you can get testing and trying it ASAP, even if a production system would need a for-fee license), a constrained, predictable cost structure, and economies of scale. Charging per evaluation offers none of these.

This model instead creates an artificial scarcity and then charges by the drop. What you want is to create abundance and sell buckets and hoses and pumps. Doc calls this the “because of” effect. Constraining KRL evaluation to support a pay-by-drink business model will artificially constrain adoption. Instead, run to ubiquity and sell the best tools for leveraging the system you’ve helped create.

At the same time, the evaluation of rulesets will have highly variable demand, with great spikes and drops far outside of Kynetx’s control. Tying revenue to that demand volatility means an unpredictable, wild revenue profile, flattening out only with insanely large numbers of users. This works for mega services like Amazon Web Services, but for a start up moving from initial revenue to predictable cash flow, it can be unsettling. In contrast, an IDE sales model or subscription based service with monthly fees bounds developer expenses and stabilizes the revenue curve.

I like the idea of KRL rulesets. Currently, SwitchBook is planning on using Javascript, RegEx, and XPath, for similar evaluations. That approach not only feels ad-hoc, it is. I’d like to see a unified approach that is flexible, cross-platform, and supported by a good development and test environment.

I think Kynetx could go far by creating an open source platform for KRL rulesets, then providing a robust IDE and testing framework for those who want to manage KRL rules to meet business needs. I think this is nicely pointed to in the mention in the White Paper of A/B testing with different KRLs. This is precisely the kind of sophistication that businesses will need to make the most of KRLs and which can easily be separated from the core infrastructure that enables KRLs in an open way for everybody. Also, the consulting opportunities to analyze, customize, and manage KRL rulesets is a huge business opportunity. Doing that well is likely to remain a black art for a long time to come; helping Fortune 1000 companies do it well should be lucrative.

As Dale Olds put it referring to Novel’s Bandit Project: First, enable an open identity-metasystem, then sell tools to companies to help them manage it.

Collaborations

I like the value proposition of platform-independent identity-based customization. It fits well with VRM’s r-buttons, MyDex’s Personal Data Store service, and SwitchBook’s Search Maps. I think there’s still some brain work to be done figuring out how we can all support each other and simultaneously build sustainable business models, but I’ve no doubt there’s a way if we all invest in exploring those opportunities. Although I focused on questions and concerns about Kynetx in this post, I have great respect for Phil and hope to work with him as both our companies–and the entire VRM community–build out viable solutions to these kinds of problems.

Going into IIW, I understood r-cards simply as a hybrid of InfoCard’s managed and personal card models. Managed cards are issued by another party–all the data associated/transmitted with that card is controlled by that managing party, while personal cards are self-asserted, allowing individuals to serve as their own card provider, controlling all of the associated data. R-cards then, allow a managing party to co-control a card with the user–with some data controlled by the managing party and some controlled by the user.

However, during the IIW demo of r-card, I had an epiphany about how powerful the r-card is, once we actually allow the user to manage the personal claims through multiple, dereferenceable links.

One issue that came up during the demo was that if the “personal” side of the r-card is manually entered claims, such as contact information, then the user is creating a management nightmare: duplicate claims would need to be entered and maintained across many different r-cards. The more r-cards, the worse the problem.

The “obvious” solution discussed at the session was to allow the user to specify specific claims that are served by other IdPs, such as a Personal Address Manager. And for completeness sake, let’s note that such claims could be mashed up from multiple other IdPs, not just a single one. Thus, any number of claims from a particular IdP could act as a sort of sub-card, combining with other subcards at presentation time.

The net result of this is a realization that that perhaps the most interesting thing about r-cards is their use as dynamic cards or aggregate cards or mashup identity cards.

That’s pretty cool in itself.

However, it also struck me that this also potentially fixes usability problems around authorizing a bunch of vendor’s (M) access to identity claims at a variety of different identity providers (N). This potentially requires N points of authorization and authentication for each M vendors (or relying parties). Sub-cards (or r-cards) may combine that task at the point of presentation for much greater user understanding and simplicity.

Since the Card Selector is itself a trusted point of authorization, we should be able to use the “mashup” gesture as explicit authorization for relying parties to access the claims specified in the sub-cards. That is, the UI of creating the r-card/mashup card/dynamic card also explicitly approves access to specific claims from multiple IdPs, since after all, the selector is where you select which claims to present to relying parties.

This adjustment to the Information Card ceremony greatly simplifies the user experience, while retaining all the power of distributed claims at appropriate IdPs. For example, it would allow me to specify my Passport # to United Airlines, as a verifiable claim served by the US Secretary of State IdP (which should be trusted by UA), streamlining any international travel I might do, while retaining my contact info at my Personal Address Manager. All with the same authorization ceremony I use with any information card relying party.

This realization was, for me, the most surprising insight into the power of the r-card. In fact, I’m wondering if the name “r-card” captures it best.

I’ve been following the user-centric Identity movement ever since Doc Searls talked me into attending IIW2006b, an unconference. EIC is a classic Enterprise technology sales conference on identity management. The two events couldn’t be more different, even though both have excellent content and are focused on Identity. EIC was all about big business selling to each other, while IIW is all about engineers making user-centric Identity work.

Identity? A lot of you are familiar with the term, but for those who might not know what I mean, I’m talking about how people authenticate themselves for access to online systems. Traditionally based on usernames and passwords, online Identity presents a host of problems, not the least of which is that an individual may have dozens or even hundreds of different usernames and passwords, one for each new web service or corporate LAN accessed. This proliferation is itself a security risk–as people reuse passwords despite the best efforts of zealous IT gurus everywhere. It is also an information management nightmare: how are we supposed to remember all of that? Which reinforces the problem of reused passwords and unfortunately typically insecure password reset. Today’s identity management software provides solutions to this problem, largely through federation and user-centric Identity.

In short, federation is how corporate IT systems rely on other corporate systems–provided by other departments or even other companies–to authenticate your identity and share information about you. It can be used for authentication, or as in the case of FaceBook’s Beacon, it can be used to pass on highly sensitive personal data. (Blockbuster is now in a lawsuit over this, which I expect they’ll lose.) As Doc Searls likes to put it, federation is about large companies having safe sex with each other, using your data. You can see how this starts to relate to your offline identity, as bits and pieces of your data trail could be used to build a profile and steal your identity or use it for other nefarious purposes, like spamming you with “targeted” ads.

In contrast, user-centric Identity is an architecture where individuals present the credentials of their choice for authentication at online services. Instead of the vendor-to-vendor systems integration and trust contracts of federation, “Relying Parties” authenticate a visitor by relying on the Identity services of an “Identity Provider” of the visitor’s choice. Relying parties may not accept all ID Providers, but in general, the choice of who authenticates your identity lies with you. Key technologies in this space are OpenID, InfoCards, and a variety of standards from the Liberty Alliance. These are the core of the conversation at IIW.

Of course, you can do federation with a user-centric Identity architecture; that’s not the point. The point is that in the user-centric world, the user is in charge of their identity. Or, as Doc Searls advocates, in the user-driven world, the user is driving the transaction.

So, when I sat down with Dale at EIC, I had already heard about Bandit—I even have the t-shirt—yet, I was wondering how Bandit fit into the whole mash up of technology behind user-centric Identity. I know that OpenID is a URL-based approach for identity that has generated significant traction because it is easy for relying parties to implement and for tech savvy users to use. I also know that Higgins and CardSpace both implement Information Cards, or InfoCards: one an open source, extendable client and server implementation, the other a polished proprietary client app from Microsoft. I even had some inkling of the various protocols created and under development by the Liberty Alliance, who started life as a federation standards group and has embraced user-centric approaches as it builds out its services stack. And I even knew about Sxipper and Vidoop, the first a client application that helps users manage their identity presentation online, whether the online services are user-centric or not, and the latter an Identity Provider with a unique method for verifying that you are you.

But what I didn’t quite get was how Bandit fit into it all. I know they are supporters of Higgins and Information Cards, but is Bandit a client app like Sxipper? A card selector like CardSpace? Is it a server implementation that could be used by companies like Vidoop? Is it open source and if so, how does it fit into Novell’s business model?

Dale was able to make it fairly clear: Bandit is an open source project supported by Novell. Bandit provided the card selector for the Higgins project and participate in OSIS (Open Source Identity Systems), a working group of the Identity Commons comprised of different Identity technology providers working towards interoperability. They also support the soon to be announced InfoCard Foundation, although there have been no official announcements by anyone yet about that particular project. Novell, as a separate entity, is putting engineering and organizational resources into these open source and interoperability efforts because they see a bright future in selling Identity management tools once we get the Internet Identity-enabled.

That’s when the light went on. Bandit is about helping create the entire infrastructure of Identity, the Identity Meta-System, as Kim Cameron calls it. Once that infrastructure is in place, Novell will be able to sell companies a number of tools that make it easy to leverage that infrastructure. As Dale put it, the open source part of this is about enabling Identity: assuring that the basic plumping and services are present and understood. The subsequent business model is helping companies manage identity, once we have the essential plumbing in place.

Think of it like http and HTML as enabling the world-wide-web, while products like Cold Fusion, IIS, and Drupal help companies manage web services. The web wouldn’t exist without the open source gift from CERN some fifteen years ago, and without that underlying plumbing of protocols and formats, software providers like Netscape, Microsoft, IBM, Sun, and Novell, wouldn’t have made a dollar selling web technologies to anyone. Instead, with a web-enabled world, literally thousands of companies competed to provide web software, making billions of dollars in the process.

Novell sees a similar dynamic with Identity. Clearly, so does Microsoft and Sun, and hundreds of other companies.

So do I. And it looks pretty damn cool from here.

p.s. my apologies for the lack of links and images. I realized I better post this before the real-time world overtakes me. I hope to see a bunch of you at IIW

p.s. bonus link: Doc Searls on vendors bankrolling open source.

Majority Uncomfortable with Websites Customizing Content Based Visitors Personal Profiles

Level of Comfort Increases When Privacy Safeguards Introduced

ROCHESTER, N.Y.–(BUSINESS WIRE)–A majority of U.S. adults are skeptical about the practice of websites using information about a person’s online activity to customize website content. However, after being introduced to four potential recommendations for improving websites privacy and security polices, U.S. adults become somewhat more comfortable with the websites use of personal information.

Good stuff, although one should read closely to understand exactly what users dislike. Customization isn’t the problem… it’s the unauthorized invasion of privacy. The questions asked by Harris were rather leading. It would be interesting to see what people say to “if asked, would you allow a Search engine to provide enhanced results based on your behavior.” My understanding is most people do opt-in to the advanced features of Google desktop, which asks essentially the same question at install time. People don’t like surreptitious activities, but if you ask up front, it’s much easier for folks to say yes.

BT admits tracking 18,000 users with Phorm systems in 2006

Bummer. I kinda like BT.

Intelligence centers run by states across the country have access to personal information about millions of Americans, including unlisted cellphone numbers, insurance claims, driver’s license photographs and credit reports, according to a document obtained by The Washington Post.

…

Dozens of the organizations known as fusion centers were created after the Sept. 11, 2001, terrorist attacks to identify potential threats and improve the way information is shared. The centers use law enforcement analysts and sophisticated computer systems to compile, or fuse, disparate tips and clues and pass along the refined information to other agencies. They are expected to play important roles in national information-sharing networks that link local, state and federal authorities and enable them to automatically sift their storehouses of records for patterns and clues.

…

The list of information resources was part of a survey conducted last year, officials familiar with the effort said. It shows that, like most police agencies, the fusion centers have subscriptions to private information-broker services that keep records about Americans’ locations, financial holdings, associates, relatives, firearms licenses and the like.

Centers serving New York and other states also tap into a Federal Trade Commission database with information about hundreds of thousands of identity-theft reports, the document and police interviews show.

Pennsylvania buys credit reports and uses face-recognition software to examine driver’s license photos, while analysts in Rhode Island have access to car-rental databases. In Maryland, authorities rely on a little-known data broker called Entersect, which claims it maintains 12 billion records about 98 percent of Americans.

In its online promotional material, Entersect calls itself “the silent partner to municipal, county, state, and federal justice agencies who access our databases every day to locate subjects, develop background information, secure information from a cellular or unlisted number, and much more.”

…

“There is never ever enough information when it comes to terrorism” said Maj. Steven G. O’Donnell, deputy superintendent of the Rhode Island State Police. “That’s what post-9/11 is about.”

The last statement pretty much sums up current institutional thinking on individual liberty and national security: in the fight against terrorism, we have a moral obligation to do everything we can. Everything.

It’s scary how much that position echoes that of fascism. As promoted by Mussolini, fascism builds a moral framework based on the primacy of the state. Fasciste means a bundle of sticks, symbolizing that the group is stronger than any individual. Fascism extends that thinking, declaring that each individual’s rights exist only insofar as they support the state. Or to restate, in the defense of the state, there are no individual rights.

Which, if you think about it, is exactly what anti-terrorist programs assert when claiming that terrorism trumps the rights and privileges of the suspect or accused. Due process, protection from unreasonable searches, freedom of speech. All of these have rights have been trampled on in the name of the War on Terror. The fusion centers are just one more institution created by the mindset that brought us illegal wiretaps, extraordinary extradition, secret prison camps, extra-territorial detention, and torture.

I understand law enforcement’s position. It is easier to enforce laws when you know everything about everyone, just like in a police state (see The Lives of Others for an Academy Award-winning story of pre-information age East Germany’s police state). But it is impossible for a police state to generate the economic and social well-being that emerges in a free society… and it is that well-being which, ultimately, is the core of U.S. global power. Simply put, undermining freedom undermines US security.

In contrast, consider the subtle brilliance of Kim Cameron’s Laws of Identity, in particular, law 2:

2. Minimal Disclosure for a Constrained Use

The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution.

We should build systems that employ identifying information on the basis that a breach is always possible. Such a breach represents a risk. To mitigate risk, it is best to acquire information only on a “need to know” basis, and to retain it only on a “need to retain” basis. By following these practices, we can ensure the least possible damage in the event of a breach.

At the same time, the value of identifying information decreases as the amount decreases. A system built with the principles of information minimalism is therefore a less attractive target for identity theft, reducing risk even further.

By limiting use to an explicit scenario (in conjunction with the use policy described in the Law of Control), the effectiveness of the “need to know” principle in reducing risk is further magnified. There is no longer the possibility of collecting and keeping information “just in case” it might one day be required.

The concept of “least identifying information” should be taken as meaning not only the fewest number of claims, but the information least likely to identify a given individual across multiple contexts. For example, if a scenario requires proof of being a certain age, then it is better to acquire and store the age category rather than the birth date. Date of birth is more likely, in association with other claims, to uniquely identify a subject, and so represents “more identifying information” which should be avoided if it is not needed.

In the same way, unique identifiers that can be reused in other contexts (for example, drivers’ license numbers, Social Security Numbers, and the like) represent “more identifying information” than unique special-purpose identifiers that do not cross context. In this sense, acquiring and storing a Social Security Number represents a much greater risk than assigning a randomly generated student or employee number.

Numerous identity catastrophes have occurred where this law has been broken.

We can also express the Law of Minimal Disclosure this way: aggregation of identifying information also aggregates risk. To minimize risk, minimize aggregation.

Whether or not you think the War on Terror is being handled well, it is a demonstrable fact that human systems fail. People make mistakes.
And that means we can guarantee that institutions–even when acting in our own best interest–will make mistakes, like the admitted errors of the FBI, as reported by the NYT:

F.B.I. Made ‘Blanket’ Demands for Phone Records

WASHINGTON — Senior officials of the Federal Bureau of Investigation repeatedly approved the use of “blanket” records demands to justify the improper collection of thousands of phone records, according to officials briefed on the practice.

…

Under the USA Patriot Act, the F.B.I. received broadened authority to issue the national security letters on its own authority — without the approval of a judge — to gather records like phone bills or e-mail transactions that might be considered relevant to a particular terrorism investigation. The Justice Department inspector general found in March 2007 that the F.B.I. had routinely violated the standards for using the letters and that officials often cited “exigent” or emergency situations that did not really exist in issuing them to phone providers and other private companies.

F.B.I. Says Records Demands Are Curbed

WASHINGTON — The Federal Bureau of Investigation improperly obtained personal information on Americans in numerous terrorism investigations in 2006, but internal practices put in place since then appear to have helped curtail the problems, Bush administration officials said Wednesday.

The Justice Department’s inspector general is expected to issue a report in coming weeks that updates the findings of a major investigation last year into the F.B.I.’s use of so-called national security letters, which allow investigators to obtain telephone, e-mail and financial information on people involved in investigations without a court warrant.

Last year’s report caused an uproar in Congress when it was disclosed that the F.B.I., under powers granted by the USA Patriot Act, had misused its authority to gather records in thousands of instances from 2003 to 2005. The new report from the inspector general will examine the bureau’s use of the records demands in 2006.

At the end of the day, this isn’t about any particular individual, nor even any particular violation of our constitutional rights.

It’s about addressing the systemic problems of the information age. There will always be threats to national security. There will always be the drive to get as much data as possible into the hands of a few, elite law enforcement agencies, capable of acting in the “public good”. And there will always be those individuals who break the rules, whether for good intent or malicious device. We don’t need conspiracy theories to point out the dangers of centralizing all the information about everybody.

What we need is an open-eyed approach to building information systems on user-centric principles, such as Cameron’s seven Laws of Identity. Do that and a vast number of systemic risks of the information age go away.

So, Steve, if you’re listening, take this to the next level and talk about service portability.

It’s great to be able to move my data from service to service. Data portability is a good thing–and we absolutely must address the licensing and privacy issues that cloud that horizon. We also need to be able to move our services from provider to provider.

We can do that today with domain names that we own. We can move our blog or our website or our email from one hosting provider to another. The next step is to extend that to user-controlled services that expose data on our terms, under our control.

Data portability lets everyone pass data around so different service providers can do smart things with that data. Ok. But we learned long ago that software systems are more robust, more scalable, and more maintainable when rather than exposing the data, you expose functions that use that data.

I don’t want people who email me to have direct access to my email data file a server somewhere. That would be insane. I want them to have a well-defined, constrained, complete service interface for sending me email, no matter which service provider I choose. An interface that lets them reach me, but keeps them from reading and deleting other email.

Similarly, we need to take user data, place it in a personal data store (yea! portability!), then provide specific, well-defined access services to third party service providers, using that data, where the user controls those services completely: what services are available, who can access them, and even who the underlying service host is. This is how email works. How websites and blogs work. Next is to take this to user-centric services with complete, seamless data and service portability across the entire cloud.

We know that we need to be able to move our email service from one service provider to another. We know that we need to be able to move our websites to the host of our choice. We know that we need to be able to move our cell phone number from one carrier to another. And we know that we need to be able to change our attorney of record, our doctor, our insurance provider, etc.

We also need to be able to move our MySpace profile and Facebook page anywhere, anytime, on our terms… not just the friends list, but the entire visual gestalt. We need to be able to move our IM and our Twitter services. We need to be able to move our search history from one search provider to another. Pick any service you have come to depend on and understand that dependence creates the need for liberation, the need to get that service on your terms with the provider you prefer, under your complete control.

Without complete portability–services and data portability–innovative service providers will corner markets with data silos and service lock in. Only with transparent, seamless portability, can we leverage the open market and open network to drive to the most desirable and most useful services.

The user-centric identity community is way ahead of the curve on this one, and I’m looking forward to the data portability movement re-discovering the architectural realizations learned the hard way by OpenID, CardSpace, Liberty Alliance, and Higgins, just as the identity community begins to extend from the hard core technology built for identity and starts working towards the applications that will connect ultimately to real value for real users. And it has all been learned and continues to be built through collaborative efforts toward real portability and interoperability at the heart of the infrastructure. In particular, XDI has made great progress hashing out exactly the sort of licensed-based identity-authorized data access that Steve talked about in the podcast. ProjectVRM is driving a user-centric approach to commerce in this conversation and I encourage folks to join us all at the next IIW unconference and to keep an eye open for a VRM workshop sometime later in the year.

Now, according to the Washington Post, an EU judge has pushed the privacy envelope even further, saying “IP addresses are personal data“:

BRUSSELS — IP addresses, strings of numbers that identify computers on the Internet, should generally be regarded as personal information, the head of the European Union‘s group of data privacy regulators said Monday.

This will be interesting to watch…