The term “ownership” simply brings too much baggage from the physical world, suggesting a win-lose, us-verses-them mentality that retards the development of rich, powerful services based on shared information.

Anyone up for sacred cow cheeseburgers?

I’m a member–and a big fan–of Steve Holcombe‘s “Data Ownership in the Cloud” LinkedIn group and I love the efforts of the Dataportability guys and am a big supporter of the Privacy and Public Policy work group at Kantara. There is a lot of good work being done by folks trying to figure out how to give people greater control over the use of data about them (privacy) and gain access to data they use or created (dataportability).

Unfortunately, sometimes the arguments behind these efforts are based on who owns–or who should own–the data. This is not just an intellectual debate or political rallying call, it often undermines our common efforts to build a better system.

Consider this:

1. Privacy as secrecy is dead
2. Data sharing is data copying
3. Transaction data has dual ownership
4. Yours, mine, & ours: Reality is complicated
5. Taking back ownership is confrontational

Privacy as secrecy is dead

First, the data is pretty much already out there. The issue isn’t “How do we keep data from bad people,” it’s “How do we keep people from doing bad things with data?” DRM and crypto and related technology as the sole means to prevent data leakage and data abuse are failures. Sooner or later, the bad guys break the system and get the data.  Sure, there are smart things we can do to protect ourselves. Just like we wear seatbelts and lock our front doors, we should also use SSL and multi-factor authentication, but we can’t count on technology to keep our secrets. We need solutions that work even when the secret is out.

In fact, privacy isn’t about information we keep secret. It is about information we have revealed to someone else with expectation of discretion, e.g., when we tell our doctor about our sexual activities. It’s no longer a secret from the Doctor, but because it is private, we have rules that keep the information from being used inappropriately. Most of the time, with most doctors, it works. Those few who break those rules are dealt with through legal means, both civil and criminal, as well as social approbation. So, because we inherently need to release data to different parties at different times, we can’t control it through secrecy alone. Instead, we need to build a framework for preventing abuse when others do have access to sensitive information. Like in the case with our doctor, we want our service providers to have the data they need to provide the highest quality services.

Data sharing is data copying

Second, in the world of atoms, there can only be one of a thing, which is the reverse of the world of bits. With atoms, even if there are copies, each copy is itself a singular thing. Selling, transferring, or stealing a thing precludes the original owner from continuing to use it.

This isn’t true for information, which can easily be sold, transfered, and stolen without disturbing the original version. In fact, the entire Internet is basically a copy machine, copying IP packets from router to router, as we “send” images, web pages, and emails from user to user and machine to machine–each time a new copy is created whether or not the originating copy is deleted. To think of bits as if they were ownable property leads to attempted solutions like DRM that try to technologically prevent access to the information within the data, which is only good until the first hacker cracks the code and distributes it themselves. Instead, if we build social and legal controls on use, we can give information more freely, but under terms set by each individual when they share that information. Enforced by social and legal rather than purely technological means, this makes the most of the low marginal cost of distributing  online, while retaining control for contributors.

Transaction data has dual ownership

Image via Wikipedia

Third, much interesting data is actually mutually owned… which means the other guy can already do whatever the heck they want with it.  Consider web attention data, the stream of digital crumbs representing the websites we’ve visited and any interactions at each: all our purchases, all our blog posts, all our searches. Everything. Some folks argue that we own that data and therefore have the right to control the use of it. But so too do the owners of the websites we’ve been visiting. We don’t own our http log entries at Amazon. Amazon does. In fact, in every instance where two parties interact, where we engage in some transaction with someone else, both parties are co-creating that information. As such, both parties own it. So, if we tie the issue of control to ownership, then we’ve already lost the battle, because every service provider has solid claims to ownership over the information stored in their log files, just as we, as individuals, own the browsing history stored on our hard drive by Firefox, Internet Explorer and Chrome.

In the movie Fast Times at Ridgemont High, in a confrontation with Mr. Hand, Spicoli argues “If I’m here and you’re here, doesn’t that make it our time?”  Just like the time shared between Spicoli and Mr. Hand, the information created by visiting a website is co-created and co-owned by both the visitor and the website.  Every single interaction between two endpoints on the web generates at least two owners of the underlying data.

