Burton Group Identity Blog

Personas Need Reputation, Too! The Idiot’s Guide to Relational Continuity Sockets Layer (RCSL)

Blogger: Mike Neuenschwander

With all the interest in LLP last week, we’re getting a lot of questions about RCSL. For example, the blog team over at Emergent Chaos asks what work we have done on RCSL. I’ve also had several e-mails asking me how RCSL compares to various Internet standards.

So it seems as good a time as any to write up our latest thinking on RCSL. Here it goes.

What is RCSL?

RCSL is a protocol. It doesn’t exist yet; it’s something we’re proposing.

We’re not stuck on the name—think of it as a codename. Kim Cameron claims “the name makes it sound like scientists are still glueing [sic] body parts together in the basement.” Since it’s nearly Halloween, we’ll stick with RCSL at least through October 31st.

Some of RCSL’s characteristics are:

• It enables multiple parties to share a single session

• Sessions can be long-lived (days, weeks, months)

• It emits “claims” based on the outcome of the session, whether broken prematurely, altered, or completed successfully

Why is this interesting? RCSL is the basis for a reputation model for the Internet. It also provides a foundation for resilient, stable relationships and transactions online.

Here’s how it works:

1. Participants are required to ante up collateral to start an RCSL session. How much and of what kind is worked out among the participants. We’re hoping that patterns emerge for common transaction types and that participants can simply point to a template—a.k.a. “game”—with pre-specified rules, roles, and outcomes.
2. RCSL then creates a multi-party session. The RCSL session can be encrypted, but it doesn’t have to be—in some cases you may want others to observe the session. Either way, each participant receives a key to the session. The key also designates the participant’s role in the session.
3. Participants remain in the RCSL session until all parties agree to end the session. The conditions for exit can be predefined, so the session ends automatically when conditions are met. Any changes in the RCSL configuration causes the protocol to generate claims about the change. For example, if someone drops out early or if the collaboration fails, RCSL sends a notification message (a claim—possibly through an RSS feed) to a predetermined aggregator.
4. RCSL aggregators combine RCSL outcomes with other information to establish participants’ ratings.
5. RCSL claims can be used to release escrowed collateral and grant merits of some kind.

Keys to RCSL sessions behave like real-life keys

With RCSL, each participant is given a key to the session. If anyone tampers with the session, the participants are aware of it immediately—it’s like someone budding into a conversation. If the participants welcome the newcomer, RCSL reissues keys to everyone in the session including the new participant. If the participants see the newcomer as an intruder, they can take measures to shut him/her out.

Participants can transfer their role in the session to another entity, but doing so also resets session keys so the new role holder receives a key and the exiting participant is locked out.

Another important feature about RCSL keys is that you know when you’re no longer in possession of one. If you lose an RCSL key or if one is stolen, it will be apparent to the owner. Just like in the real world, if you lose your wallet or cell phone, you usually realize it quickly.

My presentation at Catalyst North America offered a scenario for how RCSL works and I’m doing an encore in Barcelona next week – come check it out. For more background on why RCSL is important, see the Law of Relational Risk—specifically the principle of Relational Continuity.

What the Identity Oracle Isn’t

Blogger: Bob Blakley

Kim Cameron of Microsoft picked up the New York Times’ coverage of our LLP concept in a blog entry today.  His entry is generally excellent, but I’d like to pick on one little piece of it.  In the course of discussing the Burton Group’s identity concepts, Kim writes:

“Bob provides links to more resources, including one on Identity Oracles  - his sexy name for the  claims transformer generating “minimal disclosure tokens”.”

It’s important to be very clear here, so I’m going to say this pretty bluntly.  This statement is utterly and completely wrong.  An Identity Oracle is NOT a “claims transformer generating minimal disclosure tokens”.  It’s not even a claims transformer.  It’s not even a server.  It’s not even technology.

I’ve said twenty times from various stages and in writing on my personal blog and here that as long as we continue to try to solve privacy problems using technology, we are going to continue to fail, and the Internet will continue to lack an identity layer, and it will continue to be a privacy hazard.  Identity and privacy are not technology problems – they’re social, legal, and economic problems – and no technology can solve these problems.

