SAML everywhere?

A couple of pictures from Paul Madsen's December 17th, 2006 ConnectID blog entry are most definitely worth many thousands of my words.



Madsen views the second picture as "more speculative" perhaps because it entails somehow transporting a SAML XML fragment through a query string in place of the pieces of an OpenID 1.0 Simple Registration Extension persona.

Certainly this calls to mind that aphorism about a camel passing through the eye of a needle. Of course, that was before Fortran took us all to the moon (and beyond) relying exclusively on a method of parameter passing called pass-by-reference.


Note that Liberty Alliance is a working group that promotes the federation architecture where a user might store identity information with several identity providers that might also be web sites. These sites have an agreement to share identity information.

At this point we probably need a score card to keep track of everything. Not everything under the sun. But everything under Identity 2.0. Fortunately, such a score card seems to exist. See also the reference to Identity 2.0 in Wikipedia.

Technorati Tags: Identity 2.0, Liberty Alliance, OpenID, SAML

Simple Registration Extension

MyOpenID.com now supports the Simple Registration OpenID Extension. Indeed, MyOpenID.com supports what might be called an extension to the extension -- personas.

Each persona can hold the full set of attributes. The user gets to choose which persona to present to the application.

It does appear that the DotNet OpenID Library can retrieve Simple Registration information from the host by way of classes in the consumer module that engage the host in a request for attributes and parse the host's response.

Note that the DotNet OpenID Library is a port of the Python OpenID Library. The DotNet OpenID Library in turn has a dependency called Mono.Security.dll -- a library built and distributed freely by the Mono Project.

Technorati Tags: OpenID

Jennifer's OpenID Sequence Diagram

There are a series of redirects. Depending on whether or not a site is trusted by the user, a user may or may not be prompted to authorize the passing of credentials and optionally an attribute exchange (via the the simple registration extension) between the site and the OpenID Server.

These redirects are visualized in Jennifer's sequence diagram.

A good narrative to go with the diagram can be found in the overview of the Python OpenID Library consumer module.

OpenID NOW!

There are a number of pieces -- moving parts. Some are core. Some are not depending on what we might want OpenID to do.

Let's say there are three scenarios:

1. We want to build a .NET 2 application that authenticates with OpenID.


2. In this application we want to control which OpenIDs will be accepted. We might only want to accept OpenIDs from a subset of our employees or from this subset and a subset of employees at another organization, etc.


3. In our application we will want to retrieve attributes of the user's profile to guide .NET 2 authorization.

Today perhaps all three scenarios can be implemented. The first is leading edge. The second and third are bleeding edge.

The first scenario requires that:

the user has an account at an OpenID Server and

class libraries are available for .NET 2 to use to interact with the OpenID server.

In fact, I just set up an OpenID account with Verisign's Personal Identity Provider. As far as a library goes to enable interaction between a .NET 2 app and an OpenID Server goes, see the C# library at OpenID Enabled.

The second scenario can be implemented in a couple of ways. One approach is to use a dedicated OpenID Server. We could host it or have someone else host it. See Host your own OpenID server.

The second way to implement the second scenario uses attribute exchange. Attribute exchange is part of the OpenID 1.0 Simple Registration Extension. It enables an application with the permission of the user to access user attributes that are part of the user's profile stored at the OpenID Server. Currently, some OpenID servers support attribute exchange. Others do not. As an aside, attribute exchange is the path OpenID will grow if it is to compare favorably with CardSpace (Microsoft).

Finally, with regard to our last scenario, OpenID support for .NET 2 authorization and role-based access to pages also depends on attribute exchange.

If you want the skinny on OpenID, CardSpace and attribute exchange see a recent post at Kim Cameron's Weblog.

Technorati Tags: CardSpace, OpenID