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.

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 :-)

One long over due response

Aldo asked:

Andy,Regarding:"'Typed Links' tell the XDI Engine to treat the link as special. the most common use of this is the $op* group ($get, $set, ...) that are used to link a contract to the data it permissions AND specifies, via the Link Synonym, what that permission is."I'm imaging a scenario where I've slapped a "$op*" to a piece of data that I own in order to allow another party to "$get" it. Now what happens when I would like to allow another person (from another "Authority domain") access to that same data? Does this require that I add another "$op*" link to that data (I'm thinking in terms of Contract Law (formation of a valid contract). Is there a potential problem if the data to which I allowed "X" access under a condition that "Y" doesn't get access to it? If I can just add another "$op*" how would "X" ever know that I've given "Y" access? Perhaps this is what you refer to in your presentation as a "collision"?Thanks as always for any info.

I think there's a couple of questions in here that I can answer;

The 3 questions I think I see are:

1) What is the mechanism for providing access to the same data for more than 1 person?

Once you have established a contract that provides access (a combination of set, get and delete) to a specific set of data you can connect as many instances of $link to that contract as you like. The signed copies of the contract hang off the $link instance not the $contract instance so each permissioned person has their own signed copy of the contract. You can permission all of the members of a community via a single $link instance, in this case when a member of that community actually accesses the data and signs a contract a new instance of $link is created specifically for that individual where the signed contract can be kept.

2) What is to stop the person I have given access from 'passing-on' access to others?

Rights paths always start with a segment that identifies who can use that rights path (=andy/($link)/(=aldo)) will only pass validation if the requester can provide an assertion that they are =aldo. However the same syntax the permissions community members also acts as a ‘forwarding’ permission. If @ootao* is the syntax for ‘any i-name delegated from @ooTao’ then by granting rights to @ooTao* I am giving the administrator of the @ooTao community implicit rights to provide access into my data by adding or removing members of the ooTao community. Similarly providing access to =aldo* would give =aldo access to my data and also people that aldo trusts.

3) What control does the consumer of the data have over the provider of the data?

At this point, none. As I have understood it so far there is no explicit provision at the XDI level to enforce the data provider to sign a contract. With that said, it wouldn’t be hard to model an application that required a signed signature at the application logic level. The application could even use the XDI contract negotiation mechanisms to implement the requirement.

One quick response

Aldo asked:

I do have a question however about the following: "Even though some data providers adopt standards like iCal it is unusual and unlikely that any one protocol gains ubiquitous adoption. Low level standards seem to catch on but not high level ones - SMTP, POP3, SQL, HTTP, TCP-IP. XDI pushes Secure Data Sharing down the stack and makes it a lower level function. "Do you have an stats to prove that? I'm not questioning your assertion rather I think this might be an important point for me to address in my research and any "hard data" on this would be terrific.

No I don't have any facts.. I didn't think we needed those on blogs :-) I was just expressing my personal observation. I have subsequently be pointed at this quote by Drummond:

"protocols with few options tend towards ubiquity, whilst protocols with many options tend towards obscurity."

Although I can't find an attribution for it. We will have to look at XDI through this lens before going ‘main-stream with it.

You only make a first impression once...

So, I have been working on a new 'Introduction to XDI' ppt. I put it up for review at the XDI TC yesterday and presented it to a bunch of engineers (about 15) today. I have incorporated their feedback and posted it here it is for further comment.

The P'u of XDI

What is P'u?

... I'm not even going to go there...

To me P'u is 'The Uncarved Block', 'something in its natural state'

One of the basic principles of Taoism is P'U, the Uncarved Block. The essence of
the Uncarved Block is that things in their original simplicity contain their own
natural power, power that is easily spoiled and lost when that simplicity is
changed - "The Tao of Pooh"