The Identity Oracle is not a technology.  It’s a business.  Its business plan says “We allow people to enjoy the benefits of their identities while protecting them against the risks of misuse of their identities”.   It charges money for its services.  It works like this:

A human – let’s call him “Bob” – signs up for an account with the Identity Oracle.  The Identity Oracle collects some personal information about Bob, and signs a legally binding contract with Bob describing how it will use and disclose the information, and how it will protect the information against uses and disclosures which are not allowed by the contract.  The contract prescribes a set of penalties – if Bob’s information is used in any way which is not allowed by the contract, the Identity Oracle PAYS Bob a penalty: cash money.

When Bob wants to get a service from some giant, impersonal corporation (say “GiCorp”) whose business depends in some way on Bob’s identity, Bob refers GiCorp to the Identity Oracle; GiCorp then goes to the Identity Oracle and asks a question.  The question is NOT a request for Bob’s personal information in any form whatsoever (for example, the question is NOT “What is Bob’s birthdate”). And the Identity Oracle’s response is NOT a “minimal disclosure token” (that is, a token containing Bob’s personal information, but only as much personal information as is absolutely necessary for GiCorp to make a decision about whether to extend the service to Bob – for example a token saying “Bob is over 18”).

Instead, GiCorp’s request looks like this:

“I am allowed to extend service to Bob only if he is above the legal age for this service in the jurisdiction in which he lives.  Am I allowed to extend service to Bob?”

And the Identity Oracle’s response looks like this:

“Yes.”

The Identity Oracle, in normal operation, acts as a trusted agent for the user and does not disclose any personal information whatsoever; it just answers questions based on GiCorp’s stated policies (that is, it distributes only metadata about its users – not the underlying data). 

The Identity Oracle charges GiCorp and other relying-party customers money for its services.  The asset on the basis of which the Identity Oracle is able to charge money is its database of personal information.  Because personal information is its only business asset, the Identity Oracle guards personal information very carefully.

Because disclosing personal information to relying-party customers like GiCorp would be giving away its only asset for free, it strongly resists disclosing personal information to its relying-party customers.  In the rare cases in which relying parties need to receive actual personal data (not just metadata) to do their jobs, the Identity Oracle requires its relying-party customers to sign a legally binding contract stating what they are and are not allowed to do with the information.  This contract contains indemnity clauses – if GiCorp signs the contract and then misuses or improperly discloses the personal information it receives from the Identity Oracle about Bob, the contract requires GiCorp to pay a large amount of cash money to the Identity Oracle, which then turns around and reimburses Bob for his loss.

This system provides Bob with much stronger protection than he receives under national privacy laws, which generally do not provide monetary damages for breaches of privacy.  Contract law, however, can provide any penalty the parties (the Identity Oracle and its relying party customers like GiCorp) agree on.  In order to obtain good liability terms for Bob, the Identity Oracle needs to have a valuable asset, to which GiCorp strongly desires access.  This asset is the big database of personal data, belonging to the Identity Oracle, which enables GiCorp to do its business. And allows the Identity Oracle to charge for its services.

The Identity Oracle provides valuable services (privacy protection and transaction enablement) to Bob, but it also provides valuable services to GiCorp and other relying-party customers.  These services are liability limitation (because GiCorp no longer has to be exposed to private data which creates regulatory liability and protection costs for GiCorp) and transaction enablement (because GiCorp can now rely on the Identity Oracle as a trusted agent when making decisions about what services to extend to whom, and it may be able to get the Identity Oracle to assume liability for transactions which fail because the Oracle gave bad advice).

As long as we keep talking about “claims transformers” (which are computers) instead of “identity providers” and “identity oracles” (which are businesses) we are going to continue to build products nobody uses.  It’s not an accident that there are no commercial consumer identity providers today – no one is paying any attention to how such an entity would make money, and until investors know how they’re going to get paid, nobody is going to go into the Identity business.