This is not a minor issue. The courts have already ruled that if an email is stored for any period of time on a server, the owner of that server has a right to read the email.  So, when “my” email is out there at Gmail or AOL or on our company’s servers, know that it is also, legally, factually, and functionally, already their data.

Yours, mine, & ours: Reality is complicated

Fourth, when two parties come together for any reason, each brings their own data to the exchange. We need a framework that can handle that. Iain Henderson breaks down this complexity in a blog post about your data, my data, and our data, talking about an individual doing business with a vendor, for example, someone buying a car.

“My data” means data that I, as an individual have that is related to the transaction. It could include the kind of car I’m looking for, my budget, and estimates of my spouse’s requirements to approve of a new purchase.

“Your data” means data that the car dealer knows, including the actual cost of the vehicle, the number of units in inventory, the pace of sales, current buzz from other dealers.

“Our Data” means information that both parties have in common. That could be Shared Information, explicitly given by one party to the other in the course of the deal, such as a social security number so the dealer could run a credit check. It could be Mutual Information, generated by the very act of the transaction, such as the final sale price of the vehicle. Or, it could be Overlapping Information, which each party happens to know independently, such as the Manufacturer Suggested Retail Price (MSRP) of a vehicle (which we found online before heading to the dealership).

The ownership of “your” and “my” data is usually clear. However, ownership of the different types of “our” data is a challenge at best.  To complicate matters further, every instance of “my data” is somebody else’s “your data”. In every case, there is this mutually reciprocal relationship between us and them. In the VRM case, we usually think of the individual as owning “my data” and the vendor as owning “your data”, but for the vendor, the reverse is true: to them their data is “my data” and the individual’s data is “your data”. Similar dynamics occur when the other party is an individual. I bring my data, you bring your data, and together we’ll engage with “our” data. We need an approach that respects and applies to everyone’s data, you, me, them, everybody.

In these complex Venn diagrams of ownership, it is more important who controls the data than who owns it.  We’ve already lost the crudest form of control–secrecy–and we are going to continue to lose more as we opt-in to seductive new services based on divulging more and more information: our purchase history, browsing activity, and real-world location data. But we still need to control how all this data is used, to protect our own interests while still enjoying the benefits of the great big copy machine that is the Internet.

Taking back ownership is confrontational

© Regien Paassen | Dreamstime.com

Fifth, we don’t need to pick a fight to change the game. There is a lot of data out there that many of us believe we should have control over. I agree. A lot of people argue that we should have the right to exclude other people’s use because we own the data, because it’s ours in some legal, moral, or ethical framework. The problem is, those other people already have it, and they also believe that they are legitimate owners. In fact, many of them paid for that data, buying it from data aggregators who compile all sorts of things about people, from both public and private sources. This entire ecosystem of customer data is a multi-billion dollar business and every single player “owns” the data they are working with. So if we focus our energy in claiming ownership over that same data in order to take control, we are framing the conversation as a fight, a fight against a powerful, well-healed, well-funded, entrenched bunch of opponents.

Most of these “opponents” are the very people we are trying to win over to our way of thinking. These are the vendors we want to embrace a new way to do business. These are the technologists we want to transform their proven, value-generating CRM systems to work with our data on our terms, instead of their data on their terms. Arguing over ownership puts these potential allies on the defensive, when what we really want is their collaboration.

From Ownership to Authority, Rights, and Responsibilities

Rather than building a regime based on data ownership, I believe we would be better served by building one based on authority, rights, and responsibilities. That is, based on Information Sharing.

• Who has the authority to control access and use of particular information?
• What rights does a party have in using and distributing a piece of information?
• What responsibilities does an information user have to others with respect to that information?

Let’s stop arguing about who owns what and start figuring out how we can share information in ways that allow everyone to win.

When we collect all of our information into a single conceptual repository, and then share access to it with service providers on our own terms, we create a high quality, highly relevant, curated personal data store. This allows us to bootstrap a control regime over all of our data in a way that creates new value for us and for our service providers. Now, instead of iTunes Genius or a Last.FM scrobbler only having access to our media use with their service, they can provide recommendations based on all the information stored in our personal audio data store. We get better recommendations and they get better data to drive their services. This personal data store is entirely under the authority of the user, sharing information with service providers according to specific rights and responsibilities.

