Identity

From Entuura

OLD INFO. After learning more about OpenID, it may be part of the story, but is not the full story. This section needs to be revisited from scratch.

We will want to identify individual users someday, not just nodes. We are running our own PKI to identify the nodes. Should we use it to identify the people? (Answer: No. See below.)

In fact, the current implementation of the blog carries the name of the post author, but it is a completely unauthenticated piece of data. The only thing that a node receiving it knows for sure is that it originated on the node that signed the blog posting.

The right answer for Identity is OpenID. Even though our system is designed for offline, or mostly offline environments, it will be tied into the global Internet. And betting against better access to the Internet is a sucker bet. So need to design for the future. That means that whatever we use today to identify users should work in the public Internet. We went 15 years, or more, with no workable Internet identity scheme. MS Passport and Liberty Alliance were the last to fail. But with the rise of user contributed content, the stakes are too high to fail again. And it seems like they have learned their lessons and made it possible for anyone to be a provider (goodbye verisign, nice knowing you!) and to unify multiple IDs from multiple providers into a single ID (search for YADIS).

So, we will go with OpenID. I still need to learn more about it, but one really attractive thing about it is that you can be your own provider. So it is 99% certain any central server for an Entuura system will be a provider for all the Identities in it's network (i.e. for the union of all identities in all the communities it operates). We will have to solve a tricky problem to decentralize authentication, since we want both the central server to be able to be a provider for the ID in the public Internet, and for the node to be a provider for IDs in the offline context.

Global or Local?

Clearly, identities need to work throughout a Community. The use case demanding this is easy to articulate: I should be able to open up my laptop at a coordination meeting, his ECHO's Entuura node via wireless, login with my ID I created on my MSF node and have it work. If I post on the community blog, even though the post originates at ECHO, it should be attributed to me. And in fact, I should be able to edit it when it arrives at my home node (hopefully before I get home from the meeting, if we are in a satellite connected context).

A nod to the nice people at the well: You Own Your Own Words. The blog posting will leave with a signature from ECHO that says, "I promise that this guy proved he's got a valid OpenID and here it is." (But, what happens when I get home, edit the post, and the update arrives at a third node. It needs to somehow work out that post X, which was last signed by ECHO, is now arriving for update signed by MSF... and that that action should be allowed. Umm, hard.)

But the humanitarian woodstock moves on, and it's a dead-on certainty that someone who worked in one context (one Entuura community) will later work in another context (with a different Entuura community). And that makes me wonder if we

I think the solution to this will be YADIS, but I have to read and think some more. We can auto-generate and host the YADIS files to connect IDs across communities, but if the user spans two communities which span two central servers, that's a problem... because for your public id, which domain name will they use? Entuura.org, or OtherCentralServer.org?