The Identity Oracle is a business model for a service which provides consumer identities in a way which simultaneously protects individuals’ privacy and generates revenue for the business investor.  A claims transformer (which is a particular type of server) could be used to carry the “yes” and “no” tokens which the Identity Oracle transmits to its relying-party customers – but many other technologies could carry these “yeses” and “nos” too.  The Identity Metasystem technologies will be successful in the long term if and only if they enable successful business models – and the first step in this enablement is to stop pretending that building the technology is all that’s necessary to build the business.

You can see my original definition of the Identity Oracle here.

Limited Liability Persona in the New York Times

Blogger: Bob Blakley

Yesterday Denise Caruso took up the LLP torch in a New York Times technology section article entitled “Securing Very Important Data: Your Own”.  The article nailed the definition of the LLP, quoting Mike Neuenschwander thus:

To this end, Mr. Neuenschwander and his colleagues have floated the intriguing concept of the L.L.P.: the Limited Liability Persona. This persona would be a legally recognized virtual person in which users could “invest” the financial or identity resources of their choosing. Once their individual personas are created, consumers would be able to use them as their legal “alter ego,” even in financial transactions. “My L.L.P. would have its own mailing address, its own tax ID number, and that’s the information I’d give when I’m online,” Mr. Neuenschwander said.

Melissa Lafsky, the Times’ Freakonomics blogger, has added Denise Caruso’s article to her “FREAK-est” links list under the title “Identity data: the newest hot commodity for businesses”.   

To go beyond self-congratulation for a moment, we’d like to call your attention to another quote in the Times’ article, because Denise Caruso has made a very important point.  She quotes Drummond Reed, who says “The myth is that companies have to know all this information about you in order to do business with you ... [b]ut from a liability perspective, the less I know about my customers the better.”  Drummond might as well be reciting the headlines himself here: it was just last Thursday that the National Retail Federation issued an open letter to the credit card industry asking them to stop putting retailers on the horns of a dilemma by requiring them to store personal data, but then turning around and penalizing them when the stored data is stolen.

LLPs can help protect individuals by giving them identities which contain only a limited amount of personal information.  But they can’t help protect relying parties like retailers who collect, store, and (to some degree) protect personal information.  What’s needed is a whole system of legal constructs and new entities geared toward reducing identity and privacy risk for all parties.  The LLP is part of this equation.  Other parts of the equation are Identity Oracles (which allow relying parties to reduce transaction risk without collecting identity information; we wrote about them here) and a Relational Continuity Sockets Layer (which allows multiple parties to bring only the information and resources which are actually required for a transaction into a controlled environment which is fair and safe for all parties; we wrote about the RCSL here). If you’ve read the Times article and you want to go into more depth, you can see our original LLP coverage here, and we’ll be writing and speaking more about LLPs, Identity Oracles, and the RCSL during the coming months.

Freakonomics of OpenID

Blogger: Mike Neuenschwander

Melissa Lafsky, editor of freakonomics.com, recently posted on the debate, mystery, and hype surrounding OpenID. Refreshingly, she’s not buying in to any side of the debate; she simply wants to know whether OpenID can do anything useful, namely aid in the war on identity theft. Bob Blakely posed the question in a more general sense when he asked proponents of the technology “what is OpenID for?”

As Melissa points out, there’s plenty of debate over the technical merits and business models for OpenID. For those of you that want to dive in to the minutia of it all, I recommend starting with this post from Stefan Brands and this response from David Recordon. And never one to miss an opportunity to market my own musings, I highly recommend checking out my posts here and here.

But technical issues aside, I think it’s more important for people to understand a few concepts about what OpenID actually is, since it’s not immediately obvious. For one thing, although the name is catchy, OpenID isn’t an ID. Also, it’s not necessarily a single sign-on (SSO) protocol. OpenID is a protocol for “proving” control of an Internet address. The idea is that you log into something you control on the Internet; then using OpenID you can provide evidence to others that you have a verified relationship with the thing you logged into. The following example should clarify how this works:

OpenID-Inspired Bridge Buying

• Imagine your telephone rings and you answer “hello, who’s this?”

