Friday, May 30, 2008

A Wag for the TAG

The interference of the W3C in the XRI vote at OASIS is unprecedented and disturbing. The W3C has rebuffed all efforts by the XRI TC to engage in any form of dialog about the technical merits of XRI. Despite repeated attempts by the XRI community to show the use cases that XRI is solving the TAG make vague statements like 'you can do everything in URL'... This statement is clearly and patentley meaningless without specifics....

It all well and good that SOME of the stuff that XRI does CAN be done in URI/URL but without specifying a STANDARD way of doing stuff the ability to do it is next to useless!!

There are parts of XRI that you simply CAN NOT DO with URI.... Like resolve an abstract identifier (urn).

There are hundreds of millions of users with services that use the xri specs (OpenID being the best known). The ONLY reason W3C cares about this is they think they CONTROL the internet and here is a spec that OBVIOUSLY solves wide reaching problems and it's not theirs.

In my mind this is as subversive as the Net Neutrality issue... W3C is cynically trying to stifle innovation for pure 'not invented here' reasons.

rant rave grr huff.... This pisses me off... PLEASE.... if you voted NO on the xri vote spend some time on the phone with me and talk with me about why you voted no and why I think you are wrong! Before undermining LOTS of hard work by LOTS of smart people at least understand the technology.

Wednesday, May 21, 2008

Let every eye negotiate for itself

Paul's response to my latest post put me in mind of Claudio in Act 2 scene 1 of Much Ado About Nothing...

Let every eye negotiate for itself
And trust no agent; for beauty is a witch
Against whose charms faith melteth in blood.
Paul is correct that I must qualify my posts more carefully.

There is as yet no agreement on all of the mechanisms of claim and assertion exchange. While the ability to differentiate a self asserted claim and an issuer asserted claim in a managed infoCard is useful in some cases it is not the ONLY answer to the problem. The fact that I have a widely deployed client provider that wants to consume claims in this way is a pure Business Detail that should not impact the purity of the technical discussion.

As Paul points out a Better way to do this would be for us to deliver an 'Email' claim with enough metadata about how the claim was acquired and how it was or wasn't vetted that the RP could make its own decision as to the veracity of the claim. I probably should have implemented it this way even though the RP was asking for something else.

Post Script

That was meant to be wry bitting humor... not mean... does it sound too mean?

Tuesday, May 20, 2008

The Claim Game

ooTao's Managed InfoCards now include a verified email claim and verified i-name claim.

If you want to consume these claims you will need to ask for:
I have blogged previously about how you might validate an iname claim

We are publishing our own 'white list' of claims providers that we consider 'trustworthy' in order to 'trust' the verified email claim. More on that soon.

If you want to start consuming our verified claims at your RP just let us know and we can do some testing together.

Saturday, May 17, 2008

Did Info Card help?

I like InfoCards... I like the idea that I will not have to remember the usernames and passwords. I am confident the MS will work out how to solve the 'portability issue'... BUT.... I just went through InfoCard hell!! I'm still shaking as the adrenaline that built up is trying to drain from my body... this can't be good for me. Let me tell you what happened.

After a long week at IIW and Data Sharing Summit and OpenSocial Spec meeting, I am finally checking in on the blogosphere at 5:30 am on Saturday morning and I see this really cool thread on Kim's blog. It's all about the qualities of Distributed Data Management that I have been talking about for years, but, it's Kim and Dave and Clayton Donley, who is the Senior Director of Development for Oracle Identity Management.... I get so excited, I have to add a comment and tell them about ooTao's work in the space (although Kim is meant to know :-) ).

And that's when the problems started...

I can use digitalMe on my mac to log into our RPs and even to Mike's blog, but it will not work on Kims blog. I spent a while restarting things; browsers, selectors, OSs, this is just habit as a long-time Windows user, nothing helped.

So I upgraded and downgraded the versions of DigitalMe and tried to log in to no availe. For any who care the error I get is: 'unknown option privfile... blah blah'.

Then I remembered, my old XP PC that is now the kids, should still have InfoCard selector installed so I put aside my mac and power up the old PC. First attempt to login at Kims blog tells me that 'InfoCard isn't installed' which seems strange, since I remember installing it. So I poke around and find that I DO have it installed but I don't have any cards defined... I add a card... I return to Kims blog... I click and YES, the selector invokes and I can see the card and I select it... and I am asked if I want to be redirected to an error page... which isn't exactly what I want but, what the hell, I've come this far.

The error page informs me that the temporal offset of the requesting token is larger than the requisit 300S. Those aren't the exact words but believe me the error message did not say... 'The Client and Server Clocks don't match'... So I unpacked the message and realized that I needed to change the time on the PC so that it matched Kims server within 5 minutes.. I just had to hope that Kims clock was close to right. So I changed the time a few times and yes.... finally... I logged into Kims blog and left a comment.

Unfortunately by the time I got there, my enthusiasm and excitement for the topic had been morphed in to frustrated anxiety so my comment is no-where near the 'tone' I originally intended. There should probably be some joke I can make here about 'Claims Transformations' as this STS certainly transformed my claims... BUT... I have now been trying to write, writing, writing about this damn post for 3 hours...

I think it was worth it though if I can finally get these guys to understand what it is we have built.

Tuesday, May 06, 2008

iPages a go-go

I was reading Kevin Marks post that looks at Brad Templeton's post about the interplay between data portability and behavior portability. As I commented on Kevin's blog I agree with them 80% but think that Brad's proposal has one flaw.

I disagree that it is practical or desirable to create a centralized data store. I think there are a couple of issues with that model. The first is the security implications of having everything in one place... that scares me. The second issue is, I think key, to the success of this model...

The 'place that I have access to all my data and can therefore run my OpenSocial apps', lets for the sake of ease call it my 'iPage' can and should provide me all of the user interactions I need to manage my virtually aggregated data. Specialized 'Widget Providers' should give me widgets that give me data domain specific user interactions through which I can specify my favorite music, food likes and dislikes, rental car preferences, etc... BUT there is a world of data that is collected about me, and should be FOR me, buy people and systems that are much better qualified to know and assert those things than I am... Like medical information, qualifications, financial instruments, transactional histories of all kinds, what was done to my car at its last service, etc...

This is why we have BUILT a system that has a data abstraction (xdi/higgins) behind the OpenSocial container rather than a database. The abstraction can provide (bi-directional data access) data to widgets that is stored locally or data that is stored remotely (or a mix of both), the widget neither knows nor cares.

Using OPEN distributed identity standards (OpenID, oAuth, ID-WSF, InfoCards, FOAF, XFN) and OPEN data abstraction standards (XDI, Higgins,XML,RDF)... This can be done today... we've done it... This truly enables VRM in a broad and flexible way.