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.

Sound Byte

Aldo Castañeda interviewed me yesterday for his new series “The Story of Digital Identity::AudioArchives”. You can check it out here. I don’t think I ramble TOO much.

horse and car

I had the opportunity to spend some time at the N-TEN conference in DC this week. It was very interesting getting immersed in the world of the people that we want to adopt the stuff we are working on.  I was amazed at the ‘state-of-the-art’ that was being presented; they have a long way to go. My analogy for the day was:

They are all talking about how to better tether their horses to their carts. I tried to tell them about cars… They wanted to know how you tether a horse to a car.

The experts that were speaking were introducing the concepts of Web Services and Messaging (Pub/Sub).  I was trying to tell them that those are the OLD answers to their problems. There needs to be a real paradigm shift. It’s going to take some time, and a lot of work. The glimmer of hope; there were a few people there that really got it. Together with those few people I think we can move this stuff forward by leading by example.

Do you respect me?

As a follow on to the previous post; an interesting thing happens as the ecology evolves. When a vendor chooses to accept a given level of DSA (Data Sharing Agreement) they can (they don’t have to!!) register the fact with IDC(Identity Commons). This would enable them to get informed if that DSA was changed. It would also enable IDC to, with the vendors permission, publish a registry of vendors, or service providers, that accept that level of DSA. I could therefore choose my service provider, for any service, by searching the list of providers that are going to give me the highest level of control over my data. I think that’s cool!

Do you trust me?

I have talked a lot about Link Contracts lately, so why stop now. As I have said, Link Contracts are composed of several, signed, parts. Some of the parts are network enforceable and some are not. The non-network enforceable bits are meant to be enforced in some social system of accountability. These non-network enforceable bits are what I refer to as the ‘Terms and Conditions’ of the data sharing. The bit that says “You may not sell my data. You may not use my data for any purpose other than the original purpose of this agreement”, that kind of stuff. The problem with these terms and conditions is, they aren’t meant to be network enforceable or, therefore, machine understandable.

So if we don’t do this right this is what happens:

I address an email to you with your i-name. My email client asks your authority for your current email address. Your authority returns a response that says; you can have that info if you agree to these terms and conditions. My client is meant to sign these terms and conditions and return them to your authority in order to get the data I require. SO, the problem is; I don’t want to read some terms and conditions every time I do anything that involves someone else’s data. You know I’m not going to read it anyway, but I don’t even want to have to do that extra click. I mean, who knows what’s in those terms and conditions? What’s to stop you from adding some line 20 pages down that says “By signing this agreement you agree to pay me $500”. If this is how it worked, the Dataweb would be broken before it even started.

So… what do we do?

Rather than us all writing and using our own DSA (Data Sharing Agreements; terms and conditions) we will use ones provided by ‘trusted third parties’. I can read IDC (Identity Commons) Standard DSA #5 once and setup a preference that I am always willing to accept data under those terms. So in future when I ask for your email, you will say “under IDC DSA #5 (version 1.3)” my email client will simply sign the contract and send it back.

Now, the reality is, I’m probably not even going to read the IDC DSAs but that’s the point of having it provided by an organization that is ALL about trust. I know that if IDC publishes this DSA under their name… it must be ok. Ultimately there may be other organizations that provide DSAs that we can all trust, or at least use; Visa, HIPAA, SEC, etc…

For now we need to bootstrap this ecosystem. I have worked with Owen of IDC to outline three basic DSAs that can get us started;-

1. Basic – This one will put some simple constraints on the consumer of the data to ‘respect’ the owner’s privacy. This is the first real step toward giving the individual some control over their virtual self. It will include:

• No selling my data
• No giving my data away
• Only use my data in the context in which this agreement was forged
• Upon request or discontinuation of this agreement you will anonymize or remove my data, remove all PII (Personally Identifying Information) and any contact channel information (address info). I call for anonymization as an option as companies must have the ability to execute their operational reporting and auditing.

2. Wild West – This is for the organization that wants to take advantage of the higher quality data source that the Dataweb provides, but cannot, for technical, business or other reasons, conform to the restrictions of the Basic DSA. Accepting this agreement would be no different from filling out a registration form at a service today, just easier for all concerned.

