The quality of data is not strained

“The quality of data is not strained; It droppeth as the gentle rain from heaven Upon the place beneath. It is twice blessed- It blesseth him that gives, and him that takes.”– A bastardization of William Shakespeare.

I am often faced with the question; “Why don’t we just do this with our Web Services?” Generally when I’m asked that question it’s in relation to what I call Dataweb technologies. When I’m asked it in other contexts it makes even less sense.

There are many answers to this question and different ones tend to resonate with different people. One of the main qualities of the Dataweb that I strive for is the richness of interaction that one gets when accessing data, through ANSII SQL that is in a well designed schema. This is a quality that you only grock if you have spent time writing database reports or very data intensive apps. Those of us that have been there know that extracting information from a well written schema is a joy. In fact, given a little imagination and a reporting tool you can learn stuff from a well built data set that you didn’t know you knew. This phenomenon fueled a whole industry starting back in the mid 80’s when ODBC first hit our radar. We still build big data warehouses that we troll and derive new information and stats from, but only inside closed systems.

Back in the early 80’s all the data was locked up on the mainframes and we started writing PC apps that needed to access that data. Each time we wrote an app, we wrote a data driver to access the data we needed off the mainframe. There was very little reusability and no appreciation of the ‘value of data’. Then, along came ODBC, the first widely adopted manifestation of ANSII SQL, and everything changed. Now, you built an ODBC driver that could access your mainframe and went to town, you never had to write another custom driver again. This was the inflection point where we discovered that using a fluid, abstract, data access mechanism let us learn new things from the data we had already collected. The difference between those custom data drivers and the ODBC data access paradigm was that the drivers tightly bound the purpose of the access of the data to the mechanism for accessing it, while ODBC (SQL) provided an abstract mechanism that didn’t care what the data was or how it was going to be used. These qualities were inherent in the way we thought about those custom data drivers; when we designed and built them we built interface definitions getUser(), getInvoice(), etc… We used method invocation to access the data we needed. SQL provided us a way to query any schema in any way and ‘try new stuff’ without having to re-program our data access layer.

Given my example of getUser() and getInvoice(), what happened if I wanted to find out if there was any correlation between geographic region and annual total purchases… I was basically stuck waiting for the mainframe guys. With SQL in place I could slice and dice my 2 table schema (users and invoices) any way I wanted. I could look for patterns and play to my hearts content… but it wasn’t really play, it was the birth of business intelligence. Now that I could work out the profile of my best customers, I could target other people with that profile to become my new customers. How’s that as an unexpected outcome from a higher level of data access abstraction?

The way that we conventionally use Web Services today is not just akin to those old data drivers, it is the same thing. We know this, it’s inherent in the names of the protocols that we use, XML RPC, Remote Procedure Calls; method invocation. getUser() and getInvoice() would be very reasonable methods to see defined in a WSDL.

Now sometimes you need the quality of RPC, you don’t want people to be trolling through you data and deriving all sorts of stuff, you want to keep them on a tight leash, so use conventional Web Services. I call this integration pattern ‘application integration’, not data integration.

The protocols that support the Dataweb, XRI, Higgins, XDI, SAML, OpenID, WS-*, etc… provide mechanisms to access a distributed network of data with the same richness as if you were accessing a single data source via SQL, but with more control. Imagine doing a database join between two tables, now imagine doing a join between two heterogeneous, distributed systems… wouldn’t it be cool.

The qualities of an abstract data layer are; a well defined query language that can be used to access a well defined abstract data model that in turn returns a persistence-schema agnostic data representation. These qualities are shared by SQL, XDI and Higgins.

When contemplating a data abstraction for a distributed data network there are some other things that we have to add to the mix; trust frameworks, finer grain security, social and legal agreements, network optimization, fault tolerance, to name but a few… And that is what I spend a lot of my time thinking about.

So I hope that this describes somewhat why Dataweb technology is different from conventional Web Services implementations, although they run on the exact same infrastructure.

It is interesting to note, and I may be way off line here so if you know better please correct me, from what I’ve seen: SalesForce agrees with me. What I mean by that is that their new generation Web Services are some of the most abstract interfaces you are likely to see in a system that derives so much of its value from its programmatic interfaces. (Along with Kintera who we are working with). The only downside with the SalesForce approach is that it’s proprietary, which is a shame, when there are open standards that, appear, on the face of it, to satisfy their requirements. (SalesForce, I’d love to hear from you if you want to talk about this.)