• A voice on the other end says “I own a bridge and I would like to sell you that bridge”;

• You say “Interesting. But who are you?”

• The caller responds “I’m the bridge owner; I’m going to pass you to someone who will verify that I own the bridge.”

• You hear some Muzak and a couple of weird clicking noises; you notice the Caller ID on your phone says “ACME bridge verification.” Then another voice answers the phone and you say “who is this?”

• You hear a voice that says, “I’m the Acme bridge ownership verification service; the guy you just talked to in fact owns that bridge. Thank you for your time.”

So the question is, under what context would you take such a deal? If you knew the caller also owned the ACME bridge owner verification service you would justifiably be suspicious. But if you already had a good relationship with the verification service, it might be a pretty good thing.

Currently, OpenID doesn’t include a mechanism for setting up a suitable context for most purposes (bridge buying or otherwise). Sure, we can invent one. But remember that really smart people have worked on trust problems for years. Things get much trickier once you start adding trust; in fact the protocol starts to look a lot like the also-rans that preceded OpenID.

What is OpenID for?

Blogger: Bob Blakley

There’s been a bit of a dust-up over OpenID recently in the blogosphere.  First Eugene and Vlad Tsyrklevitch published a paper at BlackHat 2007 outlining a bunch of weaknesses in OpenID.  Then Stefan Brands amplified the critique in a long blog post.  David Recordon fired back in a post of his own, in which he expresses confidence that OpenID 2.0 will fix all of OpenID’s problems.  I have less confidence than David, but I’ll leave that topic for later.  What I’d like to do first is talk about getting the horse before the cart.

What I’d really like to see, as a security guy, is a problem statement and a risk analysis.  Specifically, before we start arguing about whether OpenID 2.0 is the answer, I’d like to know the following things about the question:

1. What are the assets to be protected?

What do OpenID’s designers intend it to be used to protect?  Blog comment lists?  Blog entries?  Persistent consumer accounts on commercial servers?  Persistent employee accounts on corporate servers?

2. What are the services to be offered?

What services do OpenID’s designers intend it to offer?  Authentication of users as the legitimate possessors of OpenID URLs?  Linkage of OpenID URLs to user accounts on web-facing systems?  Linkage of OpenID URLs to user attribute information (e.g. Information Cards)?

3. What quality of protection is claimed for these services?

Is the OpenID protocol intended to protect against phishing?  Is it intended to protect against man-in-the-middle attacks?  Is it intended to protect against attempts by one OpenID party to induce another party to execute malicious code?  Is it intended to protect against session-splicing or session hijacking?  Is it intended to protect against active or passive wiretapping?

4. What is the threat model?

What threats is OpenID designed to protect against?  Accidental failures at a participating party?  Malicious behavior by users?  Malicious behavior by relying parties?  Malicious behavior by OpenID providers?  Wiretappers?  Hackers attempting to penetrate a relying party?  Hackers attempting to penetrate a provider?  Hackers attempting to penetrate a client system?  Cryptanalysts?

5. What is the trust model?

Who trusts whom to do what?  Does the user trust the OpenID provider to actually check his password?  Does the provider trust the relying party not to send maliciously constructed OpenID URL strings?  Does the relying party trust the provider not to reissue OpenID URLs to different parties at different times?  Does the relying party trust any particular OpenID provider to issue OpenID URL strings in a particular part of the namespace (e.g. “.gov”?) 

All the arguments about OpenID are entertaining, but the claims and counterclaims are very difficult to evaluate in the absence of a coherent problem statement which includes answers to questions like these.  The OpenID 2.0 Specification signally fails to address these issues; in this sense it’s a solution looking for a problem.

John Clippinger’s “A Crowd of One”: Required Reading for Catalyst 2007

Blogger: Mike Neuenschwander

I just finished John Clippinger’s book, “A Crowd of One: The Future of Individual Identity”. It’s an eloquently written, ambitious, and timely work relating social theory to digital identity. John masterfully draws on intellectual insights from a wide range of disciplines (including social science, political science, evolutionary biology, neuroscience, and history) to weave a narrative that’s accessible to a general audience. The message is simple: highly evolved trust frameworks are wired into the biology of all living things; so why do we persist in reinventing primitive (aka authoritarian) strategies for cooperation?