3. Full Empowerment – This agreement is for the truly forward thinking organization. Under this agreement the requester of the data offers reciprocation. They say they will give you a copy of your transaction records in exchange for having access to your data. In practice this would mean that I give netflicks access to my contact info and they will, automatically, programmatically, give me a copy of the list of movies I have rented ( and how much I spent, and how long I kept them and all that good stuff). When the contract ends, I still have a copy of that information that I can take with me to my new movie rental provider.
I characterize option 1 as individuals having privacy statements instead of organizations. Option 2 as, status quo and option 3 as the next step in the evolution toward a fully empowered consumer.

Ultimately, I believe, option 3 evolves to a point where vendors simply use our repositories as the place that they keep the data about us. By giving us that level of control, and trust, and respect; why would we go to another vendor?

Please let me know if you think we need another DSA, or that I am totally off base!!

Under Contract

A key component of XDI is the Link Contract. The Link Contract is a digitally signed document that specifies the details of the data sharing agreement between the owner and the consumer of a set of data.  There is various network enforced aspects to the contract but there are also social aspects of the contract. Lets break it down a bit.

If you look up Contract in the dictionary you get something like:

An agreement between two or more parties, especially one that is written and is subject to a system of accountability.

In most cases the system of accountability is the legal system. While Link Contracts could be written to be legally binding, we are still a long way from digital signatures being broadly accepted, especially automated ones. It is my belief that we are going to be much better served grounding our accountability in a reputation system. A mechanism by which quantifiable feedback is routinely provided when transactions end (or fail to end). The reputation system will have to be subtle and flexible. If I say something bad about you that might have implications on you, me, your community and my community. If I go around bad mouthing people all the time people need to have the queues to stop listening to me. Or, am I the people’s advocate who goes around outing bad guys, so people assign a good reputation to my negative opinions… ah, so much to work out :-)

identitainment

Have you seen the ACLU Pizza movie? It’s funny. However, it paints a picture of how the world might be if ‘we’ (all the people I am working with) fail. As a counter point I wrote this story; how things might be if we succeed. It’s just a bit of fun.

spam-a-lot

Well, it happened. I started getting comment spam. I'm going to turn off the comments and just use my i-name and contact page. That's life.

Do you know Dick?

So, I finally got around to watching the movie that Dick Hardt made of his OSCON presentation. It’s very cool. I agree with almost every word he says. Of course, the devil is in the details. My opinion of the relative merits of the various protocols and standards that he mentions, I will save for another day, but I do want to disabuse you, the reader of this post, of one incorrect statement that Dick makes in his presentation;

XDI and XRI, have a very simple and open (OASIS based) APIs that include no specific transport binding specification. However, the current implementations (Java, .net and I believe, python) are all SOAP bound for a matter of convenience (and as a matter of practicality for the uses for which these efforts have been implemented). So, to state that they don’t “do web services’ is just plain wrong. (Other implementations that are bound to http and tcp will be coming soon for your personal identity service, but that’s for another post)

So, if you do know Dick….. please let him know. ( of course, I may have misunderstood what he was saying, in which case let me know).

Digital Birth Control

It is an oft asked question; “how do we keep the bad guys out?” Out of our pristine identity meta-system that is.

One of the answers that concern me is that the ‘point of friction’ should be when acquiring a name. Before a community gives you a name, they should check if you are a good guy. If you prove to be a bad guy then it’s the provider of the name that must take action to fix the situation. I think this is a bad solution. I think that the same friction that will keep the bad guys out will also keep the good guys out, I think there would be privacy issues and I think that this would put an undue and unreasonable burden on the providers of names. Name providers can’t be running background checks and arbitration boards to adjudicate accusations of malfeasance.

So, how do we ‘keep them out’? We don’t. We just don’t transact with them, neither socially or financially. It’s all about reputation.

I have never stated a law before, and I’m sure someone has stated this before, but here we go, =andy’s first law:

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