Higgins IdAS and XDI

The more I look at the Higgins IdAS the more I recognize that it is the part of the puzzle in the Higgins world that maps fairly closely to what I call the XDI Engine. They both present abstract data interfaces that are meant to be put in front of legacy persistence. I have been telling Paul for a while that I think that IdAS is going to need indexing capability to be really useful. I realized, not long ago, that we need to replace the ooTao specific ‘plugin’ engine with an IdAS implementation. I am seeing more and more that once xdi takes into account the Higgins IdAS use cases and Higgins IdAS consumes the xdi use cases as sub sets of the complete ‘dataweb’ use cases that an xdi engine and an IdAS implementation are going to end up being pretty much identical. I watch the Higgins-dev list and learn and hope to contribute where I can.

In that light I am going to start putting more Higgins musings on this blog as well as xdi stuff.

Here is a thought provoked by a current discussion on the Higgins list:

The way that we are dealing with systemic and semantic mapping in xdi is by introducing an xri abstraction into the mix... attribute types are xris, generally in the '+' namespace, known as the 'dictionary space', like +email, or +first.name. Unlike the '=' and '@' namespaces the '+' namespace is not a rooted space, but I'll get back to that.

So in xdi land, any attribute name is resolvable in dictionary space to a dictionary entry, a dictionary entry may include a bunch of different stuff, including:

• synonyms (both semantic (street and rue) and systemic(phone_number and phoneNumber))
• schematic constraints (+address = must link to 1 or 2 streets, 1 city, 1 state and 1 zip... I KNOW that +address is a bad example because it's not a global construct)
• validations (validation lists, real expressions (masks), executable validation scripts (different implementations in different languages))
• UI implementations (for building rich UIs for arbitrary attribute types; +eye.color may provide a color picker that limits color choices to natural human color range as dcom, .class, xul, etc...)
  

So, in xdi land, as we build indexes of the various contexts (one of the primary 'qualities' of xdi is indexing the contexts it knows about so that you don't have to go trolling 200 contexts to find the attribute that you need about a given subject); rather than indexing the attribute type '+email' we index the canonicallized i-number that the i-name resolves to.. +!3215.2154.1254.

example:

xri://=andy/+email, 'andy's email address', points to a specific attribute in a specific context but what we persist in the index is xri://=andy/+!3215.2154.1254

Now when anyone wants to do a get against the index they can search for xri://=andy/+email or xri://=andy/+e_mail or xri://=andy/+Email or xri://=andy/+doar.hashmali (transliteration from Hebrew) and get back the desired record because the type is always resolved back to the i-number. On set operations the xdi engine checks the validations and schema constraints of the type before parsing the operation back into the 'context provider' to persist the new data.

I said that the '+' space is not rooted, so how does it resolve? Well, just like with English, you can look up a word in whatever dictionary you want, you might prefer Webster’s, personally I like the Oxford Standard. This quality lends itself to supporting a seamless continuum of global, community and personal dictionaries so you can be as precise or as vague with any given term as you like. A person can specify the intended dictionary for a given type: @ootao*(+email) would be ootao’s definition of +email and IS resolvable in the global @ namespace.

The early dictionary implementations that we are working with use a folksonomy approach to building the communal knowledge… anyone can edit the dictionary. So if your system uses a field name for an attribute that hasn’t been mapped yet, you just add it to the dictionary. Once one person has added the ldap schema and one person has added the vcard schema the world now knows that +cn, is the same as +fn and they are both instances of +!3211.5485.3656, which is also +full_name, +person.name, etc…

I’m not saying we have all of the problems solved. Off the top of my head I don’t know how we would express the transformation between givenName, sn and cn… But I could propose a few suggestions if anyone was interested.

More on CardSpace and XRI

I like CardSpace. I finally got it installed on my XP machine at home and have used it to log into Kims Blog. Installing it wasn’t as easy as I would have liked, it was a big download, a long install and then I had to get ‘special’ tech support in order to get it to work (by special I mean I had to call someone I know over at MS, in that department to help me). Now it turned out that it was an ‘obvious’ problem but on-line help was not easy to find and the error messages were not helpful. All I had to do was install IE7… another big download and install… BUT… that’s the price we pay for security :-)

I have seen CardSpace demos for years now, and have pondered the paradigm shift in the user login experience and have always liked it… Now that I’ve tried it I like it even more!! As a user experience this makes a lot of sense to me… and with some xri and xdi integration this thing could really rock :-0

There are 3 places that I would like to see xri and xdi integration into the CardSpace world. These opinions are based on a deep knowledge of xri and xdi and a pitiful understanding of anything beyond the basic mechanisms of WS-* that make up the CardSpace. I will try to explain the use cases and the properties of the interactions that I am looking for as I talk about these integration points and if there is alternate (better?) ways of solving the same problems I would love to hear about it.

Integration 1: Portability
One problem I still have with CardSpace is that my cards seem to be bound to a specific machine. If I create self issued cards at home and at the office and log in to Kim’s blog from both places; how do I get recognized as the same person?

In the Higgins project HBX card selector the Card Store is not on the client machine, it is ‘in the cloud’. I think that using i-names to bootstrap authenticating me and finding my card store would make CardSpace better. I want to walk up to any machine that is CardSpace enabled, enter my i-name, authenticate (using the multi-factor mechanism of MY choice) and have trusted resolution (not spoofable like DNS resolution) find my Card Store and let me use my cards. Now, I only have to log in once using my i-name, after that I just pick cards. Because I only have to log in once I’m fine jumping through a few multi-factor hoops to make sure that the authentication is solid. That would be cool!!

Integration 2: I-Name Authentication
OpenID is great a way to authenticate an i-name… but not the only way; I really like the ease of picking a card to login. BUT just because a card says “my i-name is =andy” does NOT mean it should be trusted. This is just the same as on Kim’s blog, my card asserted my email address but I still had to go through an email validation…you can’t trust self asserted claims!

So who should be able to make claims about i-name ownership… whoever the i-name owner wants…who the relying party is willing to trust… and here’s how that can work:

EZIBroker (an ooTao business) is about to start offering managed cards with i-name assertions. We hope that through our XDI.org accreditation and our general reputation we will become a trusted provider of assertions. But that isn’t enough… The owner of the i-name needs to ‘show’ that they have selected EZIBroker as their token service. They can do that by adding a Service Block of type “managed card’ to their i-name record (XRDS). So, a relying party, on receipt of an assertion that the ‘bearer’ of this card is the rightful user of the i-name ‘=andy’ should do 2 validation checks… 1) They should check that the asserting party is who they say they are and that they are trusted by the RP to make the claim and 2) They should perform xri resolution to check that the XRDS for that i-name does, in deed, designate that Token Service as the claims provider for that i-name (the theory being that only the i-name ‘holder’ can change the XRDS). XRI resolution should be performed by the RP anyway to persist the i-number as well as, or in stead of, the i-name.