John argues that it’s mostly our collective lack of appreciation for natural trust mechanisms—even though we’re all familiar with them from everyday experience. Signals of health, wealth, and competence are extant in human society, but are usually exchanged subconsciously. John points to the Enlightenment as the era of emergent self-awareness that established many of our existing presumptions on the nature of identity. Now, with recent advancements in the fields of evolutionary biology and neuroscience, science is beginning to unravel the relation between self-awareness and social-awareness. John is among the writers constructing a new narrative on trust and cooperation based on this scientific evidence.

In my view, all identity architects should demonstrate substantial familiarity with the subject matter of this book before attempting to practice their trade. Which makes me wonder why John’s collaborators in the “identity gang” haven’t yet reviewed his book? My guess: they’re so focused on validating the user-centric model that it’s tremendously inconvenient right now to absorb the implications of “A Crowd of One.” Still, it lends new meaning to the book’s title that John is the solitary “voice in the wilderness” among the identity gang-sters.

But on this blog, John has plenty of company. Our posts on the laws of relation (symmetry, risk, and projection), the Limited Liability Persona (LLP), OpenID, and the Real ID bill (to name a few) are founded in the same science John borrows from in “A Crowd of One.” And as it turns out (entirely coincidental by the way), we’re spending all morning in the IdPS track at Catalyst discussing the issues this book addresses. We’ll even propose an architecture for moving forward with social trust online. So I’m calling “A Crowd of One: The Future of Individual Identity” required reading for Catalyst 2007. At 200 pages, you’ll have time to get through it before June 29th (and at only $12 to your door, you don’t have to worry about budget either).

Here are a few excerpts to get you started:

The problem statement: “The Net is moving from an open world of reciprocity and trust to a progressively enclosed, fearful, punitive, and monitored world of legal and economic sanctions to enforce the interests of influential oligopolies.” (pg. 182)

The problem with proposed solutions: “Impersonal formal and economic sanctions can actually undermine people’s natural inclination toward altruism and cooperation…. A more realistic path to global security is to avoid reliance on coercion and control, and sanctions and rebukes, and instead to establish those conditions under which fairness and transparency can evolve through mankind’s innate propensity for trust and cooperation.” (pg. 178)

The squishy nature of identity: “There is no single, unique, irreducible ‘identity’…” (pg. 156). I couldn’t agree more; I said something similar in my post on “Identity’s Inconvenient Truth.”

The closer: “In one sense having a negative identity [which we at Burton call an LLP] is like having a persistent but anonymous identity online; it is never disclosed in full, it reveals just enough of itself to enter into a relationship, and only it knows or experiences all its potential layers [see our “Relational Association Theorem”]. By having a persistent, anonymous identity, it is possible to authenticate parts of your identity so as to have trusted relationships without disclosing the full identity.”  (pg. 155) John goes on to say, “given the importance of negative identity in the biological world, it should arguably be extended to the digital world, become the ‘default’ for online identity.” (pg. 156)

See you at Catalyst!

Braying About Sun’s OpenID Support

When I read the first few lines of Sun’s press release announcement support of OpenID, I almost quit reading because it seemed un-newsworthy. And for you PR folks writing press releases, here’s the kind of stuff that triggers my “so what” response: “Through its new initiative, Sun is exploring what changes and practices are needed to make OpenID applicable to a broader spectrum of business and IT challenges.” Alert the media!

But Sun’s use of OpenID as an outward-facing registry of their workforce is an interesting move. Few businesses will trust just any old OpenID provider; rather, businesses will likely accept only OpenIDs (if any) from a provider on a whitelist. By tying a corporate identity to an OpenID, the relying party can improve the assurance of the issuer and make inferences however they may.