I expect people that I interact with to have, and to expose, some history. That exposure only need be as great as the value of the transaction that they want to engage in with me. If they want to send me a message, show me that you have a good messaging reputation. If you want to sell me something, I don’t care if you spam or not, show me that you have delivered goods, in good condition, in the past. If you haven’t sold anything in the past, show me that you have a good messaging reputation and a good blog comment reputation and show me a third party asserted mailing address and… good enough, I’ll buy it.

So the bad guy comes along and he’s going to stand out like a sore thumb because he can’t show any history. I am obviously going transact with him with suspicion and care.

But, I hear you cry, how does a newbie gain respect in this virtual society? Well, there is special services setup for just that eventuality. Places, like Opinity, that will validate your email address with a human test, or enable you to expose your Ebay reputation to another context ( and trust that it is really your Ebay reputation). These trusted purveyors of reputation will give you, not only the ability to bootstrap your reputation, but a place to build it and manage it’s exposure.

And finally, it doesn’t all have to be good. I would accept a message from someone that has interacted with 50 people but had bad reports from 2 of them long before I would accept a message from someone that presents no history. Real people have good days and bad days, they make mistakes, they go out on a limb. Real people should have rich complex histories and reputations. The bad guys will not, they will either have no reputation or it will be flat and weird because they found a way to hack some part of the system to boost one aspect of their reputation.

It is vital that we have a rich, distributed, network of reputation that works in many different ways because, coming back to =andy’s first law, the investment in gaming ALL of the systems would be so great that it wouldn’t be worth blowing it on a any single transaction that is worth less than the initial investment anyway.

New DataWeb Service

This is not exactly an XDI post but it touches on XDI and is all about identity and data sharing so I don’t feel too bad. One of the reasons I have been so quiet over the last couple of months is because I have been building business plans and strategies rather than thinking about core XDI architecture. The result of all this planning is DataTao.

DataTao (a working name) is going to be an interoperable data hub for user controlled data. DataTao is primarily about programmatic access to an individual’s data and only has as much UI as is needed to richly support its base functionality. I often use an analogy of Windows Explorer or Mac Finder; Apps that run on your computer depend on an underlying persistence layer (the file system) to work. The new generation of ICA (Identity Centric Architecture) based web apps will be dependant on the DataWeb for their underlying data persistence. DataTao will be the first DataWeb Explorer.

So why do I call it an ‘interoperable’ data hub? That’s because DataTao is designed to act as a bridge between many of the current identity protocols. While DataTao will provide storage for people that don’t have their data stored and available from elsewhere, its main purpose is to consume and forward data from its authoritative source(s). DataTao publishes your information, based on your permission settings, to all of the supported protocols. If you have a dataTao account you will be able to go to an XDI enabled site and have it establish a link contract for transparent data sharing. You will be able to go to a SXIP Network enabled Membersite and dataTao will act as your Homesite. You can visit a LID or OpenID enabled site and DataTao will provide the relevant interfaces for authentication.

If you have a LID, a SXIP Homesite, a public LDAP server or an XDI data service and you get a DataTao account you will be able to get the advantages of having all of them while still maintaining your data only at the one place that you already did. If you already have multiple places that your identity is published you can use DataTao to consolidate your identity into one virtual profile and manage who sees what from a single point.

It is my opinion that DataTao is a necessary and required next step in the evolution of the DataWeb. While DataTao by itself is NOT a compelling application it is a needed piece of infrastructure. It will hopefully encourage and enable people to build internet 2.0 applications and maximize the leverage of those already built. SXIP membersites will suddenly have a market not just of people with SXIP homesites but anyone with a LID or an i-name or an open LDAP service.

In order to drive adoption DataTao will provide some Apps that use the DataWeb for persistence in conjunction with the DataTao launch. These apps have not been finalized yet but will likely include Exchange and Mac Mail integration (Self updating address books) as well as a rich interface for person to person profile information sharing (i-share).

Despite the fact that the true value of DataTao is in the infrastructure piece that it puts in place, it is likely that all of the marketing that you see will be about the apps or the widgets that we deploy. But you, the tech savvy reader will know what it’s really about.