Integration 3: Pointers as Data
This is close to the heart of my real passion… distributed data management. When an RP asks for an email address I want to be able to return either an email address OR a pointer to an email address. Today if an RP asked for an email address and got back an xri (or uri) I would expect it to be upset… and that’s why we need integration. There are use cases where you want to push the data to the RP, but there also use cases where having the RP be able to pull data on demand can be very useful (like current temp in your location so we know how much beer to deliver). In XDI land the response to any request can be one of 2 things… data or a pointer to data. In card space land the response can only be data (as I understand it). If the response is a pointer to data then the RP has to know how to dereference the pointer.. of course you want the protocols that support the pointer to protect privacy, have fine grained security, have link contracts, have pull and push cache syncornization… be xdi :-)

So at a REALY high level those are the 3 points of integration that I am interested in seeing between XRI, XDI and CardSpace. (The 4^th one that I have talked about on the TC calls is really an integration with the Higgins IdAS service not CardSpace so that will go in a different post).

I will dig into these more as time lets me… I’ll let you know when you can get i-name cards at EZIBroker i-brokers.

I wrote this missive in an email thread about using CardSpace with i-names I thought I should share it with you too:

IMHO the use cases that i-names support are a super set of the use cases that cardSpace supports... All of the digital identity usecases where someone else's wants to refer to me they need to use a globally unique identifier to identify me. Now I could keep giving people (services) my email but I'd much rather give my i-name. When a party has my i-name they can bootstrap ANY functionality that I provide. This is very different from cardSpace.

