Social Bovines

Marc Canter's post reminded me of microformats. The microformats model for identity information is to embed the data within existing HTML pages rather than define new XML-based protocols for its sharing.

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging).

Microformats leverage existing XHTML tags such as address, cite, and blockquote and attributes such as rel, rev, and title to create semantically meaningful information. Essentially, profiles of XHTML for encoding particular slices of identity (e.g. personal info, calendar data, etc) as HTML metadata.

There is a microformat proposal for expressing social identity, it's called XHTML Friends Network (XFN). In XFN, the social connections between users manifest themselves as hyper-links, just like connections between pages. Such an XFN link is distinguished from a normal link through its use of the rel attribute on the HTML <a> element. For instance, a user named Bob could represent the nature of their relationships to Josh, Kat, and Mary with the following elements embedded somewhere in their personal page (e.g. a blog).

<a href="http://josh.example.com/" rel="friend met">Josh</a>
<a href="http://kat.example.com/" rel="met acquaintance">Kat</a>
<a href="http://mary.example.com/" rel="co-worker friend met">Mary</a>

Each of the three could have a similar set of links in their pages, perhaps including a link back to Bob to represent a bi-lateral relationship. Depending on your point of view, the ability to indicate a relationship to somebody else without their permission or action is either a good thing or a bad thing. One could, for instance, indicate a totally unrequited romantic relationship.

