Some of the best software libraries I’ve used address both ends of the spectrum. There’s a common adage in software development (and I’m sure it goes back farther than that): “make the common things easy, and the hard things possible”. First, you don’t want to make things any harder than necessary for the majority of users that are just using the basic functionality of a library. If they don’t care about customizing and tweaking every little aspect of it, then the way they interact with the library should be relatively simple and straightforward. But for those users that have unique needs, the library should allow them to configure it in such a way to accommodate that. It is certainly my goal to address both extremes in the Shibboleth OpenID library, but it will happen in phases.

The first phase will address the edge-cases, those users of the library that tend to have unique needs and requirements. That may seem backwards, but I assure you it isn’t. First of all, the really practical reason for starting here is that Shibboleth is itself an edge case. The reason I chose not to use the existing Java OpenID libraries in the first place was that they didn’t adequately conform to the way Shibboleth needed them to work. But from a design perspective, I’ve found that this approach tends to yield better results anyway.

Small Pieces Loosely Coupled

I’ve learned that in order to make a system really flexible and modular, it’s best to architect it that way from the very beginning. You have to decide where the logical divisions of labor are within the system, and then translate that into the code itself. Each component should be relatively self-contained, it’s purpose should be clear, and its interface (the way it interacts with other components) should be separated from its actual implementation. Sometimes these components are obvious, and there are clear places where the code should be divided. But more often than not, its a judgement call. Architecture is often harder than actual construction, whether you’re talking about software or brick and mortar. It requires a lot of creativity because you’re often working from a blank canvas, but it also requires that your plans are grounded in what is actually possible. Architectural plans are worthless if they can’t actually be implemented in the real world in a practical way. By no means do I think that I’ve found the best architecture for this library, because it’s always subjective. Fortunately, I’ve had similar libraries that I’ve borrowed from heavily for inspiration, as well as much smarter developers that I work with to bounce ideas off of.

At its core, this library is an OpenID messaging library. It is capable of converting between generic HTTP messages and strongly typed OpenID objects that developers can work with. My last two posts have talked about this in detail. The library also provides the additional logic for implementing the OpenID specification, things like Diffie Hellman key exchange and OpenID message signing. What the library does not do is tell you how you must compose these pieces into a working system. That’s because there isn’t just one way to do it. It greatly depends on the application that is wanting to add OpenID support. If you’re using a Java framework like Tapestry or JSF, perhaps you have other processing that happens to the message before the OpenID library gets involved. How does the user get authenticated and where do the user attributes come from? I have no idea… that’s up to your application to decide. At this level, the library makes no assumptions (or at least as few as possible) about how all of these small pieces should be coupled together.

If this sounds like a lot of work left up to the user just for something as simple as OpenID, you’re right… it is a lot of work. But when you really need that level of control, it’s important that the library support that.

Addressing the Common Case

So what about everyone else, all the “mere mortals” who don’t need that much control, and just want to add OpenID support to some application using the default configuration? At a high level, I’d love to have a Servlet Filter that you can drop in front of your application, configure a few small things, and have it just work as an OpenID relying party. I’ve always been a huge fan of the Tapestry framework, so I’d love to have a Tapestry component that can be dropped in just as easily. All of these things are possible by building a layer that sits on top of those individual components in the library, and arranges them in a prescribed way.

Now, I don’t anticipate that a drop-in Servlet Filter will ever be a part of the core library, because I don’t think it belongs there. It would be a separate deliverable unto itself that simply relies on the library to do all of OpenID work. This also means that the Filter wouldn’t necessarily need to come from me, anyone could write it and make it available. I don’t imagine that the core library itself will ever have everything that the “common case” users will need. And I’m okay with that, because I’m not building an OpenID product, I’m building an OpenID library.

Current Status

This is by no means a complete picture of the Shibboleth OpenID library, but it should give you a rough idea. It identifies some of the larger components of the libraries, and some of the interdependencies.