OK, still not huge news, but Sun’s initiative has incited the right kind of dialogue among OpenID enthusiasts. Tim Bray blogged on Sun’s forthcoming OpenID provider, which reinvigorated the identity gang mailing list. I’m convinced that the actual solution won’t be nearly as rosy as Tim portrays it. I’m not sure, for example, just how confident you can be that someone holding one of these OpenID’s is really a Sun employee (or just a contractor or former executive). But in my view, Sun’s pushing OpenID in the right direction.

In fact, I’d like to see these ideas taken much further. The Diffie-Hellman qualities of OpenID can be put to much better use than the SSO use cases so often cited. It’s as if the OpenID community serendipitously stumbled onto something that is of great value and has yet to realize it. I alluded to this in a previous post. Although  the name “OpenID” is catchy, it’d be better if we didn’t think of OpenID’s as IDs; and it’d be better not to think of the URIs associated with OpenIDs as usernames. And it would be great if people could have a dozen or so of these things at their disposal.

I recently published a report at Burton Group called, “In Search of the Internet Identity System: Contrasting the Federation Approaches of SAML, WS-Trust, and OpenID,” in which I proposed an alternative use of OpenID. Here’s an excerpt:

OpenID Is for Showoffs

Although its proponents tout SSO as the most important feature of OpenID, the standard can be put to better use. The proofs in OpenID allow for a certain kind of interaction that is of great value on the Internet. Roughly, OpenID enables a person to demonstrate control over a given web property to a stranger (who understands OpenID). It’s a web version of showing someone you own a car by hitting the “unlock” button on your key fob. Although this might seem a high-tech form of showing off, it can also be used in reputation systems. For example, a user may demonstrate control over a dozen popular websites to gain access to an exclusive site. The user may also demonstrate ownership of a particular reputation (on eBay, for example).

OpenID not only demonstrates a relationship, but to a degree, projects the status of a relationship, because the demonstration is dynamic (not based on historical certification). Once a user can demonstrate control over a resource (such as reputation), the user can then offer it as collateral in forming a new relationship. Accordingly, in the hands of astute architects, OpenID may be used to reduce risk in relationships. (For more information, see the post “Law of Relational Risk” on the Burton Group Identity and Privacy Strategies blog.)

In short, OpenID may be a convenient, scalable way to project high quality signals to perfect strangers. (For background on the topic of signaling, have a look at the work of Judith Donath). Using OpenID in this way may also satisfy the need for multi-factor identity that I pointed out in my post on the law of relational risk:

… single sign-on (SSO) efforts are often misguided. In the interest of promoting relational continuity, the more authenticated connections the better—particularly if the user can parlay these authentications into improved reputation. Recognition of participants based on multiple channels of connectivity would be the method for improving identity assurance rather than on a single login event.

To me, these are important elements for creating functional online relations and societies. At Catalyst, we’ll be proposing other pieces of a technical architecture to support relational and social processes important to social trust. So if you have any thoughts on the subject, please drop a comment on this post!

[posted by Mike Neuenschwander]

The Law of Relational Projection

Previous posts on laws of relation describe the dynamics of parties within a relation. But how do discrete relations combine to form complex structures, such as cultures and societies? In this post, I propose the Law of Relational Projection—a postulate on how relations relate to each other. For relations to inter-relate, there must be some notion of a boundary between relations and a theory for how loosely connected relations can coordinate activities.

The Law or Relational Projection
The law of relational projection distinguishes between parties directly involved in a relation from parties with only informational interest—let’s call the latter “observers” for now. Inter-relational dynamics are primarily based on informational projection, by externalizing information about the state, nature, longevity, and outcome of the relation. So the law of relational projection is this:

Any party with more than an informational interest in a relationship is a participant in the relationship.

Why does this distinction between observers and participants matter? Is the role of the observer so different from the roles of participants? After all, observers can influence the relation they’re observing, too—so why not treat them as the same class as the participants? The answer is that observers and participants present vastly different risks to the relation. The law of relational risk states that participants lose their contribution to a relation if the other parties don’t respond in kind. But this dynamic doesn’t hold true for observers. Because relations can exist with only loose dependencies on observers, the costs of observation are low and don’t require observers to ante up or participants to match relational contributions. But note that the law of relational projection requires that, to be an observer, a party must maintain only informational interest in the proceedings; conversely, at the moment parties interact with other participants they transition from an observer role to a participant role.