XFN defines a short list of allowed values for the rel attribute, things like met, colleague, sibling, etc. For some applications this level of granularity for describing relationships might be sufficient - but not for many others (because ultimately the social data has to enable something or else it's simply an ego trip). To be fair I expect this was a deliberate trade-off in favour of simplicity over flexibility.

The alternative is to not attempt to prescribe what are valid relationship types but rather ensure that users can specify their own. The Liberty Alliance's People Service defines two such mechanisms in support of this model, groups and tags. Groups allow a user to define collections of the base members of their people service, the tag element can be used to add additional metadata to both members and groups. For instance, I might define a 'Identity Bloggers' group to carry those individuals who I wished to be able to leave comments on this blog. For other users who didn't quite fit this grouping, but for whom I still wished to enable commenting, I could define a 'respected' tag and apply it to each such member.

There are of course bigger issues dividing the microformats and XML protocols camps. Microformat advocates preach 'pave the cowpaths'. Sure, if the cows have been going to interesting places.

Identity Enabled Devices

ABC News anchor Bob Woodruff and his cameraman Doug Vogt were injured in Iraq by an IED (Improvised Explosive Device).

Two thoughts:

1. As opposed to naturally occuring explosive devices? Presumably the distinction is between explosive devices created by recognized arms manufacturers and those cobbled together with duct tape and spit. Given the obviously lethal nature of any such ad hoc devices, is the distinction relevant? Do convoy drivers say to themselves as they drive through hot spots 'Phew, only need to worry about brand name bombs today'?
   
2. The military must be the only community more inclined to create unnecessary acronyms than IT.
   

Social silos

Identity woman complains about the duplication & fragmentation that people current face in maintaining 'buddy lists'.

Each phone handset has one for address books -

• Motorola,
• Nokia

Telecom Incumbents

• Orange(france telecom),
• British Telecom

Cool “apps”

• YackPack
• Jazz

The Incumbent internet players

• ebay/Paypal/skype [PESk]
• Yahoo!
• Google (using Jabber)
• Microsoft

Amen to that.

Liberty People Service.

What does user-centric identity mean?

Granted that it makes for lovely slideware with a smiling face in the centre of appropriate clip art for banks, hospitals etc but I honestly don't know what it is.

Despite its popularity, I haven't come across a clear definition of what are the criteria to be met for an identity-system to be considered 'user-centric'. And yet, this doesn't stop people from characterizing those identity systems they don't favour as unable to meet these undefined criteria.

Perhaps user-centricity can be defined in the negative, i.e. determining the common characteristics of systems that don't have it.

So, which of the below are NOT user-centric?

• URI-based system under sole control of user (i.e. personal server)
  
• Liberty-based system with identity data hosted on the client and over which users have sole control
  
• Infocard mediating interactions between PC-hosted identity provider (over which users have sole control) & network service provider
  
  
• URI-based system with identity data hosted on user's behalf at network providers at which users are given mechanisms in order to specify policy over identity release
  
• Liberty-based system with identity data hosted on user's behalf at network providers at which users are given mechanisms in order to specify policy over identity release
  
• Infocard mediating interactions between service provider and network identity provider storing identity data on behalf of user and at which users are given mechanisms in order to specify policy over identity release
  
• Shibboleth-based system with identity data hosted on user's behalf at network providers at which users are given mechanisms in order to specify policy over identity release
  
• sxip-based system with identity data hosted at network providers at which users are given mechanisms in order to specify policy over identity release
  
  
• URI-based enterprise system with identity data hosted on user's behalf at network providers at which users are not given mechanisms in order to specify policy over identity release
  
• Liberty-based enterprise system with identity data hosted on user's behalf at network providers at which users are not given mechanisms in order to specify policy over identity release
  
• Enterprise Infocard mediating interactions between service provider and network identity provider storing identity data on behalf of user and at which users are not given mechanisms in order to specify policy over identity release
  
• Shibboleth-based system with identity data hosted on user's behalf at network providers at which users are not given mechanisms in order to specify policy over identity release
  
• sxip-based enterprise system with identity data hosted at network providers at which users are not given mechanisms in order to specify policy over identity release
  

Other than the enterprise deployments above, where it can be argued that the user's control over their identity are scoped by their employment contract, I believe all of the above can be user-centric.

What I take out of this exercise is that the ultimate determinant of an identity-systems user-centricity is the degree of control the user has over the data that comprises their identity. And, as far as I can tell, all of the above systems can support such control, but none can guarantee it.

For instance, although Liberty's protocols have explicit support for carrying user consent decisions for the release of identity, and implementations of these protocols provide mechanisms for the user-administered definition of such policy, nothing forces a deployment to avail itself of either. Liberty's protocols could definitely be deployed in a non user-centric manner. As could any other identity system.

More sxore

Sxip responded to my "Writeable Web & sxore" post of a few days ago in which I tried to understand the sxip-based sxore system for controlling blog spam.

Fundamentally, what I wrote yesterday was that sxore, like many other identity systems, relies on a trusted 3rd party to make assertions about users to relying parties. In the sxore system, the trusted 3rd party is sxore.com and the relying parties are the blogs at which a user wishes to post a comment. By either signing in to their sxore account, or completing a captcha there, would be commenters rise above the suspicion threshold sufficiently such that sxore.com recommends to the relying parties that their comments are authentic and not spam.

Sxip acknowledges that I had it mostly right based on what info is available but don't have all the details:

Paul Madsen thinks that Dion Hinchcliffe is off the mark about how sxore works. However sxore does more than Paul describes.

They go on to say

In sxore, as members write comments and are moderated, they build up an aggregate reputation that sxore can then use to auto-moderate comments. That aggregate reputation will also be portable, members of sxore will be able to take it to other sites using SXIP 2.0. Those other sites can verify that a user has a good reputation on another site, in this case at sxore.com.

So, as bloggers use sxore to moderate my comments, sxore.com builds up an overall reputation for me across the different blogs at which I've commented. Eventually, and presumably based on a preference specified by individual bloggers, my comments could be automatically approved based on that reputation. Also, the above gives the impression that the reputation, established in the context of blog posting, could be transferable to other contexts, e.g. online commerce or rating systems.

While I think such functionality is valid and useful (and makes me think that perhaps Liberty should be thinking about a 'Reputation Service' built on top of our Identity Web Services Framework) , I don't think it changes the model. Portable reputation won't mean a thing unless it's coming from an entity that a consumer of such reputation has reason to believe gives its stamp of approval only to deserving individuals (twisted grammar above to ensure that I didn't use the word 'trust')

If I show up at a blog and self-assert 'I have a reputation for making witty and relevant comments' I can guess where any such comments will be filed. If however, sxore.com were to assert the same thing, then I would be much more likely to have my spelling corrections and similarly insightful comments approved.

Writeable Web & sxore

Dion Hinchliffe writes about the potential of Sxip's sxore as a means of bringing responsibility to the writeable web.

He wonders

If I understand it fully, Identity 2.0-compliant credentials can be shown to anyone and validated on the spot, without consulting a validating authority

With the same caveat about fully understanding sxore, I think Dion is off the mark here on how sxore works.

From what I can tell from the sxore FAQ and playing around with the sites that are enabled, with sxore, when somebody wants to leave a comment on some post or article, they have 2 choices, they can complete a captcha to prove they are human and not a bot, or they can log-in to their sxore account. Either way, they prove their humanity or authenticate at sxore.com. Sxore.com then uses the sxip protocols in order to assert to the original site that the user is, at minimum, human.