The orange blocks are pieces that are basically complete and present in the current library. All of the message handling is complete for OpenID 2.0 message, as well as three of the most popular message extensions (SReg, AX, and PAPE). Additionally, association management is done, and a very simple AssociationStore is provided (though it needs a little improvement). The security layer is complete insofar as signing and verifying signed messages. The yellow blocks represent pieces that are not yet complete, but will be included in the core library in the future. The discovery component is still up in the air a little bit because it’s not completely clear if we’ll be using XRD, XRDS, or both. The portions of the security layer that depend on discovery are, of course, waiting on the completion of the discovery stack. Those pieces include everything that an application would need to construct an OpenID provider or relying party. They implement the full OpenID protocol.

But those components alone leave a lot to be filled in by the application using the library. It says nothing about how an incoming HttpServletRequest object is converted into an OpenID Message. The application would be responsible for instantiating the specific objects and wiring them together to actually get a working AssociationManager. And for applications that wish to have control over these specific aspects of an OpenID flow, this is a good thing. The next layer up on the stack however, the yellow “Managers” block, will provide simple Manager objects that wire things together in a prescribed way. Most users of the library will deal with the Manager layer, and probably nothing else. Only when they have specific needs will it be necessary to dig any deeper.

Now this last layer is actually nothing special… it’s a very common pattern, and both OpenID4Java and Joid work in very similar ways. I point it out only to note that while this layer will be part of the core library in a future release, it isn’t right now. Much of the code that will likely make up these components has already been written, but in the form of the Shibboleth IdP extension. For the last few months I’ve been simultaneously building both a generic OpenID library, as well as an actual product that makes use of the library. One of the tougher ongoing challenges while doing this is in deciding which of the two projects a particular bit of code goes into. Much of the time it’s clear, but when in doubt, I’ll put something into the Shibboleth extension rather than the library. If anything, I want to err on the side of keeping the library “pure” so to speak. To not accidentally bake any assumptions into the library itself that might limit its flexibility. One of my focuses after the holidays will be in identifying which pieces need to be refactored from the Shibboleth extension back into the core library in order to build out that management layer.

(And in case it’s not clear, the final layer in grey in the stack above are other pieces that will make use of the OpenID library, but will likely not be part of the library itself.)

Let me first preface this by clarifying that I’m not saying the existing OpenID libraries are not usable. Quite the contrary, I know that the OpenID4Java library is used for AOL’s OpenID provider, on Google’s Blogger, as part of Sun’s OpenSSO, and countless other projects. Additionally, JOID powers Verisign’s very usable PIP. There is no question that they work for many use cases. However, they lack the clean architecture I was looking for, which can really only be corrected by starting from a blank canvas.

(I’m not sure how many posts this will take, or how sensical the order of things will be, but better to go ahead and get it written down in some form.)

Message Handling Flow

One of the most immediate differences you’ll see in the Internet2 library is the very clear separation of logic in the message handling code. I wanted the core message objects to be simple Java beans that provide access to strongly typed properties, and nothing more. When I’m processing an OpenID message, I don’t want to be thinking about how that message was encoded during transit. Additionally, I don’t want to duplicate code if at all possible, so there needs to be one very clear place where any particular process is implemented. To achieve this, messages are transformed into three distinct formats as they are being processed.

When a message comes in to an OpenID provider, it is in some kind of transport specific format. Typically that will be a URL-encoded string that is taken either from an HTTP POST request body, or from an HTTP GET request query string. Alternately, it may be a Map retrieved by calling ServletRequest.getParameterMap. This transport specific format needs to first be converted into some kind of common intermediary format so that the next step in the process can deal with all messages in the same way, regardless of transport method. In the Internet2 library, this common format is a ParameterMap.

ParameterMap

A ParameterMap is simply a LinkedHashMap with QName keys, String values, and a little additional logic. Why QNames for keys? Aren’t those for XML? Yes they are, but they actually work beautifully for OpenID message parameters as well. You see, an OpenID message is really just a collection of namespace qualified parameters, and can be quite easily represented in XML. (Yes, this is a little bit of a rabbit trail, but it’s interesting nonetheless). Let’s start with a really simple KVF encoded OpenID message:

openid.ns:http://specs.openid.net/auth/2.0
openid.mode:checkid_setup
openid.claimed_id:http://example.com/
openid.identity:http://example.com/
openid.ns.sreg:http://openid.net/extensions/sreg/1.1
openid.sreg.required:email,fullname

Yeah it has no signature, etc, but that’s not the point. What might this look like in XML?

<message xmlns="http://specs.openid.net/auth/2.0" 
         xmlns:sreg="http://openid.net/extensions/sreg/1.1">
    <mode>checkid_setup</mode>
    <claimed_id>http://example.com/</claimed_id>
    <identity>http://example.com/</identity>
    <sreg:required>email,fullname</sreg:required>
</message>

See how cleanly it maps? This is no accident. This is a very common pattern for handling namespace qualified parameters. First you assign your namespace to an alias, then you use that alias as a prefix for any parameters that are part of that namespace. The simple registration ‘required’ parameter name has three parts: there’s the base parameter name (“required”), the namespace alias (“sreg”), and the actual namespace URI which is declared separately (“http://openid.net/extensions/sreg/1.1”). A Java QName object consists of three parts: a namespace URI, a local part, and a namespace prefix. Slightly different terms, but exactly the same concepts.

Okay, so back to our OpenID library. We’ve taken our transport specific encoding, passed it through an appropriate MessageDecoder, and ended up with a ParameterMap. Before we move on, I want to point out one more thing about the parameters in a ParameterMap. None of the parameter names contain the “openid.” prefix. This prefix is specific to messages that are encoded using URL Form encoding, since that’s the only way to identify which parameters are part of the OpenID message. One of the jobs of the URLFormCodec is to strip this prefix as messages come in, and add the prefix as messages go out. The message encoder and decoder is the only part of the entire library that knows anything about this prefix, and quite frankly it’s the only part that should.

Okay, so now that we have our ParameterMap, it needs to be converted into an actual message object, which is the job for a MessageUnmarshaller.

Unmarshalling messages

Message unmarshallers are responsible for taking a ParameterMap and using it to populate a specific kind of message object. Remember the desire for message objects to have strongly typed properties? The corresponding unmarshaller for that message type is the one and only place that needs to worry with how the parameter passed on the wire gets converted into that strong type. For example, AssociationRequest messages may include the Diffie-Hellman public key of the OpenID relying party. Java provides a very specific object just for that called DHPublicKey, so that’s what we want our AssociationRequest object to use. Parameters can only be passed as strings during transit, so the AssociationRequestUnmarshaller (and nothing else) is responsible for knowing how to convert that string into a DHPublicKey.

Similarly, Attribute Exchange fetch requests may include a list of required attributes it wants for a user. These attributes are identified by URIs, so Attribute Exchange does it’s own aliasing similar to the namespace declarations we saw above. This way, the “ax.required” message parameter need only contain a comma-separated list of attribute aliases rather than the full namespace URIs. But when you get right down to it, these aliases are just an optimization that is used during transport. Really all that’s being represented is a list of attributes URIs. This is why the FetchRequest object in the Internet2 library exposes this particular message parameter simply as a List of attribute URIs. It’s the FetchRequestUnmarshaller that is responsible for taking the AX message parameters, dereferencing the attribute aliases, and populating the FetchRequest object appropriately.

Reversing the process

What about returning OpenID response messages? We just do the same process in reverse. The message object is passed through an appropriate MessageMarshaller which populates a ParameterMap. And the ParamerMap is in turn passed through a MessageEncoder that produces some kind of transport specific format. That may be a Key-Value form encoded string, as is the case with direct responses, it may be a URL suitable for redirecting the user to, or it may be an HTML response to use for HTML form submission.

Uniformity over brevity

Depending on how you separate them, there are roughly nine different message types in the core OpenID 2.0 spec, and for each of these message types, the Internet2 library has five files that handle the processing. There’s the message interface, the concrete implementation, the message builder (which I didn’t actually talk about in this post), the message marshaller, and the message unmarshaller. At times all these files may seem needlessly verbose, especially when you see that some of them are only a few lines long. It turns out that this separation doesn’t necessarily result in more lines of code, just that the code is broken up into smaller chunks. Besides, the goal here is not conciseness. The goal is uniformity and predictability in how messages are processed, as well as clean, logical separation of duties. When every message is processed in exactly the same way, bugs tend to expose themselves much earlier in the process, and strange edge cases are far rarer. When things are logically separated, it makes the overall architecture much easier to understand. And perhaps more importantly, it makes it possible to fully understand one part of the library without needing to be concerned with others. You can go in and look at the code for signing messages, and not have to wade through code dealing with transport encodings.

Shibboleth and SAML

Shibboleth is an open source web single sign-on product which is very popular with universities around the world. It is primarily an implementation of the Security Assertion Markup Language (SAML), but supports other identity protocols as well. SAML v2 defines a specific type of identifier that may be used to identify a user within a transaction known as a Persistent Identifier. The name itself does not convey it’s full meaning, but it is defined as “a persistent opaque identifier for a principal that is specific to an identity provider and a service provider or affiliation of service providers.” This is SAML’s directed identity.

Shibboleth’s implementation of persistent identifiers has matured a bit over the years, but the main algorithm remains the same. At it’s simplest, the identifier is simply a hash of three things: an identifier for the user, an identifier for the identity provider, and an identifier for the relying party. Using md5 as our hashing algorithm, and using a few made up values, this would look like:

md5( "jsmith" + "http://idp.example.com/" + "http://sp.example.com/" ) = 
    2f6bc52c7527747eff263f4183c7f402

When a relying party receives the string “2f6bc52c7527747eff263f4183c7f402”, it is completely opaque and reveals nothing about the identity of the user.

Working with known algorithms

As I mentioned before, Shibboleth is open source software. All of our code is publicly available, including the way that we calculate persistent identifiers. So how could a relying party use this knowledge to take the above opaque identifier and decipher the identity of the user it belongs to? Pretty simply, if they have a list of possible usernames, or can reasonably guess them. A list of usernames is far easier to get than you might imagine from unprotected university LDAP directories. Then you simply iterate through the list and run the same algorithm until you find the matching hash value. And even given a population of 30,000 usernames (the approximate number of students at USC where I worked), the following shell script churns through them in about 90 seconds:

~$ date && for i in `head -n 30000 /usr/share/dict/web2`; 
   do echo $i | md5 >/dev/null; done && date
Sun Aug  2 16:25:53 PDT 2009
Sun Aug  2 16:27:35 PDT 2009

To protect against such a brute-force attach to reveal the identity of a user, we added a secret salt to the hashing algorithm. That way, you can’t regenerate the hash without also knowing the salt value:

md5( "jsmith" + "http://idp.example.com/" + "http://sp.example.com/" 
    + "my-secret-salt" ) = cf79282c587897fb733d8338fe7bc9c2

It’s worth pointing out that, while use of a secret salt prevents a relying party from brute forcing the hash, it in no way prevents the identity provider from doing so, since they do of course know the secret salt. Though we never ended up needing to do this at USC, we built the tools that would enable us to identify the user a persistent identifier belonged to. In the event that a relying party reported that a particular user was abusing their system, we wanted to make sure we could identify who it was.

The realities of deployment

The above algorithm actually works pretty well for generating unique and secure opaque values for tuples of user, identity provider, and service provider. But what happens when one of those values change? At USC, users could request that their username be changed for a variety of reasons, and approximately 300 such requests were made each year. So using the above algorithm, a username change would change every one of the user’s generated persistent identifiers. And the reality is, businesses are often bought out by other businesses. What happens when “http://sp.example.com/” needs to change to “http://sp.new-company.com/”? That will effect the generated persistent identifier for every user. How do you deal with these realities? There are a number of ways, and I’ll outline just a few. There is no one right solution, as the policy and practices of a particular institution will greatly impact their decision of how to address these situations.

Perhaps the simplest option in some respects would be to simply not change which identifiers are used for generating the hash and instead map the new identifiers to the old values. Even if a user’s username has changed to “jjones”, you map it back to “jsmith” for the purposes of generated persistent identifiers. While this allows a deployment to continue using the same hashes, it does introduce the burden of maintaining this map of identifiers. And what is the institution’s policy with regards to re-issuing identifiers? If “jsmith” is allowed to be re-issued to a different user at some point in the future, that is going to create problems.

An alternate solution would be to simply use better identifiers. At USC, we had another user attribute called the “uscPVID” which we used instead of username. This was itself an opaque identifier that effectively served as the primary key within the enterprise directory. Even if all the other data for a user changed like their name and username, the uscPVID would remain the same. The same kind of persistent key can be obtained for relying parties by creating a lookup table that maps the relying party’s public ID to some more persistent internal ID. If and when a relying party changes their public ID, you simply modify, or add a new entry in your lookup table.

Finally, an identity provider could migrate from old to new identifiers, either with a one time update, or gradually. For a one time update, the identity provider would generate the old and new identifier for a user or set of users, and provide that information to the relying part out of band. The relying party would then be responsible for updating their database accordingly. Alternately, the new and old mapping could be provided gradually at the time of user login by using attributes. This was the technique used at USC for updating relying parties of changes to a different user attribute known as the USCID. For reasons I won’t bother explaining here, this 10 digit ID could change for a user when certain events occurred. To alert relying parties, we would include two attributes — the current USCID for the user, along with a list of “historical” USCIDs for that user. Relying parties were then responsible for updating any records they had for one of the historical USCIDs to the current USCID of the user.

Application to OpenID

The above hashing method could be used with little or no modification to create directed identity URLs for OpenID users. You could of course simply generate completely random IDs and store them in the database… that works too. In my next post however, I’ll be talking about a new kind of OpenID service I’ve been doing a lot of thinking about, an OpenID proxy which works to protect the privacy of OpenIDs that don’t support directed identity themselves. We’ll be using the above hashing algorithm, but doing some interesting things with the user identifier.

I’ve been working in the Identity Management space for a few years now. I started getting involved with the Shibboleth project while at the University of Memphis. After a year and a half, I moved to California and took a job at USC working in their middleware group. I’ve spent the last two years there helping to develop and manage various parts of the Identity Management cloud including the LDAP directories, meta-directory processes, and their Shibboleth environment. In October 2006 I formally joined the core Shibboleth development team, focusing on the Shibboleth 2.0 Identity Provider.

Meanwhile, I have also been toying with OpenID for a couple of years. In early 2007 or so, I sort of took over development of Alan Castonguay’s OpenID plugin for WordPress. I started with a couple of new features, then worked to add support for the latest OpenID protocol, lots of code refactoring, etc. I got to know characters like Chris Messina, Scott Kveton, and a host of others. I continued making updates to the WordPress plugin as I had time, but it never felt like enough. Don’t get me wrong, I certainly enjoyed the work I was doing at USC and with Shibboleth… I just would have liked to have had more time for everything else as well. Every now and then Chris or Scott would prod me about going to work at Google or somewhere to spend more time on OpenID and related technologies, but I wasn’t ready to leave my work at USC.

Late last year, Chris Messina and Steve Ivy announced the DiSo Project, initially based on my updated wp-openid plugin. Within the first week after it was announced, I sat down with Chris and Steve and we decided it would be best to officially move the wp-openid plugin under the DiSo umbrella to allow for tighter integration with the other planned work. Then a lot happened this last February in the social networking space — Google announced the Social Graph API and SGFoo really got people talking more about enriching the OpenID endpoint (among other things). Things were beginning to move pretty fast, and I felt like if I didn’t jump in now then I’d end up watching all the great new developments from the sidelines. I spent the next few months interviewing with a number of companies active in this space and made a couple of trips to San Francisco to talk with them in person.

In the end, a dinner conversation with Luke Sontag had me sold. I was quite familiar with Vidoop and their OpenID provider, knew they had a great development team, but had always been a little skeptical of the company. After Luke gave me a better picture of their overall vision and where technologies like DiSo fit into that picture, I knew that these guys really “get it”. They understand the importance of what DiSo is trying to do, and more importantly they are willing to do their part in making it a reality. I love Vidoop’s OpenID implementation and have been using it since before I took this job, but that’s not why I did. I took the job because the team at Vidoop know their shit, they know the kinds of problems we’re up against, and they are ready to take a shot at developing some real solutions. Well that and I really can’t wait to get started working with Chris a lot more. :)

