I-names can support SSO through resolution to an XRD that indicates the authentication service. The authentication service will be the user’s i-broker and will ask for a password. Supposing that the user recognizes the “trust cues” from the i-broker, she will enter the password. The user will be returned to the SP with an authenticated session. The flow actually uses redirects through the browser. The SP and the AuthN never talk directly to each other. The weak link in SSO is the password page and possible spoofing.

There are libraries available for doing i-name SSO now (SPIT) that work in PHP, Java, Perl, Python, and Ruby. BooksWeLike is an example of a site that has implemented i-name based SSO. I went there, registered by putting my i-name and email into their registration page and now can log into their site using my i-name, authenticating though 2idi (my i-broker). I dislike the multiple pages (with buttons that say things like “click here to complete the login process”) but it’s pretty cool to see it work. Here’s my BooksWeLike page. Notice my i-name in the URL.

Moving on to XDI

While XRI is an extension of the URI concept, providing a richer set of mappings than DNS will support, XDI is the XRI Data Interchange. XDI is a set of specifications that are dependent on XRI and discuss how to share data resources that are identified using XRIs.

Why publish data from your systems? Internal and external system integration is the obvious answer. But, you can do something else at the same time: empowering you members so that you can serve them better. Say what? Here’s an example:

Today people give money online to non-profits. non-profits remember that they do this so they can ask them for more later. But when many people give money to lots of organizations, it becomes difficult, especially for smaller organizations, to manage their donors. So small non-profits sell their data to aggregators and then by data back to get a better handle on who’s giving what.

What happens if the donor ends up with an authoritative record of their giving? Then the individual can aggregate a profile of their own giving that far exceeds any data an aggregator can amass. The donors can also specify what they are interested in giving money to. Other data about the individual can be aggregated with the profile. This profile can be selectively exposed in the context of other transactions. Intermediaries can use this data to broker giving to organizations. This strikes me as the longtail of trust funds. There’s also a serious attention component here.

To enable this, the donor must receive an authoritative record of the transaction. By publishing this data back to the user, you serve your members better. The system must provide fine grained permissioning that let’s you control who has access to what. Roles-based permissioning simplifies the permissioning matrix. Service-based roles make permissioning doable for real people.

To do this, you should not only capture data at its source, but use data at its source as well. Data about me lives in lots of places. I don’t want to gather it up and put it all in one place. What I really want is to establish a database of pointers to where my data is. Note that this is a different problem than whether I have control over who sees that data or not.

XDI is to the distributed data web what ODBC and SQL were to datastores in databases. XDI takes an XRI as the query you get back and XDI doc (a well known, universal data structure with introspection).

XDI has field level security. Since the structure is hierarchical, the permissioning can be specified by a path. John has access to “a/b/f/1” for example. This path-based syntax allows fine-grained and course-grained syntax in the same model.

The IP for XDI is open and it has a social layer. The social layer is represented by “link contracts” that mediate data access. Link contracts can express conditions for data use. This could be used to require certain behaviors with respect to caching and other things. This seems like identity rights agreements.

XDI has low-level caching. This is independent of (or an augmentation of) transport level caching since the XRI syntax can be used to specify what are authoritative copies of the data and which are no longer valid.

XDI has low-level versioning. XRI has a specified versioning syntax. Values can be soft deleted. Old values can be kept addressable and can be auditable only.

Triggers can be built into XDI implementations. XDI is not yet enterprise ready. There needs to be more work on backup and recovery, clustering and fault tolerance.

Because of these properties (in particular the fine-grained permissioning), you can easily incorporate the “user” into a data integration by merely permissioning her system. What’s more, identity providers are found through resolution without having to integrate multiple IPs into each system.

At this point, a light bulb went off in my head and the information density of the next few minutes pegged my brain bandwidth. I’ll have to parse it out and write about it later.

In XRI, my email address would be represented by =windley/+email. Resolution would be able to turn that into my current email address or even a contact service. This allows you to put a wall between the resolution and the email address, allowing someone (perhaps the user) to turn off email resolution on a case-by-case basis. This allows user-controlled access to personally identifying information.

ooTao has a XDI Demo available online.