CardSpace is REALLY good at doing authentication (on Vista clients). Here's where I'm going to go out on that limb... I-names aren't bound to any specific authentication mechanism, they can be used in SAML they can be used in OpenID, but they can be used in any number of other schemes as well. A managed i-card with a signed assertion from the i-broker that this i-name has been validated as belonging to this card holder seems to me to be just as valid a mechanism to authenticate an i-name as any.

Use case:

I go to Evite (the i-name enabled Evite) and say I want to invite =joe to my party. NOTE: CardSpace has no mechanism for me to identify 'Joe'; I HAVE to know a global identifier for him. Now Evite can look up =Joe's invitation SEP (could be his contact service, an email or other). Later =Joe wants to look at his invitation at Evite so he goes to the site and logs in with the convenence of the cardSpace paradigm. I don't think that using cardSpace authentication diminishes the value of the i-name in doing what it is good at doing.

So once cardSpace/higgins is broadly available we are going to need to define an attribute type so that an RP can ask for an i-name (or should it ask for an xri?). We are also going to have to provide the list of parties that should be trusted to assert i-name ownership (self asserted 'this is my i-name' should NOT be trusted); presumably XDI.org could publish that list.

So in summary... I think that people NEED i-names; they are just too useful in too many usecases. I DONT think that authentication mechanism is a good place to focus on the value of i-names, I would go as far as to say that this is one of the biggest mistakes that we in the i-name community have made. Once you have authenticated that the principle is the valid user of i-name that's where the value starts, not stops. So authenticate by whatever means the RP wants, and then look at all the cool services that can happen.

XDiggins

What is XDiggins? It’s what you get when you smash XDI and Higgins together at high speed. Last week Drummond Reed, Paul Trevithick and myself had the opportunity to get together and explore this synergy in some detail with a specific client use cases to explore.

The use cases that we were looking at were those presented by the establishment of ‘Wiser Commons’. The Wiser Commons is a group of nonprofit organizations who are willing to share information in order that all of them can provide better services and be more effective in their missions. The commons, lead by NCI and Jon Ramer of Intera, provided the excuse that Drummond, Paul and myself have been looking for, for years, to come together to try to ‘rationalize’ our various standards into a working solution.

Paul, Drummond and I spent 3 days together. The first day we spent with a small group of ‘techies’ from the commons discussing requirements. The second day we secluded ourselves and talked tech and the third day we presented a proposed initial architectural approach. Over the next couple of weeks I will dive into the details of the approach we are proposing, here on my blog, for all to see. Meanwhile, there is one main thing that is worth mentioning that I think is very exciting…. We did it!

The 3 of us finally achieved a level of understanding of each others work that we were able to build a single proposal that all three of us could agree to, endorse and understand. The single most startling thing that I came to understand is how similar our work is. Many of the ‘problems’ that we were having in understanding how Higgins and XDI should work together were not because they were incompatible but rather because they are so similar. The 2 efforts are deeply, profoundly, validatingly similar in their underlying models. There are certainly nuances that differentiate the 2 bodies of work but now that we are able to appreciate the big picture similarities we simply have plug the best-of-both together to get a working solution that transcends both and removes the necessity to choose between them.

Watch this space for upcoming details…

More Adoption

It’s really starting to happen, XDI nodes are starting to spring up. This press release that went out yesterday illustrates that real businesses are seeing the value of doing this stuff ‘right’.

Another node in the XDI DataWeb

The Netgroup of University of Rome Tor Vergata have brought up an instance of the open source XDI server to further their project to develop user-centric self-reconfiguring radio equipment (E2R project)

Check out these links:

G.Bartolomeo, S. Salsano, N. Blefari-Melazzi authored the paper: "Exploiting Access Control Information in User Profiles to Reconfigure User Equipment" - International Workshop on Ubiquitous Access Control (IWUAC 06), July 17, 2006 - San Jose, California, USA
The PDF
The PPT

It’s cool stuff and very exciting for me to see people using xdi to solve real-life problems.

Week at the knees

What a week!! Not enough that it was Digital ID World so ‘everyone’ was in town. In honor of Digital ID World we ran our $5 i-name promotion. The promotion got picked up by Slashdot… and we survived, with our servers intact. We were hoping to sell 100 i-name during the promotion; we sold almost 1000. Additionally, I had some great meetings and participated in some great sessions at IOS (Identity Open Space, day one of DIDW).