Every marriage counseling book in the world would probably recommend otherwise, but I’m also taking a new job when we get back from the honeymoon. I resigned my position at USC early last week, and my last day will be next Friday April 25th, 2008. It is a bit bittersweet, as I really wish I would have had the time to wrap up more of the unfinished projects I’m leaving behind, but I trust that they are in good enough hands and will be well cared for. If things go as planned, I will continue on as part of the core Shibboleth development team, which I feel is very important. There are a few major additions to Shibboleth we’ve talked about adding, but simply haven’t had the time. The primary attraction to the new job is quite simply the work I’ll be doing and who I’ll be doing it with — I’ll finally be able to really dig in to some of the projects that haven’t received the level of attention I would have liked to give. Aside from that, I don’t think I’m ready to say too much else about the new job, only that it is in San Francisco and that we will be moving up there as soon as the wedding is over and we find a place.

OpenID attributes

The OpenID Simple Registration Extension was designed, much like OpenID itself, to address a very specific use case — providing the most common data requested when registering at a new website (things like name, email, gender, etc). It defines a fixed list of nine attributes that can be provided, and it works well for what it does, but it’s a bit rigid when one tries to do anything more with it. Even before the final draft of the SREG extension had been published, work was already being done on a more flexible extension for attribute exchange. This new extension defined only a mechanism for transferring attributes, but didn’t prescribe a fixed list of attributes. But in order to be at all useful, two parties must be assured that they are both talking about the same attribute. Therefore an attribute registry was established at axschema.org and a number of attributes (formatted as URLs) have already been defined which will likely be useful in common scenarios.

