Skip to main content
GDPR Kit CIAM Buyer's Guide Contact Us
Janrain respects your privacy and will treat the personal data you choose to share with us in accordance with our privacy statement.

We use cookies to give you the best online experience. By using our website you agree to our use of cookies in accordance with our privacy statement


Mobile Menu

More on Authoritative IDPs

By Janrain Team | Posted on May 09, 2007

A commenter named “Andrew” had this observation in response to my post yesterday about Sun and their plans to deploy an OpenID server that (only) issues OpenIDs to Sun employees.

But, doesn’t this run into the whole problem of multiple logins? Were this world to develop, I’d have to choose which sites I wanted to use my Sun Employee OpenID, which sites I wanted to use my college student OpenID, which I wanted to use my own personal (domain name) OpenID. Is this what we want?

I got the same kind of response from several staffers here at JanRain. It’s a good point, and there’s no getting around the fact that, at scale, a proliferation of IDPs — each a “single purpose” IDP (i.e., deployed just as a vehicle for supporting an authoritative claim of one type or another) — works against the stated goals of OpenID: to make one’s online identity more manageable. If I have to have an ID for my employer at my employer’s IDP and an ID at United Airlines’ IDP and an ID at Amazon’s IDP and… at some point it starts to look much like a problem we hope to solve — too many logins and passwords.

That said, I remain convinced that the Sun announcement, and others like it that are sure to follow, is a significant step forward for OpenID. Why? Perhaps the best way to answer this is to look at the “better” answer. Andrew continues:

Maybe this is in the works too, but wouldn’t it be better to have some way to authenticate an OpenID against multiple authorities? That is, I have a domain name that I use as my OpenID. The main reason I do this is so I can have greater control over my identity. I am free to change OpenID providers at will or even setup my own. I’m far less dependent that way–and when it comes to my identity, well, I like to be in control. Wouldn’t it make sense to have a system in the protocol for authenticating OpenIDs against servers that verify the status of that ID?

Yes, that makes great sense, and that is definitely the point on the horizon that we are marching toward. But that “some way” doesn’t exist quite yet, and I suggest that moves like this one by Sun are the catalysts that will push the development and deployment of solutions like you suggest. In our talk about this yesterday inside JanRain, we supposed it would be much more elegant to have a “group” idiom that could be authoritatively maintained by an OpenID. So, for example, one might suppose that Sun hosts an “OpenID Group” (a concept that has been batted around, but isn’t a part of OpenID in its current version):

Queries could be addressed to this group (”Is this ID a member of this group?”), which would mean that your own, personal ID could be added to that group, thereby removing the need to allocate a new ID for you in the Sun OpenID namespace. For example, if I were a Sun employee, they could add “” to the their “employees” group. This seriously empowers my main OpenID, as I can manage my “go-to” ID (or small set of IDs) and arrange for my main ID to be verifiable as a member of all the groups I want to or need to belong to. Beautiful right?

Yes, but no sooner do you finish reading that paragraph before issues start to arise. What about recycled OpenIDs? If Sun were to put “” into their “employees” group, and verify my employment at Sun through that ID, then what happens when I let the domain name lapse, and someone else gets administrative control of “”? I won’t chase down all the permutations of the problems that arise from this proposal, but the point is that solutions will be developed that work to consolidate and empower your “go-to” OpenID, but these solutions will need some solid work before they are ready to adopt by the likes of Sun and others.

As it is, Sun’s announcement is a positive step along the “evolutionary pathway” for OpenID. Sun won’t verify “” as an employee at any point in the near future — even assuming I was a Sun employee — as Sun does not currently have a reliable means of ensuring that “” will remain bound to me, and only to me. What they’ve got going will provide strong assurances that the IDs supported at are, at this instant, employees in good standing at Sun. As long as Sun can maintain control over their domain name, they do not have to worry about the ongoing ownership of the IDs they are verifying as employees.

There are ways to solve these problems, to provide a means of avoiding “ID proliferation” while providing controls that protect against the problems of delegated authentication. But we’re not there yet. Sun’s move kicks us down that path, and that’s a good thing. As we have more corporate adopters of OpenID, we will have a solid basis for getting a solution in place for this.

It also should be noted that many enterprises will specifically aim to provide a distinct ID to be used as a “corporate ID”, and will sponsor and authorize IDs come exclusively from their namespace, if for no other reason than it’s branding value. I think many enterprises will be entirely apathetic to requests from employees who want their personal IDs verified as “authoritative employees” in the OpenID sense. Like a security badge to get in the front door, employees will be issued a “corporate ID”, and if employees want to consolidate their overall digital identity around a “master ID”, then they will have to find a way to bind their “corporate ID”, verified and controlled by the enterprise to their “master ID”.

Which brings us Andrews last point:

Perhaps something like a way for me to delegate an OpenID provider who will perform the functions they currently perform, and then also designate other servers (such as that can verify that my OpenID belongs to one of their employees. Obviously, I would have to associate my domain name with their system in some way. But, that seems like a better solution. It allows me the option of maintaining my single OpenID while simultaneously asserting my identity as a Sun Employee, a college student, etc.

This is very much resonant with the way I and others I’ve talked to think this may work out. If you have your “master ID”, and can selectively “bind” it to other assertions, then you become the aggregator and policy master over all the moving parts. In this case, then, you would still have the lingering problem of “ID proliferation”, but being able to say “This is me (my master ID), and I can also prove in this session that I have an associated ID that can be verified authoritatively as controlled by a Sun employee”, will enable you to use your Master ID as a Master ID, but still be able to get the full benefits of asserting that you are a Sun employee. So my master ID may delegate the primary OpenID functions to, say, (to pick a really excellent OpenID server), but it may also include other delegations:

  • To verify my employment/employer, I can assert this other ID over here at
  • To verify my 1K status at United Airlines, I can assert this ID at
  • To verify my enrollment at UCLA for my MBA, I can assert this ID at


Now, I think that United Airlines requiring a customer to have an ID at their IDP and in their namespace just as a way of making an authoritative assertion about their frequent flyer status is using a sledgehammer to kill a gnat. Clearly, it is preferably for the OpenID community to develop a lightweight, but flexible assertion framework so that United Airlines and other parties can simply make the proper assertions about you that you can carry around with your ID and present and use as needed. But no matter how expressive the assertion framework is, ultimately some providers and parties will demand that their assertions are bound to IDs that are provisioned out of namespaces they control. Sun is not willing to simply hand over an assertion that is an employee for a number of reasons, even if that is what seems most useful to me.

What we will end up with is a hybrid of sorts, I believe. Users will have “master ID” (or small set of master personae), and these IDs will have both a set of assertions that can be used for ACL and transactional purposes, and a set of “sub IDs”, OpenIDs issued by other organizations that will be bound to the Master ID. As should be clear here, there’s still a lot to be worked out and thought through in this area, which is why the Sun announcement has me feeling good; developments like this underscore the fact that there is a real business case for getting solution sets developed for this problem of authoritative assertions in OpenID.

Popular Posts

About the author