So, with respect to Dion's conjecture above, the individual wishing to leave a comment does very definitely provide their credentials to a validation authority, specifically sxore.com (and perhaps other similar sxore-enabled authorities in the future).

This is not to question the value of sxore, it appears a slick (and user-friendly) solution for the problem of blog spam. But it does not do away with the role of an authoritative identity provider validating credentials and vouching for identity to relying party sites. And so, at this most basic level, sxore (and Sxip's larger Identity 2.0) appears to be consistent with many of the other identity systems.

Microsoft Codename Max

Codename Max is a cool P2P photo sharing (beta) application from Microsoft. The Channel 9 blog has an interesting video interview with the development team.

Haven't installed it but from the video's description of how it works, the mechanism for inviting friends to share your photos is the standard one - you specify their email addresses (seemingly linked to a .NET Passport?) and they receive an email with a link to click - after which a P2P connection is established between both machines for the transfer of the relevant files.

I saw no mention of support for tracking social relationships, e.g. friends, once invited to access one batch of photos, would be remembered for the next time. Or, even better, for Max to be able to use some common social layer not specific to photo sharing and isolated on the user's PC.

Theoretically possible would be that, when the user indicated they wanted to share photos (or videos, music etc), the Max desktop app would call out using the protocols defined by the Liberty People Service to view the list of friends, family etc with whom sharing was desired. Friends, once invited, could be optionally remembered for subsequent availibility to other social applications.

I take some solace in the fact that physicists who believe in the parallel-universe interpretation of quantum mechanics will argue that this is indeed happening in some other less-divided identity universe.

Agreement on Identity Rights Agreements

Drummond Reed refers to a Phil Windley post on the value of "identity rights agreements" - pre-defined policies governing the use and sharing of identity info.

When asking for identity info, the requestor would include an identifier (likely some URI) for whatever policy it would abide by if the requested data was released to it. Likewise, the custodian would include the appropriate URI for the policy governing any released data. Drummond & Phil point to Creative Commons as an example of the principle; P3P is another.

Phil throws out some possibilities for those policies that would warrant an identifier.

* Post publicly (broadcast)
* Share with anyone, but can’t broadcast
* Share with self and partners with which you have a legal agreement to honor this agreement
* Keep to self
* Stored encrypted
* Use for this purpose and destroy

The identifiers would serve as a simple and easily parsed syntax for the complete policies (captured and accessible somewhere).

Liberty ID-WSF has a container in our protocols for carrying such identifiers (an empty container because, as yet, we have not ourselves defined any policy syntax or identifiers - despite some early work along this route). The <UsageDirective> SOAP header is defined in the SOAP Binding specification.

Participants in the ID-WSF framework may need to indicate the privacy policy associated with a message. To facilitate this, senders, acting as either a client or a server, may add one or more <UsageDirective> header blocks to the SOAP Header of the message being sent. A appearing in a SOAP-based ID-* request message expresses intended usage. A <UsageDirective> appearing in a response expresses how the receiver of the response is to use the response data. A <UsageDirective> in a response message containing no ID-WSF response message data, a fault response for example, may be used to express policies acceptable to the responder.

Drummond points to Identity Commons as the place where relevant policies (and agreed upon identifiers) might be defined.

Identity rights agreements are becoming one of the galvanizing forces for a revitalized Identity Commons. One of the reasons is the oft-used analogy that “Identity Commons should be to identity rights what Creative Commons is to copyright".

This work would be really interesting & valuable. Identity agreements and their identifiers could be common across particular identity systems (e.g. Liberty, Shib, OpenID, LID, SXIP, WS-*, etc) and so serve as a key piece of any metasystem that underlies or unites such systems.

Testing, testing

In the Liberty Web Services Framework, the Data Services Template provides a design-pattern for identity services to (optionally) avail themselves of. At its most basic, DST defines a CRUD pattern so that specifications for individual identity services (e.g. for calendar data, for geolocation, for presence etc ) don't have to reinvent the wheel.

A key piece of upcoming functionality in DST is the ability to test identity attributes without necessarily actually sharing them. In many situations, a request for a user's identity is motivated by the requestor wishing to ask a question about the data rather than needing to know it's actual value. Examples include 'Is this person under 18?' (or more generally 'Is this person a minor'?), 'Is this person a Gold-Level Frequent Flyer' etc.

While the requestor could ask for the data itself and then determine the answer, this means sharing the attribute when such sharing isn't necessary. Minimal disclosure (surely some sort of Identity Law) dictates that a requestor should ask for, and a provider subsequently release, only the minimally acceptable amount of identity.

If, in order to deliver some service, all a provider needs to know is whether I'm over 18 years old, telling it that I'm (a spry) 42 breaks the principle. If, in order to bombard me with unwanted mobile coupons for a muffin, all a coffee shop chain needs to know is when I'm within 500 m of one of its stores, my mobile provider telling it my actual location (even if obfuscated through accuracy limitations) unnecessarily shares my identity info.

I expect there is an 'Identity Corollary' in here.

Liberty People Service for Group-based Access Control

Allowing users to define access control for their online resources in terms of their online friends & colleagues was one of the key use-cases that drove the development of the Liberty Alliance's People Service. We recognized that often times a user will wish to define access rights against a group of such friends rather than each individually, e.g. 'Allow all members of the "Soccer Team" group to see my online calendar and allow all members of 'Coaching Staff' to add entries'.

In this scenario, Alice has defined access rules to some of her resources at aservice provider (SPa) based on membership in a 'Work Friends' group she maintains at her people service (PSa). Anybody who is in the group can see the page etc, anybody else can't.

Bob is a friend of Alice and she has previously both added him to her People Service as well as to the group in question. Now, when Bob appears at SPa and tries to access the resource in question, in order to enforce Alice's policy, SPa must determine if Bob is a member of the 'Work Friends' group.

The messages below (a mixture of SAML & Liberty WSF) give an idea of how this might work.

1. Bob shows up at SPa and tries to access the resource in question.

2. SPa asks 'Who are you?'.

3. Bob wants to use his identity provider account and so says 'Ask IDPb'.

4. SPa redirects Bob to IDPb with a SAML AuthnRequest message.

    <samlp:AuthnRequest
      ID="NTT7630E00861279F0ADC63E241D0926D0B"
      Version="2.0" IssueInstant="...">
      <saml:Issuer 
          format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://spa.com
      </saml:issuer>
      <samlp:NameIdpolicy 
         format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
    </samlp:Nameidpolicy>
   <samlp:AuthnRequest>
 

5. IDPb authenticates Bob.

6. IDPb sends a SAML Response to SPa with a SAML AuthnStatement carrying a name identifier for Bob (this possibly a one-time anonymous identifier for Bob)

   <samlp:Response id="NTT3F633E3F712BAC4B0804714431D46D7B"
        inresponseto="NTT7630E00861279F0ADC63E241D0926D0B" version="2.0" 
        issueinstant="...">
      <saml:Issuer 
        format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://idpb.com
      </saml:Sssuer>
      <samlp:Status>
        <samlp:Statuscode value="urn:oasis:names:tc:SAML:2.0:status:Success">
      </samlp:Statuscode>
      <saml:Assertion version="2.0" issueinstant="..." id="NTT02068C15DFB">
        <saml:Issuer
           format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
          https://idpb.com
        </saml:Issuer>
        <saml:Subject>
          <saml:NameID namequalifier="https://idpb.com"    
            format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
            e0b735bf9d1f3959241d3584733d704c
          </saml:NameID>
        </saml:Subject>
        <saml:AuthnStatement authninstant="..." sessionindex="...">
          <saml:AuthnContext>AuthnContext goes here</saml:AuthnContext>
        </saml:AuthnStatement>
      </saml:Assertion>
    </samlp:Response>

7. Knowing that it needs to 'talk' to PSa about Bob, SPa sends IDPb an <sa:TokenMap> message, providing the previous name identifier for Bob and specifying PSa as the target namespace.

    <sa:TokenMap>
      <saml:NameID namequalifier="https://idpb.com" 
          format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
        e0b735bf9d1f3959241d3584733d704c
      </saml:NameID>
      <TokenPolicy spnamequalifier="https://psa.com">
      </TokenPolicy>
    </TokenMap>
 

8. IDPb returns an appropriately targetted(and likely encrypted) identifier for Bob that PSa will recognize.

    <sa:TokenResponse>
      <sec:Token>
        <saml:Assertion>
         identity token for Bob in PS's namespace
        </saml:Assertion>
      </sec:Token>
    </sa:TokenResponse>

9. As Alice has previously defined her access control rules in terms of a group maintained at PSa, SPa knows how to invoke PSa. SPa sends a query to PSa questioning Bob's membership in the group in question (the object for which is identified by the TargetID element), using the token just obtained from Bob's IDP to identity him.

    <ps:TestMembershipRequest>
      <ps:TargetID>https://ps.com/nmerflas</ps:TargetID>
      <sec:Token>
        <saml:Assertion>
         identity token for Bob in PS's namespace
        </saml:Assertion>
      </sec:Token>
    </ps:TestMembershipTequest>

10. PSa extracts the identity token, decrypts the encrypted identifier in the identity token, looks up the group in question, and finds that Bob is indeed a member (Alice having previously placed him there).

11. Consequently, PSa returns 'true' to SPa's original query.

    <ps:TestMembershipResponse>
      <Status code="OK">
       <ps:TestResult>true</ps:TestResult>
      </Status>
    </ps:TestMembershipResponse>

12. Confident that Bob is a member of the group against which Alice defined privileges, SPa grants Bob access to the resource in question.

Of course, all Bob would see of the above would be appropriate access to Alice's resources, everything happening behind the scenes.

Alternatively, when Alice first defined her access rule in terms of the 'Work Friend's group, the SPa could have then gone out and obtained individual identity tokens for all members of the group (from their respective IDPs). If and when somebody showed up trying to access a resource, SPa would check the identifier they presented against those in teh approved list and grant access accordingly. The issue with this model is dealing with changing group membership.

Dwight Shrute

Lots of wisdom here.

When there is a chill in the air, there are colder
weather patterns coming down from Canada.

In Canada it is always winter. Sometimes the sun
never rises in Canada. Harp seals abound until they
are brutally slaughtered by Canadians. They worship
maple syrup, hockey and Alanis Morisette. I hate
Canadians.

Seating inertia

I feel like Andy Rooney even asking this but .....

Have you ever wondered why, when people attend a multi-day meeting, whatever seat they happened to choose the first day they will typically sit in for the duration?

Is this some sort of sad vestige of a territorial imperative? An artifact of Grade 3 classrooms?

Vancouver Voted Best Canoing in Canada

SXIP's corporate blog brags that Vancouver was again voted the Best City in Canada.

Vancouver is a great city and may even deserve the award.

Truth in advertising would however suggest that SXIP at least acknowledge the occasional downside .

Make it into a bonus, e.g. 'come work for us and improve your swimming'.

Group Sex?

Over at weaverluke, Luke Razzell considers the possibility of a genetic explanation to why human's generally like to hang around those that think like ourselves

a man and woman who share a point of view are presumably more likely to reproduce together than a man and woman who do not.

Luke's theory offers no explanation as to why both men and women seek out similar-minded people of the same sex. If reproductive success isn't necesary to explain why males seek out other males (or females seek out other females) that share their point of view, why should we to attribute to it the same phenomena when it occurs between males and females?

Luke goes on to wonder

Could there be a genetic component in the formation of communities of thought?

I expect that any link between reproductive success and the tendency of humans to form into groups is less direct. If you aren't in a group you are on your own. In our evolutionary past, being alone would almost certainly have had an impact on your ability to pass genes on - starving when food is scarce, being swallowed by a lion or speared by another tribe would surely have cramped your moves on Friday night down at the pub.

Kemp

Nokia's John Kemp, at least within the Liberty Alliance, is one of those 'last name only' people. If he comes up in a conversation (and he does often, typically along the lines of 'I don't know how that works, who can we ask?'), people typically refer to him as 'Kemp' - as in 'Kemp would know'.