Attributes in Higher Education

Developed in the early 90s at the University of Michigan, LDAP quickly grew favor with higher education institutions to replace heavier-weight directory protocols. A number of LDAP object classes were defined to provide attributes deemed useful in certain contexts, for example rfc2798 defined inetOrgPerson which addressed the needs of “Internet and Intranet directory service deployments”. Higher Education had its own unique needs, so in 2001 Internet2 published the first version of the eduPerson Object Class. If (and only if) institutions required additional attributes beyond those provided by some already published object class, it was common practice to define a local object class to house those attributes.

Within a few years, the SAML specification was published and Shibboleth began finding its way onto many college campuses. Though not required by SAML, Shibboleth recommended the use of URIs for SAML attribute names, and subsequently established a collection of URN values to represent common LDAP attributes, including those defined in the eduPerson object class. As before, if campuses needed to include additional attributes in a SAML assertion, they were defined within a local namespace. Today, it is very common to see a mix of attributes at USC including those defined by Internet2:

• urn:mace:dir:attribute-def:displayName
• urn:mace:dir:attribute-def:eduPersonAffiliation

as well as those we have defined locally at USC:

• urn:mace:usc.edu:gds:attribute-def:uscUSCID
• urn:mace:usc.edu:gds:attribute-def:uscStudentDegreeProgram