Owen and I were talking about the what he called the 'Liquidity of Data'. This is something that we had both experienced; I call it the ultimate ACID trip, of course I mean ACID Transactions . It's when you are interacting with well structured data and suddenly you see the beauty and power that is unlocked in the interactions between the pieces of data (I said it was an acid trip). There is a whole industry that has grown around data mining that tries to unlock that power, that energy, it is generally accepted that it is a very valuable commodity. In the olden days, when I was young, data lived in dbase files. As a young database report writer I learned to respect a well crafted data model, I learned that if you modeled the data well; reports, knowledge, flowed out. I learned that trying to get meaningful reports out of poorly structured data was less than fun. Then, people understood that they needed to share data and move data from one repository to another. Those were hard times, moving 1meg over that 14.4 modem that would keep on dropping it's connection could take hours. And, how to structure the data so that the other people could use it? It was like running up the hill to the village with your water in a hand woven basket. Then XML came to save the day, all of a sudden we had real vessels to move the precious liquid, it was a plastic cup. Then the final touches SOAP, a plastic bottle with a screw on lid. Now you could move your data from one place to another without loss, knowing that anyone could receive it and understand it. This was cool.

But something happened, that ocean of data that spawned life, that ebbed and flowed, a medium we could swim in, was diminished. People thought well if XML / SOAP is so damn useful lets start using it everywhere. We can keep our data AS SOAP. So the image I have is this; imagine the ocean and it's richness, it's untapped potential. Imagine the same quantity of liquid in bottles sealed and stacked, static and dead.

The P'u of XDI is that data in it's raw form is a powerful thing. A call to XDI is a call to liberate data everywhere, throw off your chains and be free....

That was fun :-)

Metrics For Success

Last night I was fortunate to see my friend and associate Gil Friend speak at the Commonwealth Club, it was inspiring. The topic of his speech was ‘THE STATE OF SUSTAINABILITY’, he spoke eloquently and passionately about how Big Biz can not only make a huge difference in the state of sustainability but MAKE MORE MONEY while they do it. Gil sited a couple of instances where, by changing the definition of success, companies have made more money while driving toward a greener goal:

DuPont used to manufacture and sell paint to the auto industry. The metric for success was ‘how much paint did we sell’, the more paint they could ‘push’ the better. As part of a drive to sustainability DuPont started to sell painting services to the auto industry instead of paint. Now every drop of paint wasted is money from the bottom line, the LESS paint used the better.

I think it was a Swedish shipping company that used to measure success by kg moved across km. That seems reasonable for a shipping company, the more stuff they move, the better they are performing their business, but then, they changed their metric. They made a decision to be more sustainable and changed their metric for success to $ (krona) of profit per liter of gas. More money good, less gas good. They now act as a logistics firm helping companies make sure that they have what they need, where they need it, when they need it, in the most efficient way. After all, that is what companies need, they don’t want to buy ‘shipping’ they just need their stuff in the right places.

So my point… How can I change my basic definitions of success to change my behavior? That isn’t a rhetorical question, please send answers to…

Personal Server

The current XDI Server is what I consider the start of a "Community XDI Server" it's based on the J2EE servlet framework with 'axis' providing a SOAP Web Services interface. It is designed and built to handle a large volume of data and traffic, it needs robust server grade hardware to support it. I hope that we will see a PHP (LAMP) version of XDI Server soon that may offer an easier entry point for not-for-profit and NGOs. We may even look into a C/C++ version for really high end commercial use.

This post is about the other extreme; the XDI Server that will run on your desktop, your phone, your PDA, your watch?. This server needs to be very light weight and run as a stand alone app. It will be your messaging client, your calendar, your blog reader, file storage interface, your Personal Productivity Dashboard. You will generate content of any type; document, image, movie, song and in a single action do any of these that you wish:

• Save it.
• Publish it.
• Put into a Knowledge Management System (tag it).
• Notify others that it is published.
• Back it up.
• Secure it.
• Assert ownership over it (I'm working on evaluating some newly patented watermarking technology that may have some teeth)

Because XDI is inherently distributed and interoperable this doesn't mean that we/you are building some monolithic repository that must hold all data, it simply enables a single point of reference for all that data. Your calendar data will still be kept in whatever you already use, your rich media will go to your ourMedia.org account.

You will use your person server to share your data with only the people you want to share it with and otherwise secure it. You will use your personal server to control access to you; when someone types your i-name into their cell phone, do they get your home phone, your cell phone or voice mail? You configure who, when, where and how. That works for email too and rss consumption. Maybe one day FedEx will be i-name enabled so you can have your package delivered to where you are when you are there.

XDI'm OK, You're OK

According to Amazon "I'm OK, You're OK", written by Thomas A Harris (1967);-

Synopsis: A guide to transactional analysis. In non-technical language, it
offers advice on gaining control of yourself, your relationships and your
future, no matter what has happened in the past.

I haven't got a clue what transactional analysis used to mean but now it means that someone is watching all my transactions, analyzing them then selling them for their own gain. XDI is about "gaining control of yourself, your relationships and your future, no matter what has happened in the past."

Another reason I like the I'm OK, You're OK analogy is that XDI is about interoperability; if you are using LID, LDAP, FOAF, SXIP, XRI/XDI it doesn't matter, they should all work together, they are all OK. They all have different strengths and weaknesses but should be able to work together to give us all the control we desire in our futures. This isn’t some hippy dippy idealistic dream, this is the reality of our success or failure, collaboration and competition are the driving forces that will keep us focused and innovating.

I link therfore I am.

I was asked this question via email but thought I would answer here so that you can correct me.

Aldo Castaneda the watcher and documentor of the developing identity standards wrote:

By the way I read "XDI-Universal-Graph Primer" with interest. One basic question for you:

In the notation that reads -> xri://@ooTao/(+Contact)/email*(=Andy/(+Email)/work)

Does the "*" stand for the Red Dot (Link Node)? And is a Link Node necessarily a delegated authority?

So the easy bit first, yes, the * always denotes a Link Node (which is represented either by the Red Dot or by a Green Line). It is also true to say that a Link is always a delegation of authority for a given section of the graph. But, I am finding that that description falls short of describing the richness of interactions that Links enable. At the different levels of the graph the Link represents a different thing;

At the Authority Level a Link mostly represents 'Membership' @ootao*aldo would indicate that Aldo is a member of the ootao community. @ootao*aldo*andy has Andy as part of Aldo's community in the context of ooTao.

At the Type Level Links represent Complex Types (I am going to write up a doc about XDI Dictionaries that will cover this ground) (+address*(+street)), (+address*(+city)), (+address*(+state)) and so on is a way of indicating that street, city and state are connected to make a larger type; address ( the dictionary definitions should indicate that while there may be 1 or 2 (+address*(+street)), there should only be 1 (+address*(+city)) for a given instance of +address).

At the Instance Level Links seem to be used for unstructured aggregation (aggregation not defined in the Dictionary) for example Link from the (@ootao) instance of (+biz.card) to an instance of (+email), (+phone) and (+title). From the (@natural.logic) instance of (+biz.card) I would link to a different combination of data. By not associating this at the Type level I have no constraints of the data structure.

Across all levels Links may be given synonyms that are $words (system words) these 'Typed Links' tell the XDI Engine to treat the link as special. the most common use of this is the $op* group ($get, $set, ...) that are used to link a contract to the data it permissions AND specifies, via the Link Synonym, what that permission is.

Control Freak

Drummond always loves it when I randomly decide to add another system word... well here I go again... (the title of this post is about the system words not about Drummond!!)

We have been going back and forth for a while about the behavior of the link contracts when the underlying permissions are changed. If I give you additional access to a new piece of data, should that invalidate the contract that you have already signed? What if I remove your access to piece of data?

If each change does invalidate the contract we are going to end up with a LOT of contract signing overhead. If it doesn't I might suddenly give you set rights to something and then accuse you of messing up my data... You never even knew that you had the set rights.

So we decided to support both options; If the instance of a $policy has a synonym “$RequireSignedRightsPaths” then the rights paths will be signed as part of the contract. Any changes to your permission set will therefore invalidate the contract. In the absence of this synonym you will only sign the policy itself and the permissions can change at the authorities will. This has been added to the primer.

Given that most policies should be standard and don’t actually care what the specific data that is being shared is this should work fine.

How much is too much?

James Kobielus' Blog: fyi Databases Can't Handle RFID

Can a massively distributed data architecture like the ‘Dataweb’ as we conceive of it support masses of data? I guess we’ll find out. I do know that 5 years ago the idea that I would have a 300gig drive in my $800 PC would have seemed not only unlikely but also unneeded. If that 7 million terabytes of data that Wal-Mart Stores Inc was generating each day was spread across the data repositories of the people who executed the transactions what would the spread be? I’m not being glib… these are my real first thoughts on what is clearly a huge question.

But then... It is probably true that XDI 1.0 will not solve all of the problems in the data sharing world including this 'massive' data question. But massive distribution will certainly help and it will solve a lot of other problems.

The Authorititive Voice

I want to make sure that you know that all this stuff I spout is just MY OPINION. There is no XDI Spec yet, I'm sure that others on the TC would not agree with all my opinions (that's why we have the TC process). The stuff that I put out may be TOTALLY WRONG!! I hope not, I don't think it is but it might be.