To draw a cryptic analogy to atomic theory, relational mechanics involve a kind of “strong force” (which governs the behavior of particles in very close proximity to one another, such as within the nucleus of an atom) whereas inter-relational bodies, such as observers, are influenced by something analogous to the electromagnetic force (which applies to particles outside the grasp of the strong force). For completeness sake, perhaps the gravitational force is something on a macro scale—such as how societies interact—but that’s beyond the scope of this post. Relations, like elements, therefore have a way to influence each other and to combine to form complex structures through projection of information.

This interplay of relations between immediate participants and observers also plays out in everyday experience. In a game between two teams in the National Basketball Association (NBA), the teams on the court are in an immediate relationship. The referees are also in that relationship, and by extension the NBA is also a direct participant in the relationship. Almost everyone else, including teams not playing in that game and the media, has only an informational interest in the relationship. These observers can cheer, cajole, and check the scores, statistics, and the outcome of the relationship—and plan accordingly—but their connection to the game is as an observer not as a participant. Of course, when a fan gets in a fight with one of the players on the court, the law of relational projection states that that person is now a direct participant—welcome or not—in the relation. In an NBA game (unlike on the Internet), barging onto the court has significant cost to the perpetrator. The person would be kicked out of the game, publicly humiliated, and possibly fined and sued. Accordingly, the NBA has found a stable equilibrium among observers and participants.

Relationships play out in a similar fashion in financial transactions. The immediate participants assume predefined roles, such as buyer, seller, and financer. The outcome of the relationship can be projected in terms of credit scores and seller ratings.

Making Child’s Play Out of Transactions
In online environments, the infrastructure for setting up and playing such games is woefully sparse outside the gaming community. But a general infrastructure that would be a valuable asset for improving trust online. The infrastructure should enable people and organizations to create a playing field, define the roles that are necessary for the relationship to function, and provide transparency to would-be-participants about the degree of symmetry among roles. And during the progression of the game and after its completion, there must be some way to project information about its status and outcome. Such an infrastructure would allow for stronger and widely diverse relationships, while allowing successful games (relational patterns) to be efficiently replicated on a grand scale.

On Participants and Interlopers
The law of relational projection qualifies a party as a participant whenever the party’s involvement is more than passive (informational). The law is objective, without regard for participants’ intentions in the relation or whether the party is even welcome. Where most people prefer to think of an evil doer, interloper, or criminal as a party outside the relationship, the law of projection states that the party is actually a participant regardless of how the other participants feel about it. In this model, then, evildoers are always insiders and play a role in the relation.

Resilient relations acknowledge the role of the evil insider and put controls in place to make attempts at exploitation costly to the perpetrator. Online systems must alert participants to the presence of new participants, for example. And entering a relationship should require some degree of cost to the perpetrator / participant; defection from the relation should be met with loss of contributions.

Projection and Federation
The law of relational projection helps clarify some confusion over federation approaches. One problem is that IT organizations usually don’t strongly type federated connections as purely informational (observer) or relational (direct participant). In so doing, they straddle a fine line between projecting the status of a relationship and attempting to control others’ resources and security infrastructure. Informational federations require almost no trust framework (such as contracts, collateral, social protocol), because the parties exchange information but provide no assurance of action. Relational federations are based on the dynamics of relational mechanics (such as relational risk and relational symmetry) and require highly structured or ceremonial interactions. Where these differences aren’t appreciated, organizations may over-engineer informational federations or create confusion by mixing styles.

Federation standards also differ in the types of federations they provide. OpenID is, I believe, at its root an informational, observational protocol. In contrast, protocols such as Liberty Alliance ID-FF, WS-Trust, WS-Federation, SAML are meant to facilitate relational interactions.