Applying Precedence

No one is pretending that the fixed set of attributes defined in rfc2426 is the definitive list of attributes that could possibly be useful in OpenID, no more than eduPerson was the exhaustive list of attributes for every university that used it. All that is being questioned is why did Attribute Exchange redefine all that was already established in vCard? I would strongly support Tantek’s third proposal of hosting the official hCard XMDP profile at http://microformats.org/profile/hcard, so that AX can leverage the hCard specification while maintaining URL based attribute names. And given that it appears as though no one is currently supporting AX, now is the time to make this change.

(For the non-technical, the title roughly reads “First try to reuse. Only if that doesn’t work, then reinvent.”)

So the question is, when OpenID is clearly a player in the future and part of that promise is about making things easier, more consistent and more citizen-centric, why would we go and introduce a whole new format for representing person-detail-data when a perfectly good one already exists and is so widely supported?

While I certainly agree with Chris that hCard has a role to play in the new world of online identity, I don’t want SREG or AX to be dismissed too quickly. I don’t believe he was suggesting that hCard would replace SREG/AX in all use cases, but I want to labor this point just a little bit so that others are not confused.

There is one huge benefit to SREG and AX that hCard doesn’t (and by it’s nature, can’t) address… releasing different attributes to different relying parties. This can take a number of forms. The one most commonly supported in OpenID providers today is the idea of personas - a complete set of attribute values that reflect your online identity within a particular context. You may have a “work” persona that includes your formal name, work email address and website, etc. Separately, you may have a “personal” persona that has some informal nickname along with a personal email address, website. etc. Separate still, you may have an “anonymous” persona that includes little (or fabricated) data about yourself. Depending on which relying party you are authenticating to, you may use a particular persona.