I don't know why - we haven't had a huge number of 'Johns' that would motivate such a disambiguating identifier.

Maybe it's the British accent that encourages some degree of social distance. But, he was a key contributor to the People Service, the key value of which is to decrease social distance.

A mystery.

Regardless, Kemp is blogging. And Kemp would know.

I feel like Microsoft (or a politician)

Sxip, Marc Canter and Johannes Ernst have blogged on Liberty's People Service.

All posts are an interesting mix of guarded approval and suspicion.

From the Sxip corporate blog

It will be interesting to see whether this is an open or closed "circle
of trust" approach to IdM for individuals, to what extent it will be
user vs silo-centric, and how complicated it is.

From Marc

I won’t go into the irony of announcing this right after CES and during MacWorld. I wonder if these Liberty people even have a clue what that ruckus is all about.

way - I’ll give them the benefit of the doubt. It’s just too coolio to be negative about.

From Johannes

I've got to admit that this is not something I would have expected from Liberty ... it runs counter to its traditional reputation ... but I very much like the direction this is going.

While it is definitely gratifying to see respected players see value in the People Service (and hopefully think about how they might work with it), I honestly don't understand why it's seen as such a paradigm shift and/or breakout for Liberty.

Internal to the Alliance, the People Service is very definitely seen as evolution rather than revolution. Whereas with the first version of our Web Services Framework we could deal with transactions involving single identities, with the People Service (as part of the soon to be finalized ID-WSF 2.0) we can now deal with transactions involving two identities. Definitely 'cool io' and interesting but in no way inconsistent with the architecture and philosophy that we've always followed. Just new functionality layered on top of what we already had. Put another way, just another slice of identity that can be shared. And, as before, supporting a range of deployment options, e.g. a People Service on the network, a People Service on a PC, or on a phone.