The Information Sharing approach neatly sidesteps the complexities involved in privacy and dataportability issues of the information already known by service providers. These remain serious issues, worth addressing. Resolving them will require long term investment in the legal, regulatory, moral, and political systems that govern our society. Fortunately, sharing the information in our personal data store can begin almost immediately once we have working specifications.

This controlled sharing of information will dramatically increase our comfort level when revealing our intentions and interests. We would have control over the use–and would be able to prevent abuse–of that information, while making it easy for service providers to improve our lives in countless ways.

At the Information Sharing Work Group at the Kantara Initiative, Iain Henderson and I are leading a conversation to create a framework for sharing information with service providers, online and off. We are coordinating with folks involved in privacy and dataportability and distinguish our effort by focusing on new information, information created for the purposes of sharing with others to enable a better service experience. Our goal is to create the technical and legal framework for Information Sharing that both protects the individual and enables new services built on previously unshared and unsharable information. In short, we are setting aside the questions of data ownership and focusing on the means for individuals to control that magical, digital pixie dust we sprinkle across every website we visit.

Image by hegarty_david via Flickr

Because the fact is, we want to share information. We want Google to know what we are searching for. We want Orbitz to know where we want to fly. We want Cars.com to know the kind of car we are looking for.

We just don’t want that information to be abused. We don’t want to be spammed, telemarketed, and adverblasted to death. We don’t want companies stockpiling vast data warehouses of personal information outside of our control. We don’t want to be exploited by corporations leveraging asymmetric power to force us to divulge and relinquish control over our addresses, dates of birth, and the names of our friends and family.

What we want is to share our information, on our terms. We want to protect our interests and enable service providers to do truly amazing things for us and on our behalf. This is the promise of the digital age: fabulous new services, under the guidance and control of each of us, individually.

And that is precisely what Information Sharing work group at Kantara is enabling.

The work is a continuation of several years of collaboration with Doc Searls and others at ProjectVRM. We’re building on the principles and conversations of Vendor Relationship Management and User Driven Services to create an industry standard for a legal and technical solution to individually-driven Information Sharing.

Our work group, like all Kantara work groups, is open to all contributors–and non-contributing participants–at no cost.  I invite everyone interested in helping create a user-driven world to join us.

It should be an exciting future.

This material is based upon work supported by the National Science Foundation under Award Number IIP-08488990. Any opinions, findings, and conclusions or recommendations expressed in this publication are those of the author and do not necessarily reflect the views of the National Science Foundation.

User Driven Services look out for their users’ well-being.

If a service is truly acting in our best interests, it will take appropriate measures to protect us from dangers resulting from our use of the service. User Driven Services continually work to minimize user exposure to liability, risk, and potential harm.

Minimal identity information should be acquired and what is acquired should be retained for a minimal period of time, to help reduce the possibility of inappropriate identity correlation and theft. Services should acquire and maintain a minimum amount of confidential data—identity or otherwise—and where feasible, should store that data in an encrypted form. Services should also endeavor to minimize the possibility that their system becomes as vector for attacks of any kind on users, including phishing, viruses, Trojans, and malware. User Driven Services should also expend appropriate duty of care in protecting their systems from hacking and attacks, not simply out of self-interest, but to protect their users’ interests as well.

Examples

Google and Firefox help prevent users from unwittingly visiting potentially malicious websites, working with the StopBadware program at the Berkman Center for Internet and Society. The PCI Security Standards Council oversees payment card industry (PCI) data security standards designed to protect credit card data. Classically, Doctors adhere to the Hippocratic Oath, with its essential commitment to “Do no harm“. Attorneys and accountants have strict ethical and legal obligations to see to the welfare of their clients.

Questions

• Does the service take precautions to prevent potential risks to its users?
• Does the service have adequate security and monitoring in place to effectively identify potential risks and active incursions?
• Does the service manage its data so as to minimize the exposure profile for potential users, both in minimal data acquisition and in timely deletion?

This article is part of a series. It is the tenth 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

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…

