Sxip demonstrated federated authentication at Dreamforce (a Salesforce.com trade show) (see the article). This is a framework in which users are authenticated somewhere else and then use that information to receive authorization for a service. SAML is the international standard, while Sxip and others offer vendor technologies. Other open-source efforts include OpenID (the successor to TypeKey) and LID. (Federation itself is not particularly unusual. At last year’s Xoops Conference, for example, there was a demonstration of TypeKey integration with Xoops, and an XRI-based system was demonstrated at PlanetWorks in 2002, if I remember correctly.)

To explain in a little more detail, a typical ASP vendor provides services, not authentication. Authentication can be performed by each Identity Holder. A user then goes to obtain a service carrying an Assertion. Whether to provide a service in response to that Assertion is a decision for the Service Provider. This is Authorization. The question is who provides the Identity that undergoes the Authentication.

Have you heard the terms Theirdentity, Ourdentity, and Mydentity? They appeared in a talk by Doc Searls at Digital ID World 3 years ago.

Theirdentity is an ID that a company or other organization assigns to us on its own initiative. A customer number in a customer database is one example. Its purpose is to be used for direct marketing and the like; even though it is information about me, I cannot use it myself.

Ourdentity is an ID from which we can also benefit, such as an employee number or bank account number. However, because its provider is a company or a bank, we do not have control over it, and it may one day be deleted unilaterally without our consent.

Mydentity, by contrast, is an Identity that you manage yourself. If, for example, you obtain your own domain and issue yourself an email address, that address is a Mydentity. Ideally, you should be able to use this Mydentity to obtain authorization wherever services are provided.
The trend in the world should be toward Mydentity, and this could indeed be called Identity 2.0.

Securely managing this, however, is surprisingly difficult. That is why the idea of Identity Hosting arises, along the lines of Web Hosting. An Identity Hosting provider is merely entrusted with management and does not hold rights to the Identity itself. In this case, however, measures are needed to address the trustworthiness of the person or company providing Identity Hosting and what happens if it goes out of business. These are precisely the kinds of matters being addressed by XDIORG: establishing uniform operating rules; making it possible, when necessary, to move from one hosting provider (which we call an Identity Broker) to another; arranging escrow so that even the provider’s sudden demise does not cause a problem; determining what kinds of insurance must be carried; and putting contracts, terms, and various other arrangements in place. Unless these things are done, the Identity framework cannot be widely used. We should not think too casually about the technology alone.

From a technical perspective, SAML alone is not sufficient. A framework is needed to resolve members of a circle of trust that has not been determined a priori and to assess their trustworthiness (reputation). XRI/XDI is one such framework. It is a URN scheme with a built-in delegation framework and is a core technology of Yadis. Standardization is proceeding at OASIS Open, with participants including SAML evangelist Peter Davis.

Now, this Sxip blog post promotes Sxip by claiming that SAML is too heavyweight to be used from devices such as a Blackberry. Is that really true? Could it simply be that current SAML implementations are heavyweight?

As part of our R&D work, we are currently experimenting with something like mod_saml as an Apache module. It has SAML Assertion Provider and SAML Assertion Consumer components. When the Consumer receives an Assertion, it places the information in environment variables, allowing the Web Application to use it without being aware of SAML, much like Basic Authentication. I think something like this could make SAML very convenient to use. What do you think?