Anatomy of a Rights Path

Geek Out:

What is a "Rights Path" ? It's a booklet on Aboriginal Human Rights .

but to me it's;

The address that a single entity (individual, organization, service, bot) can use to access data that has been made available to them that is under another entities authority. A Rights Path is a cross between an 'ability' and a data query. It's a query that only one specific entity can execute.

See Rights Paths 101 doc for more.

$Public speaking

Geek Moment:
For months now I have been saying that the $public instance of the $contract provides a mechanism to permit anonymous access to your data. I was wrong...

A $public instance of $link should be the access point.. It'll be in v4 of the primer.ppt

Not what I was expecting - Take II

That's why I should stick to technology not politics; from what I'm reading Kim and MS are still playing nice. I trust Drummond's assessment that Kim’s the real thing

Options Options

As I continue to make the XDI Viewer more usable I was building in an 'Options...' page. A place you can specify som preferences about the look and feel of the app. And as one does, I started asking myself.."Where shall I persist the options this time?". I could write them to a .properties file (plaintext or XML) I could send them to the registry.... But then I thought NO.. I'll save them into my XDI profile. I have to login to use the app anyway so I might as well just pull down my options from the service when I log in. Whenever I login, I get my options, no matter where I am. I like that :-)

Not what I was expecting

I just read:
http://www.cnn.com/2005/TECH/03/29/microsoft.id.reut/index.html

It was NOT what I was expecting to hear out of MS based on all the buzz in the circles I move in. Is MS that split? can we trust them? Are they trying to 'play' us?

IMHO: They need us more than we need them. Given the choice I think people want an open, free, cross platform, secure ID platform. We have to not only make the choice available but make sure people kow they have a choice.

Coming soon to a server near you

I have actually been dying to blog more but I find that I have to work instead. Normally I can make time to do what I want to do but this week I have a deadline so I'm being good and working instead of blogging.

So I thought I would just let you know what I'm working on as it is really pretty impactfull to the world of XDI.

But first I have to 'clip' is that the right term? I just loved this link I found on Doc Searls blog:
SaveToby.com

The Schedule:
Beginning of next week

The deliverables:
An XDI service capable of:

• Validating the authentication credentials provided in an XDI request using the (almost) SAML compliant ISSO framework.
• Responding to an XDI get() request by returning an XDI document that represents the XDI graph rooted at the requested XRI.
• Respond to an XDI set() request by validating and placing the provided XDI graph segment at the specified XRI.
• Respond to an XDI setData() request by updating the contents of a terminal node.

A web based service that:

• Uses ISSO authentication.
• Provides an i-name owner the ability to create and update a simple 'personal profile' ( a couple of email addresses, phone numbers, snail mail address) that is persisted in an XDI store.
• Provides the ability to permission the data in the profile to be 'viewed' by other i-name holders, or not.

An outlook plug-in that:

• Enables an outlook user to enter an i-name into the message address bar in place of an SMTP address (without triggering bad validation messages)
• On 'send' look up the i-name recipients email address and put it into the outgoing message as the destination for the SMTP transaction.

What this is:

This is meant to be a proof of concept, sample implementation, open source project. This is not meant to be finished, production grade, products or services. This is meant to help other would-be XDI developers see the patterns used to implement thin and thick client apps on an XDI platform.

Most of all this is NOT meant to, does not try to, is no way implying that this set of services in any way helps the spam problem!! You can see the email address that the i-name resolves to in the outbox and sentbox of outlook. What this is, is a dynamic permission-based lookup so that I may end up sending the email to a different address than you because we are permissioned to see different email addresses, it is always going to send an email to the 'current' email address as the lookup is dynamic.

This is not a package that I would consider commercially viable. There will be XDI based products and services that will meaningfully address the issues of spam and general permission based communications channels... this ain't one.

I said all of that because I know I am still going to get a bunch of people telling me that my "product" sucks because it's not really secure because you can still see the email in the outbox.

Coming Soon:

Once we have this proof of concept under our belt and we have had the time to iron out the bugs that this process will uncover... THEN we will start to build some really cool stuff!!

Honor Roll:

I want to point out that half of the code that we are using was written before I even got involved with this endeavor by Fen Labalme, Victor Grey and Mike Mell; thank you.