Projection and Privacy
Projecting relational information rather than personal information offers important privacy benefits, because the true identities of direct participants can be replaced by information about the relationship itself. In the example of two basketball teams playing a game, information about individuals takes second place to information about the teams and result of the game. Identification of the individual, as it were, fades into the background; what matters is the outcome of the game. Yes, the NBA tracks personal statistics and rewards players for various accomplishments. But those statistics are projections of another relationship (the players’ relationship to the NBA) and are designed to reward good citizenship among the players. And of course the NBA doesn’t generally post personal information such as their players’ personal phone numbers and social security numbers in the course of reporting on a game.

Similarly, individuals and organizations can play “games” with predetermined roles, rules, and playing fields without committing much personal information to the relationship or its informational projection.

The Relational Association Theorem
At the heart of every identity federation scheme to date is the notion of an identity provider (IdP) that generates assertions about a party. Some of the “federati” have prognosticated on the emergence of third-party identity brokers that enable identity transactions for individuals and businesses. But in practice, a generic third-party IdP has proven difficult to sustain. Bob Blakely called into question the business model of such an idea in a previous post.

The law of relational projection provides further tools for evaluating the effectiveness of an identification broker. If a broker does more than “gossip” (that is, simply exchange information about data subjects), the law says the broker is a party to the relation and not just an observer. But it’s unreasonable for a single broker to be a participant in all of an individual’s (or an organization’s) relations. This line of reasoning leads to a theorem on aggregating identifications, which is:

It is impossible to manage all of a party’s relational associations (identities) externally from the party

Passport didn’t fail for lack of trust in the Microsoft brand as a credential broker. Identity brokers fail when they are automatically pulled into relations in which they are unwelcome. The best a third-party IdP can hope for is enabling relations for individuals within a functional domain. This theorem therefore leads me to believe that technologies like Idemix (now at Project Higgins) and Credentica’s U-Prove are critical to the success of wide-scale federation. Though today these technologies aren’t available in consumer products, they could enable users to aggregate their relational artifacts while verifiably maintaining the integrity of claims they didn’t create.

[posted by Mike Neuenschwander]

Follow up on Relational Continuity Sockets Layer

In my post Relational Risk I promised to flesh out an idea that I provisionally dubbed "relational continuity sockets layer" (RCSL - [our-sizzle]). In the meantime, Mark Wahl already posted on this idea. As it turns out, Mark's been thinking along similar lines for some time; and since I agree with everything he says, I'll just quote his ideas on this topic:

This RCSL abstraction has several promising benefits for use in identity relationships.

• It could provide a standard and potentially portable container to hold the state of relationship as it changes over time.

Examples of this kind of state which could be referenced from this relationship might be a eBay reputation, or a transaction history. In addition, it could enable the user to view where their identities are in a workflow process.

• It could provide the means for each party to have access to theunderlying data from which the party would be able to perform a consistency check.

For example, a bank may keep track of the date and source IP address of each successful login. Other than to perform some basic checks that the requests are coming from a country that's appropriate for the user's transaction pattern, the bank may not wish or even be able to perform any further checks on whether the IP address is appropriate. While the end user may not wish to see this information displayed to them directly as they maynot know their IP address history, theoretically the end user's computing systems could coordinate amongst themselves, determine whether this IP address history matches the addresses known by these systems, these end-user-focused systems could use this data to determine if there has been a compromise.

• It could provide a means of controlling the visibility of relationship state.

At a minimum, the ability to address the relationship as an entity separate from the participants could allow for selective disclosure of relationship information without needing to disclose who is in this relationship.

• It could provide a referencable underlying data set on which a reputation system could be built.

Some reputation systems may be able to leverage the knowledge that if A and B have had a relationship over n transactions, they each may be able to make a better assessment about each other than parties which has had fewer transactions with A or B.

• It could provide a template for common operations among many kinds of identity relationships.

For example, just as "logout" is a typical operation for many kinds of identity transactions, "end relationship" could be an operation for an identity relationship.

• It could enable multi-party relationships to be better managed by the participants.

The majority of existing identity protocols describe pairwise relationships between two parties, but may not be able to incorporate theinteractions of other parties.

[posted by Mike Neuenschwander]