User Driven Services can be improved by users.

A closed system can’t predict and satisfy all the needs of all its users, all the time. Sooner or later, someone will eventually desire a new feature or capability beyond the resources or interest of the service provider. User Driven Services take advantage of that motivation, allowing users to directly improve the service itself, both for themselves and others.

Through source code modifications, plugins or extensions, API calls or webhooks, or client-side scripts or macros, users should be able improve the real-time experience of services, without breaking the services and without violating their Terms of Service. Mechanisms should also exist for developers to contribute to improving the standard specifications upon which interoperability and portability rely.

Examples

CGI scripts enable custom code to generate web pages for webservers such as Apache. Open Source projects provide full source code so users can directly modify a service application. Excel macros let users define sophisticated data operations across spreadsheet data. Facebook’s FBML and OpenSocial allow customized widgets integrated into web pages at social networks. The iPhone lets users download and install new applications. Internet Explorer and Firefox allow users to write or install custom plugins like Google Toolbar, Acrobat Reader, Flash, and Quicktime.

Questions

• Can users add functionality to the service through custom code, plug-ins, or extensions?
• Does the service allow interactive access via APIs so that third party applications can provide enhanced, wrap-around or integrating functionality?
• Does the services support webhooks or other callbacks for integration with other online services?
• Do client-side applications allow for client-side scripting or macros?

This article is part of a series. It is the eighth 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

More soon…

7.

Users contribute to User Driven Services.

User Driven Services build on active, engaged participation in value creation. Users should be empowered to augment, annotate, and contribute to the underlying service as much as possible. By enabling users to pro-actively co-create the service experience—and to share that co-created value with other users—services tap into the most motivated, qualified source of content and innovation in their product.

Examples

User profiles, pictures, and status updates make Facebook and MySpace highly personalized digital expressions of personal identity. Flickr lets users load photos to share with others. Facebook, MySpace, and Flickr let users tag and comment on other people’s content as a distributed worldwide dialogue in shared social spaces. Twitter integrates web and SMS updates from, and to, select lists of users to dynamically generate a real-time ambient, global conversation. GetSatisfaction and other online help forums allow users to post questions and get support from others using similar products. IRC is a global distributed chat system.

Questions

• Can users create new content within the service that contributes to value received by other users?
• Can users provide feedback that improves the flow of experience for others?
• Is user input a driver of system value?

This article is part of a series. It is the seventh 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

More soon…

User Driven Services can be hosted on users’ own machines.

If we can’t host our own services, we become beholden to those who can. This creates an artificial barrier to portability, limiting user choice and allowing service providers to charge unnecessarily high costs for their services.

User Driven Services assure users credible alternatives to traditional hosted services. This means that there exist multiple, independent options for users to host their own service running on their own machines, and there also exist hosting solutions that allow users to run their own service on hardware at a co-location facility or running the service on a generically available website hosting provider. These options may be commercial or free, proprietary or open source. Preferably there is at least one open source, free option. It is even better if there are multiple such implementations for different platforms, different programming languages, and different storage and network technologies.

Examples

The LAMP (Linux, Apache, MySQL, Perl/PHP) stack allows anyone to host and run their own advanced web service with custom capabilities. If you own your own machine and have a connected IP address, you can host your own server for email, FTP, gopher, website, Jabber, MUD services, etc. You can host your own blog, fully integrated via pings and trackbacks into the global conversations occurring throughout the blogosphere.  Free and commercial software enable you to host any number of services, either on your own hardware or hosted at standard hosting providers online.

Questions

• Can users host their own implementation of the service on their own hardware?
• Can users host their own service at third party hosting companies?
• Are there free or low-cost licenses available for self hosting?
• Can users host on a variety of hardware and operating system platforms?

This article is part of a series. It is the sixth 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

More soon…

No longer is it sufficient for companies to package a value proposition on their website and then drive traffic to it through ads, search engine optimization, and reciprocal links. Today companies must find ways to provide a value proposition wherever the user might be: on Facebook and Twitter, on their iPhones, and even through 3rd party applications accessing deep into the company’s datasphere through APIs and webhooks.

The Internet is reconfiguring around the user, wherever people happen to be.

