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

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.

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.

And there is a TON of hard stuff. Just ask Microsoft and Kim Cameron, whose CardSpace is making up for the failures of Passport. Or anyone who thought PKI (public key infrastructure) would solve the problems of Internet Identity. Or David Recordon and the folks of OpenID who brilliantly solved the challenge of a user-centric Single Sign On only to find that was just the first of many challenges of Identity and then answered in part with OpenID 2.0 and OAuth, and continue to answer collaboratively with the rest of the IIW community.

One of the hardest problems discussed at IIW is how we apply the open approach of the Internet to traditional buyer/seller relationships. When customers can come from anywhere and leave at any time, the silo-based world of proprietary lock-in is rapidly becoming outdated. It is not just unsavory for customers, it is actually damaging to vendors who doggedly defend their CRM systems and industrial era mindset. Fixing this problem is what VRM is all about.

In a planning workshop before IIW, a few of the early contributors to VRM met and started to map out the simplest use case we could think of: changing your primary postal address. We’ve all had to do it and it rarely goes smoothly. In the US, it often starts with a Change of Address card sent to the USPS, plus updates to magazine subscriptions, credit card companies, the IRS and the Department of Motor Vehicles, utility companies, ad nauseum… and eventually emails or letters to those friends we want to inform. It is structurally ideal for the user as the point of integration, since ultimately only the user knows for sure when and where they are moving.

What we found was that even this seemingly “simple” use case required a lot of baselining, normalization of language, and formal abstraction to fully clarify the details of what should happen when designed for the users’ needs rather than the vendors’.

In the end (with about 80% completion) it boiled down to a three-step abstract use case narrative, five requirements, and 5 supporting use cases (6 with the base case) for two actors, the AddressChanger and AddressUser:

Use Case Narrative

1. AddressChanger decides to move
2. AddressChanger expresses new address to system (optionally including scheduling information)
3. AddressUsers get the new address when they need it

Requirements

1. Address stored independently of any particular vendor
2. Owner of address can choose who stores canonical source (self-storage ok)
3. Data should be in an open format and portable without data or service loss
4. Data transfer and use is always under user control
5. Vendors can discover the appropriate service for each user

Supporting Use Cases

1. AddressChanger Changes Address (base case)
2. AddressChanger Manages Address Holder Permissions (and data subsets)
3. AddressChanger Accesses Audit Report
4. AddressChanger Reviews Address
5. AddressUser Gets Current Address (pull)
6. AddressUser Subscribes to Address Changes (push)

This level of definition specifically leaves the design and implementation details up to subsequent engineering. The first step for VRM is to formally define the requirements of the system in the individual’s terms. Once we agree on that, we can move to specifics of how the requirements can be met. For instance, in the above definition, the user may or may not directly interface with an “Address Service”. The expression of a new address and the authorization management could all–theoretically–happen at standards-compliant vendor websites (who are in effect acting as the Address Service). For example, when I tell Amazon I have a new address, they could automagically update the cloud so that other authorized vendors get that address, and those “authorized” vendors could have been set up at the same time I signed up for their service. Use cases 5 and 6 are alternative design choices, but the consensus was that a standard system should allow the users to make that choice rather than restricting it at this stage.

As we make design choices, we can clarify the challenges and additional requirements those design choices imply. Those design choices will in turn suggest further use cases, which, in the case of VRM, can be considered for further development and standardization if merited. For example, Amazon currently lets me maintain any number of addresses of record… how would we update the Use Model for the Address Service to allow multiple addresses, including the additional authorization complexities? Plaxo, in contrast, allows two addresses, a personal and a business address, which syncs nicely with their permissions framework for who gets updates to which address. What do these usage situations imply for the entire use model? How should/might we expand the use model to standardize how this advanced functionality is supported in a cross-platform user-centric way?

We then took the simple use case as outlined above and worked through a Gap Analysis, led by Brett McDowell with Paul Madsen, Paul Trevithick, Andy Dale, Doc Searls, and Drummond Reed contributing, among others. That conversation morphed from the AddressChanger use case to the AddressUser to map out how current technologies implement this use case, including any overlap and missing pieces. Here’s what we came up with:

It is more than a bit technical and without a good discussion, it is hard to understand the details (I will point out that the BA in the cloud is British Airways, one of many AddressUsers in the system). Yet, this is the magic of IIW, this is the hard stuff, collaboratively worked out by folks who are intimately involved with all of the competing technologies… because at the end of the day, without interoperability, Identity (and VRM) are just another proprietary data service.

Here’s Paul Madsen’s post-IIW reflection and continuation on the Address Change use case. Good stuff. You can clearly see how the “simple” use case outlined above starts to address sophisticated real-world situations. You can also see how this is just the beginning of a conversation that both explores and defines some critical uses of both Identity and VRM. Paul outlined specifically how the WSF framework could implement the use case with particular design choices along the way, such as when & where the user interfaces with the Address Service. The same scenario could also be implemented with Liberty’s framework or OpenID+OAuth. And as Paul states, just about any aspect of Identity could be managed this way. And for some use cases, we need even further specifications, such as how we manage Personal Health Care records or how a Personal RFP is structured, propagated, and responded to.

I’m looking forward to moving this forward and transforming more of these “simple” use cases into consensus requirements for reinventing the modern marketplace, or as we like to call it, VRM.

Bonus link: a great post by Joel Spolsky of Joel on Software on the value of solving the hard problems.