It’s really starting to feel like we have pushed the ball to the top of the hill and it’s about to start rolling down the other side… It’s going to pick up size and momentum and smash into the identity silos blowing them apart (or they can open their doors and let the inevitable roll through, but once those doors are open they aren’t going to be closed again).  

…And once we have distributed identity then we can manage distributed data… XDI, here we come.

Put a LID on it

Great to see Drummond and Johannes getting together jammin’ to the XDI groove. As you may remember we did an XDI/LID integration demo about a year ago with Johannes’s help.

I Want My Name Now

I have talked lots about i-names and promised value of an abstracted global unique identifier. We are slowly but surely inching our way toward realizing that value. On Monday we will hit XDI.org’s base service compliance deadline and you will see all of the current i-name registrars (I-Brokers) offering the authentication, contact and forwarding services. If you already have an i-name be sure to go to your i-broker and configure your services so that you can start to use them.

If you don’t have an i-name yet, or if you want more, this would be a great time to jump in. In celebration of the services launch and the Digital ID World conference we are running a three day promotion that lets people buy i-names for just $5. At that price I think it’s a no-brainer to buy a name just in case these things take off. If they don’t, you’re out $5, big deal. If they do take off you’ll look like a genius. How many time’s have you wished that you’d got into the .com space earlier?

Go to www.iwantmynamenow.com on Monday, Tuesday or the first half of Wednesday to get your low cost name.

You should ph-off

Just for fun I built a FireFox plug-in to help protect OpenID users from phishing and Pharming attacks. The idea for this plug-in first came from Nat Sakimura one of the xdi.org board members and I was finally launched into action when Dick Hardt said "the solution is that we need 'something' on the client" the other week at an OpenID tech workshop. Now, I don't know if this is what Dick had in mind but it should raise the bar for a would-be phisher to succeed if it's used right.... Go on, ph-off

More on OpenID

If you are in the bay area next week... or could be... check out this 3 hour workshop that will introduce what can be done and what is being done with OpenID. David Recordon, Mr OpenID, will talk about OpenID implementation; I will talk about i-names in OpenID and, if I have time, will show a quick demo I have of simple profile sharing using XDI that uses OpenID authentication.

On another note; have you heard about the $50,000 OpenID code bounty? If not, check it out.

I-Names and OpenID

How exciting, I think I qualify as the first person to ever log into an OpenID site with an i-name. While I did have the honor of doing the first tests, I want to thank Kevin, Brian and Larry from JanRain who built the server and helped me install and configure it. I also want to thank the ooTao team, Steve, Barry and Frank who did all the work to get our i-names infrastructure to the point that the OpenID integration could work. It was an amazing collaboration of a bunch of very smart and very dedicated people.

I have to say, having typed in my OpenID url to authenticate a bunch of times, using my i-name is a really cool alternative. It’s easier to type, and the display name is a lot cleaner, it feels a lot more like a label that represents _me_.

Launch approaches and I think there are going to be a lot of these really cool ‘firsts’ with i-names. In the next days, weeks and months we are going to see a proliferation of i-brokers and i-services that embrace the user-centric vision.  I’ll let you know about these as they become available.

Back to work, lots to do for the launch on Tuesday.

Link Contracts

There are all of these lawyers running around the identity space getting involved in the technology issues... here's my revenge:

I know we are going to be talking a lot at IIW and the Berkman Conference about policy and standardization of data sharing agreements so I thought I would get this thought out of my head. This document basically says that I think we need to differentiate between several different types of agreements that need to be standardized to build a robust, dynamic, trust framework in which overlapping circles of trust can evolve. When the discussion focuses on “the data sharing agreement” I am often unclear about which one is being talked about.

XDI Workshop

Yesterday ooTao hosted an XDI Workshop that dove into details of i-name single sign-on (ISSO) and talked at a higher level about XDI data sharing. The slide show is available here.  The wiki that we used to publicize the workshop can now act as a place for us to continue to explore XDI implementation issues; linked from the wiki I have also setup a yahoo group for XDI developers.

YABP – Yet Another Blog Post.

I just want to point you at the work going on at YADIS. If you are interested in XDI then you should be interested in YADIS. YADIS provides capabilities discovery that is not only compatible and interoperable with the XRI specifications but shares several dependencies.  Here is a summary of the latest YADIS F2F. For the full YADIS story go here.

GR Mapping