I’ve been talking with folks in the VRM community about this topic over the last few years. VRM is, at its core, about starting with the user, re-engineering systems to maximize user freedom and control, and placing the user at the point of integration.  Or, as Doc Searls puts it, creating tools for “both independence and engagement”.

For example, I’ve led several discussions at various VRM workshops on what I call “user driven search“: what would happen if the user were truly in control of all the data related to their search and could engage any Search provider they like with the full scope of that information and under the user’s terms?

In the last several months, I have been advocating a new term has that captures the core direction of both VRM and User Driven Search: “User Driven Services”.

When you configure your services around the user as the primary point of origination, integration, and control, you are building User Driven Services.

Over the next few weeks, I’ll dive into what we mean by User Driven Services; consider it a warm up for both the VRM West Coast Workshop 2009 and the Internet Identity Workshop.

More …

Digg

In Attack of The Frames: VideoEgg Introduces The Twig Ad Bar, Erick Schonfeld blasts the new Twig Ad Bar and DiggBar for not playing well together.  And well he should.

TechCrunch authors Mike Arrington andMG Seigler also got in on the DiggBar discussion:

There are reasons to like the VideoEgg approach–it is essentially an easy way for websites to do a site-wide video bar that is slim and unintrusive. As such, it does exist just at the hosting website, in contrast to DiggBar whish uses frames to flow traffic through their webserver before it reaches your browser… allowing them to bypass most frame escape mechanisms used by websites that don’t want to be enframed elsewhere. Arguably this is an invasion of privacy and misleading to users.

These are real problems. But in my book, the cardinal sin of DiggBar is that it cannot work at Internet Scale.

When other websites try similar approaches, it fails. Just as it does when Twig and DiggBar compete for functionality on the same website.

So, again, please, be good Netizen Developers when you build your webservices. Design and implement them so that they work when everybody does it. Because if you innovate well, everyone will.

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

The Web used to be about pages, then applications, followed by mashups. Today the interesting action is in augmentation.

The leading edge of the Web first moved from static pages to database-driven applications, where user interactions dynamically changed the presentation of content. That is rapidly giving way to multi-site mash-ups and interconnections through APIs and webhooks that, for example, allow one to dynamically use Flickr pictures elsewhere, allow Twhirl post to Twitter, and allow users log in to new websites with their Yahoo! ID.

The mashup/API culture knows that not every website can be the best at everything. Instead, mash up those that are the best into custom-combined web pages.  The shift away from monolithic webservices  began here, applying applied multi-source content to a centralized experience. It was still predicated on users visiting a central website, but it was a start at redefining the perspective from which the web should be constructed.

Web augmentation takes that one step further, moving the locus of control into the browser.

It changes the context of value from a website with widgets on webpages, to capability that travels with the user to every web page they visit, improving the user experience no matter where they go. This enables multi-source/multi-destination content with a distributed, yet integrated experience.

Instead of integrating mashups at the point of the “hosting” web page, augmentation integrates at the point of the user, through the browser, while users visit anywhere online. Moving towards truly user driven services, web augmentation gives priority to the user’s experience rather than website owners’ goals.

For example,

• Ad blockers remove ads from web pages, anywhere
• Pop-up blockers stop annoying javascript pop-up windows
• SkypeOut turns any phone number found in a web page to a button that launches Skype to call that number
• Google Toolbar’s AutoLink button automatically links addresses to online maps, package tracking numbers to delivery status, VIN numbers (US) to vehicle history, and publication ISBN numbers to Amazon.com listings.
• Adaptive Blue’s Glue uses a “topbar” to augment pages with social context about the content of the page you are on: friends’ reviews, recent visitors comments, etc.

As I wrote about previously, Kynetx is also getting into this game, as is Azigo with their RemindMe service. I like both Kynetx and Azigo. I know the folks behind those efforts and believe they are “fighting the good fight”, using user-centric identity to provide advanced and improved user experiences.  SwitchBook is also a web augmentation service, one which doesn’t rely on modifying web pages as Ad Blockers, SkypeOut, and Kynetix allow; we use a toolbar approach more like Adaptive Blue.

It’s a matter of being a good netizen.

