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