Thursday, January 25, 2007

I wrote this missive in an email thread about using CardSpace with i-names I thought I should share it with you too:

IMHO the use cases that i-names support are a super set of the use cases that cardSpace supports... All of the digital identity usecases where someone else's wants to refer to me they need to use a globally unique identifier to identify me. Now I could keep giving people (services) my email but I'd much rather give my i-name. When a party has my i-name they can bootstrap ANY functionality that I provide. This is very different from cardSpace.

CardSpace is REALLY good at doing authentication (on Vista clients). Here's where I'm going to go out on that limb... I-names aren't bound to any specific authentication mechanism, they can be used in SAML they can be used in OpenID, but they can be used in any number of other schemes as well. A managed i-card with a signed assertion from the i-broker that this i-name has been validated as belonging to this card holder seems to me to be just as valid a mechanism to authenticate an i-name as any.

Use case:

I go to Evite (the i-name enabled Evite) and say I want to invite =joe to my party. NOTE: CardSpace has no mechanism for me to identify 'Joe'; I HAVE to know a global identifier for him. Now Evite can look up =Joe's invitation SEP (could be his contact service, an email or other). Later =Joe wants to look at his invitation at Evite so he goes to the site and logs in with the convenence of the cardSpace paradigm. I don't think that using cardSpace authentication diminishes the value of the i-name in doing what it is good at doing.

So once cardSpace/higgins is broadly available we are going to need to define an attribute type so that an RP can ask for an i-name (or should it ask for an xri?). We are also going to have to provide the list of parties that should be trusted to assert i-name ownership (self asserted 'this is my i-name' should NOT be trusted); presumably could publish that list.

So in summary... I think that people NEED i-names; they are just too useful in too many usecases. I DONT think that authentication mechanism is a good place to focus on the value of i-names, I would go as far as to say that this is one of the biggest mistakes that we in the i-name community have made. Once you have authenticated that the principle is the valid user of i-name that's where the value starts, not stops. So authenticate by whatever means the RP wants, and then look at all the cool services that can happen.

Wednesday, January 17, 2007


What is XDiggins? It’s what you get when you smash XDI and Higgins together at high speed. Last week Drummond Reed, Paul Trevithick and myself had the opportunity to get together and explore this synergy in some detail with a specific client use cases to explore.

The use cases that we were looking at were those presented by the establishment of ‘Wiser Commons’. The Wiser Commons is a group of nonprofit organizations who are willing to share information in order that all of them can provide better services and be more effective in their missions. The commons, lead by NCI and Jon Ramer of Intera, provided the excuse that Drummond, Paul and myself have been looking for, for years, to come together to try to ‘rationalize’ our various standards into a working solution.

Paul, Drummond and I spent 3 days together. The first day we spent with a small group of ‘techies’ from the commons discussing requirements. The second day we secluded ourselves and talked tech and the third day we presented a proposed initial architectural approach. Over the next couple of weeks I will dive into the details of the approach we are proposing, here on my blog, for all to see. Meanwhile, there is one main thing that is worth mentioning that I think is very exciting…. We did it!

The 3 of us finally achieved a level of understanding of each others work that we were able to build a single proposal that all three of us could agree to, endorse and understand. The single most startling thing that I came to understand is how similar our work is. Many of the ‘problems’ that we were having in understanding how Higgins and XDI should work together were not because they were incompatible but rather because they are so similar. The 2 efforts are deeply, profoundly, validatingly similar in their underlying models. There are certainly nuances that differentiate the 2 bodies of work but now that we are able to appreciate the big picture similarities we simply have plug the best-of-both together to get a working solution that transcends both and removes the necessity to choose between them.

Watch this space for upcoming details…