For you implementers out there here is an excellent article written by Steve Churchill, ooTao’s CTO, that gives a concrete example of how we executed our first successful Graph/Relational mapping implementation. This implementation utilizes the plugin architecture that our XDI Like (no spec) server supports.

I fought the law...

So, I went out on a limb and coined a law a while back:

The value of a transaction between 2 parties should never be greater than the reputational collateral exposed by either party.

While at IIW2005 I had the opportunity to chat with Allan Schiffman of CommerceNet we got to talking about reputation and so I rolled out my law… he very nicely pointed out the flaw in my thinking; My law assumes that, like in the real world, people can only be in one place at a time, doing one thing at a time. My law breaks down if a user can build a $10K reputation and then enter into fraudulent $5K transactions with 100 people at the same time such that the latency of the reputation system is greater than the time needed to complete the transaction. It’s a great point.

I think this drives a change to my law but doesn’t completely invalidate it. There are 2 ways that I need to mentally adjust my thinking to accommodate this new reality;

1. Think Small. Reputation systems that are designed to operate within the size limits of workable human groups will be much more effective. For social accountability to be meaningful you need social collateral not just reputational collateral.


2. Add latency to reputational transactions that mirrors the latency of the reputational feedback mechanism. For example; when I agree to buy a laptop from you for $500 bucks you put your ‘seller’s reputation’ on the line, I get the right to effect your seller’s reputation by 100 points. That 100 points should be put ‘on-hold’ the moment that we agree to consummate the transaction and should only be freed once the transaction is completed to the satisfaction of the buyer. Another would-be buyer might now see the seller’s reputation as 400, with 100 on hold. This would reduce the latency of the system to almost 0 and limit ability for a seller to over-use their reputation. I think. This is just one way to negate the latency effect, I can think of others, it’s basically just having awareness of this problem and implementing _some_ solution to mitigate or remove the risk.

So maybe I can simply change the law to:

The value of a transaction between 2 parties should never be greater than the available reputational collateral exposed by either party taking into account the latency of the reputational feedback mechanism.

I think I need to strengthen that; I’ll work on it.

Easy is Hard

I got this quote at the bottom of an email from Luke Kanies of reductivelabs; I love it.

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are 'obviously' no deficiencies and the other way is to make it so complicated that there are no 'obvious' deficiencies.
-- C.A.R. Hoare, Turing Lecture "The Emperor's Old Clothes" CACM
February 1981, pp. 75-83.

It makes me wonder; I have long loved the quote:

I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity.
- Oliver Wendell Holmes

And have long strived for, and I believe periodically found, the simplicity on the other side of complexity. But, did I, or is it that if you stare at the same complexity long enough it starts to LOOK simple to you. When people tell me some of my work is too complex, I have to believe them, not discount their opinion because it LOOKS simple to me.

let them go, and if they love you...

I talked about this in the interview but for my own sanity need to get it down on paper. One of the arguments against giving users control of their data and control of their relationships is that businesses and organizations would ‘lose control’. There is a fear that all of an organizations members (customers) would cut them off and they would be left high and dry with no affiliations left.

First let me tell you what I mean by ‘giving the user control’:

I am using a very simple use case; rather than the organization keeping my name and my email address, they just keep my i-name. Whenever they want to contact me they look up my email address, it doesn’t matter how many times I change it, as long as I don’t revoke their permission to see it, they can get my current email. I do have the right, and the ability, to revoke permission (as I should).

Here is why I think the fear is fallacious:

The ADMA (American Direct Marketing Association) says that mailing address data ages, becomes bad, at a rate of 15% a year. I couldn’t find statistics on email address aging but you have to assume that it ages faster than mailing addresses given how much easier it is to change email address than move house. So lets assume that email data ages at a rate of 20% ( and I think that is low). So, today, an organization can expect to lose 20% a year of their relationships simply due to the inefficiencies of the infrastructure. By adopting an identity centric architecture (ICA) an organization can eliminate this attrition completely. So what about the people that ‘opt-out’; well, they weren’t interested in your stuff anyway, clearly. If over 20% per year of people that have established relationships with you jump ship; you have a deeper problem that needs to be addressed. So, the net is, you have more people, more relationships, and they are known to be of a higher quality.

I think this is profound; by respecting your constituents, and empowering them, you end up with better relationships with more people. So you save above the line because you have a more efficient information system and you make more below the line because you have more, better qualified, relationships.