Varying this slightly, one can imagine a use case that will be become increasingly important as OpenID continues to expand. hCard is suitable for public attributes I want to post for the world to see, but what about not-so-public data? It will likely be some time before we start transferring credit card numbers over OpenID+AX, but I have no doubt it will happen eventually (as nervous as that makes even me). But even before then, I can imagine a host of data that I may need or want to provide to a relying party, but do not want to publish in my public hCard. As I included in my OpenID provider wish-list, OpenID providers will need to provide the tools to manage the policies controlling this release of data, a feature that has the potential to really differentiate one provider from the rest of the pack. This fine-grained level of control has always been a core requirement for the Shibboleth SAML Identity provider, and I would argue that the (currently beta) Shibboleth 2.0 IdP has one of the most powerful and flexible (and admittedly, verbose) filtering engines of its kind anywhere.

So there are really two issues at play in Chris’s question, that of the data format and separately, the mechanism for conveying that data. I haven’t really addressed the issue of the data format, because I agree with Chris in principal at least. His comparison table of attribute names shows a very clear overlap between the different methods, and perhaps it would be useful to work to consolidate some of that. But the mechanisms for making that data available address different, and equally valid, use cases and each play a role in making all of this stuff work.

Imagine being able to update your shipping address in one place when you move house and having all the online retailers you use receive the updated address immediately. Or changing your email address and having all the bugzilla instances you use pick up the new address instantly (perhaps requiring you to verify the new address first, of course).

While I agree this kind of experience would be very neat, it is not a use case for OpenID nor the Attribute Exchange extension. I am not surprised to hear someone say this, as this is a common point of confusion here at USC in regards to Shibboleth. When it comes to attribute delivery, both OpenID and SAML are primarily designed to provide data at the time of login ¹. So this means that if a user never logs in to your service, you never get any data about them. And if a user’s data changes since their last login, you don’t find out about until they next login, since that is the only time attribute delivery occurs. It is also important to note that you are typically only getting data about the user that is logging in, no one else. You can’t treat an OpenID provider as a lookup service to get data about some other user.

So how does a relying party update their data without waiting on the user to login again? One option is to have the data pushed to each service using some kind of messaging hub. There is a whole market for enterprise messaging complete with its own set of acronyms like ESB, EMS, EAI, and many many more. I’m particularly interested in a project developed by a colleague of mine in Sweden called JEvent, which uses the XMPP Publish-Subscribe protocol to deliver these types of messages using a standard XMPP server in the middle. Your Jabber messaging window becomes your console. :)