Guarded approval tempered by suspicion. My mother-in-law would recognize the dynamic.

Red Queen

The Red Queen principle is the concept in evolutionary science that animals engage in cyclic arms-races with their predators, prey, and parasites. The arms races are cyclical because, typically, the long term balance of power stays the same despite periodic reversals of that balance. Both sides must evolve merely to keep this balance.

The allusion is to Lewis Carol's 'Through the Looking Glass' in which a character of that name states to Alice:

"in this place it takes all the running you can do, to keep in the same place."

Cheetahs are almost certainly faster than their ancestors, and gazelles similarly improved relative to earlier versions. Despite this, today's cheetahs probably don't dine on fresh gazelle significantly more than previous generations. Both sides are 'fitter', but that hasn't changed the general dynamic. If either side were to gain too significant an advantage (e.g. cheetahs either catching everything in sight or starving), evolutionary pressure would act to bring things back.

We are seeing a number of seemingly Red Queen style arms races on today's Net - that between spammers and email clients, that between phishers (and other identity thieves) and unsuspecting email clickers, that between WAM products from competing vendors, etc.

For identity theft in particular, as defenses improve against existing attacks, the phishers/pharmers develop more elegant variations. Either side may enjoy a temporary advantage, but only until the other side catches up. If this race truly is a Red Queen phenomena, neither side will ever win out right and the general severity of the identity theft problem will remain relatively constant over time. Lets hope not.