All the new code has been written by Barry Beechinor and Steven Churchill with consultation and help from Fen and Mike (Victor is on vacation).

All I have done is pointed Barry and Steve at the work of Drummond Reed, Marc Le Matre, Dave McAlpin, Peter Davis and the others who did all the work on the TC before I showed up.

OK, I know I add some value too... but I just wanted to point out what an amazing community effort this has been and will continue to be.

First day on the blog

Tao means: "The Way" in that deep 'truth' kind of way.

XDI is;-
A new dimension in ultrasound
A leading provider of B2B solutions and web hosting service
Advanced, low noise F.E.T. technology
Some dudes blog
Distributorless Ignition System

but to me XDI is;

A standards based framework for securely sharing distributed data with the option of establishing trust through federated trust networks. (if that doesn't scare you off you're as crazy as me)

When I started looking at XDI I looked here;-
http://xrixdi.idcommons.net/
http://www.xdi.org/
http://wiki.idcommons.net
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xdi


My main mentors in this space have been:
Owen Davis
Drummond Reed
Fen Labalme

but it was Kaliya that has me thinking I might have something worth saying.

IMHO:-

XDI has the potential to change the tao of how data moves around the web. Stuff that today is considered 'application logic' will become the taken-for-granted behavior of the underlying dataweb, the new application logic will soar to new heights of functional simplicity. I get the occasional glimpse of what that might be.

I will be focusing on 3 things in this blog:
xdIdeas
products and services that I think XDI can enable or improve.
Vertical markets, industries, that I think XDI can revolutionize.
The evolution of the XDI framework from a true geek standpoint.

For example:

Prods and Svcs:
The killer app for XDI may well be 'Identity'. This is of course a suite of apps, that run on top of a network of interoperable trust networks. With the i-broker ISSO (provided by 2idi) as our initial authentication mechanism ( soon to be fully SAML 2.0 compliant) XDI will soon be enabling a plethora of controlled cross-schema rich-format data publishing services. Sharing and cross-posting your personal or community schedule will be a no-brainer (only one authoritative copy so you can change it once and it changes every where). Create a message and publish it to your blog, your web site and to a friends RESTMail inbox all in one go. Publish your Biz Card via XDI while maintaining it, and viewing/managing others, in whatever schema you happen to like (initial mappings will include; LDAP, vCard, FOAF,SXIP... let me know what I'm missing ( we will have to build the connectors on an 'as-needed' basis but the mappings will already be defined))

Industry Shake up:
I am already actively looking into 2 industries that I have a history with and a passion for; Healthcare and Environment Data Management.

In healthcare I am starting to develop ideas around how XDI can liberate the HIPAA world. Today, doctors cannot, according to HIPAA, send electronic messages to patients (except where secure messaging systems have been put in place) XDI RESTMail can easily satisfy HIPAA standards and open a world of B to C activity.

In Environmental Data Management, what does it do to the man years of resources that are wasted gathering, formatting, parsing, centralizing and reporting on emissions data when each data source can publish it's data to the dataweb (so that ONLY those people that are meant to see it can see it). You give the EPA (and any NGOs you trust) the XRIs of the data feeds off each of your smoke stacks and they can real-time monitor, cross-company benchmark and create industry standards from the relative comfort of their own cubicles.

Geek Space:
As we get closer to the release of the first XDI service, lovingly known as the "Identity Commons Prototype XDI-like Service" (in the absence of a TC spec it's about all we can do) . I am starting to turn my mind to the fun of data modeling in a new paradigm. I've done ERD and I'm a competent Object Modeler, but XDI data modeling could be totally different, or it might be exactly the same... as both !??

At first look people react to the 3 level schema (Authority, Type, Instance) and see it as a limiting constraint. As I start to dig I understand that the freedom of movement within the levels is unlimited and very powerful. I am starting to see how, within the 3 level logical schema you can model relational (1-1, 1-n, n-n) or strictly hierarchical data (object hierarchy included) . I am thinking that a simple JDO implementation will make the java XDI libraries very easy and even JDBC drivers should be well within reach. I'm not even going to attempt to explain this stuff yet but in the next couple of weeks I will start to put out XDI Data Modeling methodology guides for all to see. I'm sure that both people that read it (Drummond and Fen) will sleep very well.

So let's see if I ever blog again :-)