The other method of getting at user data is for each relying party to pull the data. This is the model we use at USC, where that mechanism for pulling data is LDAP. A number of services on campus use LDAP to address both use cases mentioned above — refreshing data about users, as well as looking up data about someone other than the user who logged in. So what’s the equivalent in the decentralized OpenID world? Well honestly there isn’t anything just yet but we have a good foundation. Thanks to microformats like hCard, you can publish your data in a standard, machine-parsable format that your online retailers or bugzilla instances could watch periodically. When you update your hCard on your homepage they can respond in kind, perhaps by immediately updating their databases or sending you a confirmation email of the change. Right now all of this data is decentralized, published on personal blogs and webpages. I don’t argue that this data should certainly be under individual control, but it puts an awful large burden on the individual service providers to do all that spidering. I don’t know what the answer is, but I’ve been thinking about an hCard crawler with an LDAP front-end as a simple place to start. Configure Apple AddressBook or Outlook to use LDAP, and you’re off and running.

Shibboleth loosely translated means, “Who the fuck are you?”
- Dead Library

We’d like to be your provider of choice - so do tell us what you want to see.

I had been meaning to post a reply to this for several days, but now with Martin Atkins’s Relying Party Best Practices, it seems like an ideal time to discuss this. Here is a short list of items I came up with that I’d like to see in an OpenID provider, roughly in priority order. A number of them are already addressed by one or more existing providers, while several are not.

• SSL — not having SSL is an immediate deal breaker. If my password or my personal information is going over the wire, it sure as hell better be over an encrypted connection.

• Strong Authentication — this was the primary topic of the aforementioned post, and more details can be found there. The main point, however, is that I’d like some kind of stronger authentication mechanism than just a single username and password. As more OpenID enabled services come online, the more important it will become to have a stronger mechanism to identify the user. This might be in the form of an client SSL certificate like prooveme and certifi.ca use, or a one-time-use password like iamdentity.

• Auditing — It looks like a number of providers allow you to see and modify the list of all the relying parties you trust, and while that’s a good start, this could (and for some use cases, should) be expanded much beyond that. I’d like to see a log of every time I authenticated to a particular relying party, and perhaps some additional information about that transaction such as IP address. This could potentially help identify if and when my account has been compromised. When attributes are released via simple-reg I want to see that, and it might also be useful to know exactly what values were released during a given transaction. I may have updated an attribute a number of times since it was released to that relying party months ago, and I might like to know what values were sent to them.

• Real attribute release policies — Perhaps I’m just spoiled from working on Shibboleth for several years, but I would really like fine grained control over what attributes are delivered to a given relying party. MyOpenID’s “persona” feature definitely comes pretty close on this, but I believe it is still an “all or nothing” choice — I can’t approve the release of only a subset of the attributes an RP requested.

• Modify attribute value for the current transaction — This somewhat carries over from the previous item. MyOpenID has the ability to edit your persona just before you send it to the relying party (although this is a bit broken, because it completely breaks the OpenID flow if you do so). In addition to making permanent modifications to a persona, I’d like to be able to modify the values that are released for the given transaction only. For example, I may want to use my main persona for this relying party, but just change my email address to something different.

• Identity Linking — This is certainly in the running for being the latest “holy grail” of OpenID… the ability to link multiple OpenIDs in such a way that relying parties understand that they are equivalent. I’m not even sure if the provider is the right party to address this problem (I imagine it will require work on both sides) but if someone is able to come up with a compelling solution, that would be very attractive.

So there’s a few things I was able to think of in a short amount of time, but I’m sure I overlooked a bunch. I’m curious to know what kind of features others would like to see in an OpenID provider. Don’t limit yourself just to what you think is realistic or easy to implement in the short term… think bigger than that, this is a wish-list after all.