p.s. One currently respected theory (as championed by Matt Ridley in his "Red Queen" book) for explaining the evolution (and relative ubiquity) of sex is that the genetic mixing that sexual reproduction enables (relative to asexual reproduction) gives hosts an advantage over the parasites and germs that attack them (the popularity of internet porn notwithstanding, sex does need an explanation because its costs relative to asexual reproduction are clear). By giving the genes a good churning with every generation, the theory posits that sex allows hosts to present a moving target to the pathogens that would prey on it. It's not clear to me what conclusions might be drawn from such a theory for the usefulness of sex for the battle between WAM products. Maybe being a product manager would be a better job than I've always believed.

Who do I sue?

Wired reports that some residents of New York State are up in arms over plans to install wind turbines in and around their homes.

The comments of one (particularly visionary) resident suggest the potential for an as yet untouched identity application. Patricia Oakes, a Hartsville, New York, resident asked:

"...Who do I sue if I have any health problems or my property value decreases because of this project?"

Beyond my admiration for Ms. Oakes' foresight (too often people wait till after suffering harm before they start contemplating damages) and the specifics of the windmill issue, surely an identity metasystem could help Patricia (and others with a litigious bent) obtain an answer to this question?

Currently it is a mostly hit-and-miss process by which Patricia finds potential candidates for her lawsuits. This ad-hoc nature allmost certainly means that she is unable to be fully compensated for the harm (known or otherwise) from which she is suffering.

Why not allow people to store and publish the list of current ailments, grievances, damages, etc that they are currently suffering from (or might in the future) - this identity info discoverable by 'suebots'. Lawyers would similarly publish the class-action lawsuits they were prosecuting (or even contemplating prosecuting should demand warrant) and the relevant individuals could be found and matched. People needn't even know they were part of a particular lawsuit, simply wronged in a high-level and non-specific manner.

For too long, American's have borne the burden themselves of finding litigants for their potential lawsuits. They need our help.