DataTao will be a free service that will have its public launch early in 2006.

For the true geeks amongst you...

Here is some thoughts on how Error Handling can be improved using XRIs and XDI in distributed systems.

XDI Data Modeling Take II

Here is a link to the same document (both .doc and .pdf forms). I have already largely changed my thinking on section 6 but I stand behind the rest though, still.

View from the top

Click here for an image of XDI provided by Paul Trevithick that is just SUPER coool, THANKS Paul!!

XDI Data Modeling

Here is a doc that represents months of thought about how dictionaries and applications might be built in XDI.

Graph-o-manic

As Drummond Reed, Paul Trevithik and I continue to delve into the XDI Universal Schema and it's graph representation my understanding of it, and my belief in it, continue to grow.

I understand Kim’s assertion of his 7 laws. He’s not legislating; “You must do this”. He’s not playing god, he’s proposing that he has uncovered some basic truths about the state of things. I am starting to feel the same way about the power of the XDI Universal Schema. I believe that Drummond (it really is his brain child) has lead us into a VERY powerful, new way of representing data.

The Universal Schema juxtaposes, or superimposes, 4 hierarchical graphs on top of each other, one at right angles to the others. Every resource in the dataweb can be accessed through the constrained 3 level syntax (Auth, Type and Instance) axis or through it’s ‘natural’ schema (or meta-schema) representation on the second axis (once you have put it in the context of the authority that can permission that ‘document’).

Let’s Take a look…



In this image I see 4 distinct hierarchies; the first runs across the Authority level. This is a registry and the vertical graph would have been equally valid rooted in any of these Authorities.

The second hierarchy runs across the Type level. This graph describes a VERY simple schema; it shows the component parts of a US mailing address.
The third graph runs across the Instance level of the graph this MUST describe graphs that are valid instances of the schemas represented at the Type level.

Finally, the fourth graph is the one that runs from top to bottom. This is the graph that associates authorities with the schemas and the instances of those schemas. It provides XRI addressing directly to any point in that schema or schema instance. This enables very efficient traversal of the data as you can navigate the abstract schema until you NEED to drop down to the instance level to get the specific instances that you need.

Notably the first 3 graphs are totally un-constrained. At the Authority level this means that our registry is totally extensible. At the Type level this means that ANYTHING that can be represented in XML (which is a hierarchical metaphor) can be represented at the Type level (if you can describe it in RDF or XML Schema or RelaxNG you can put it here). At the Instance level it simply means that you can represent instances of the schemas from the type level.

Now, the final mind blower for the night…

I was talking to Jamie Lewis and I said “any object can be described as a list of name value pairs”… eyes, blue, hair, brown, street address, …, etc… in a simple world that might be true but even as I said it I knew that it was overly simplistic. But now looking at the XDI Universal Schema in the terms I just described I see what the vertical graph ‘also’ represents; it’s the association of, not ‘name,value’ pairs with an object, (an Authority) but ‘Schema, Instance’ pairs with an object. And That, in my mind, seems to be a mighty powerful way to describe an object.

Put a LID on it.

NetMesh, ID Commons and ooTao jointly published a press release today anouncing the integration of i-names and LID through an XDI service.

To see, and play with, the demo that includes the LID integration go to the ooTao XDI Demo page.

Next... We will add a SXIP integration so we can demonstrate XDI i-name enabling and integrating LID and SXIP together. One i-name, one profile; use it as a LID or a SXIP homesite. (At least, that's the plan)

Face to Face

Images of the XDI TC member that attended the Face to Face in New Orleans... with a twist.

If you want to view this silly bit of fun you will need to install the plugin (link at the bottom of the page). If you know the people on the XDI TC it's probably worth it. I have seen this working on IE and Firefox on PC and Mac. I have heard that some people have had trouble with Netscape 7.0 on the PC.

http://peru.ootao.com/docs/xditc/XDI_TC.htm

Another chance...

My BlogMentor Kaliya has made me see the error of my ways. Here is the Intoduction to XDI in a format that is open and linkable... Now I want feedback on the content as well as the distribution format :-)