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:
Beginning of next week
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.
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!!
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.