One great thing about the Internet is that anyone can use it. And once you enable a capability on the Internet, anyone can do it. Then, when successful, everyone will do it.

So the social ethics question we have to ask ourselves as developers is “What if everyone does do it?”

What if everyone adopts Ad Blockers? What if all my desktop apps try to modify phone numbers on web pages? What if everyone writes web augmentation services that amend, inject, and otherwise manipulate the web pages we see online?

It isn’t about legal questions—which is apparently what killed Microsofts “SmartTags” initiative.

It comes down to a question of open systems. Open systems that work, work when everyone does it, because that’s where you get game-changing economies of scale. The network effect only happens if the value of the system increases when more and more people use it and open systems are all about the network effect.

• What happens if everyone uses TCP/IP?  WhoohoO! Seamless interconnected networks.
• What if everyone uses SMTP, POP, and IMAP?  Yes! You can email anyone, anywhere, anytime!
• What if every company, government agency, and organization uses HTML and http to build online services for their users? Mega efficiency. 24 hour engagement. Low-cost quick answers. Happier people and happier organizations.

Those are good open systems.

But what about these?

What if everyone were to use ad-blockers to completely block every ad they see online, banners and text–everything?  Google would go out of business. The New York Times online would have to go back to a paywall. Vast chunks of the online content business would collapse, because those same ads are what pay the bills.

What if every company that wanted to “augment” your web experience started inserting content, buttons, and javascript into web pages? Even assuming the augmentation is only done by those services you trust and appreciate—just those companies or organizations or movements that you want to help you—if we restrict the augmentation to just those firms, we still have a veritable cacophony of conflicting augmentations. What happens when your library, Borders.com, your favorite local bookstore, all want to “augment” a listing of 1984 by George Orwell? And I haven’t event started on the list of folks wanting to tell you about movie versions, plays, online videos, derivative works, Wikipedia articles, and discussion groups about the book.

Sure, one or two million people using ad blockers isn’t going to put anyone out of business. Nor will the first few intrusive web augmenters. That’s not the point. The point is, how do we build systems that not only work when everyone uses them, but actually gain in value when that happens?

As netizen developers, we have an obligation not just to do what makes us money, or even what makes users happy, but to build systems that work at Internet scale, when everyone does it.  If the systems we build don’t work when everyone tries to get into the game, then we are just being selfish, hording value just because we are first-to-market.

Think about pop-up blockers. On the one hand, pop-up blockers break certain websites. Especially, it seems, sites keen on opening windows for editing or sending a message. So, pop-up blockers aren’t the ideal solution… there is friction for users when people choose to use them. Yet, ask the netizen developer question and the answer is pretty straightforward. “What if everyone used pop-up blockers?” Sites that currently use pop-up windows would redesign to work within the browser rather than popping out new windows. In fact, most of the economic friction with pop-up blockers is in the middle-way, with just some users using them and others not. Arguably, the world would be a better place if everyone were to use pop-up blockers. So pop-up blockers aren’t ethically problematic, rather, they are an incomplete solution to a tricky problem.

Being a good netizen requires thinking about these issues, just as being a good citizen means thinking about how private actions affect the public good. To build out this next generation of identity-enabled web augmentation services, we would all do well to think through what happens when everyone does it.

Finally, although Adaptive Blue and SwitchBook both use a toolbar approach to augmentation—without manipulating the underlying web pages— similar issues challenge us as we aim for Internet scale. There are only so many toolbars users will install. Each is borrowing screen real estate from the core web experience. This gets even worse when you consider the possibility of augmenting web experiences in a mobile device. The mind boggles at that challenge.

Ultimately, what we need is an open system that allows all of these types of augmentations from Adaptive Blue, SwitchBook, Kynetx, Azigo, Google, Skype, and others, to mingle smoothly in the same interface.

We (SwitchBook) haven’t begun to solve that problem, but we look forward to working with the rest of the open community to figure out how to make it work. At the end of the day, the collection of interfaces and services that provide the most value to users is going to win. Everything between here and there is just wasted development dollars, even if it generates millions in profits for those fighting the tide.

In an open world, the best solution eventually rises to the top. Let’s see if we can speed that up and stop wasting money on closed, proprietary, unscalable solutions.